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

Your summary is only part of what I am suggesting.

I am also saying (indepedent of the above and in addition to it) that fast abort could be achieved by just sending TM on all connections of a single session.
The need for the Async Message and t= he Nops dissapears.
The negotiation (of fast abbort) can be used to allert the target that it will get TM on all connections (with same CmdSN but different ITTs).
The target will then know that:
  • there are no new data comming on oth= er connections after the TMs
  • it does not have to do the lengthy S= tatSN check


Initiators can do this with more or less the same effect today (without negotiation).
The penalty will be minimal and can be completely eliminated with the negotiation.

Regards,
Julo


Black=5FDavid@emc.com=

29/12/06 19:45

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





Julian,
 
I'm not sure I completely understand what you wrote, but if you're
suggesting that for a TMF that affe= cts tasks from multiple initiators:
- Fast abort (early termination of data transfers) is used for the sending
    initiator.
- The existing 3270 abort mechanism is used with other initiators, with
    the update that the T= MF response does not have to wait for data transfer
    completion.
I think that suggestion is reasonab= le, and it actually helps with the use
case that started this (3rd party i= nitiator is dead).  The draft text would
need to change to allow this (right now it mandates fast abort in all cases
if the key is negotiated to support it)
 
I'm not sure how target-scoped queu= es enter into this.
 
Thanks,
--David
-----------------------------------= -----------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
black=5Fdavid@emc.com        Mobile: +1 (978) 394-7754
----------------------------------------------------

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

David,

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

Regards, Julo

Black=5FDavid@emc.com=

28/12/06 21:54 =


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







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

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


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


Mallikarjun,

I would consider the text: =

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

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

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

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

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

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

28/12/06 06:41 =


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








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

Mallikarjun



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

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

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

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


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


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

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

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

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

=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
Ips mailing list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips
--=_alternative 00419110C2257256_=-- --===============0711439428== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============0711439428==-- From ips-bounces@ietf.org Mon Jan 01 08:28:50 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1NDE-0003Nm-0D; Mon, 01 Jan 2007 08:28:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1NDC-0003Ng-JA for ips@ietf.org; Mon, 01 Jan 2007 08:28:22 -0500 Received: from mtagate1.de.ibm.com ([195.212.29.150]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H1ND9-00018g-J2 for ips@ietf.org; Mon, 01 Jan 2007 08:28:22 -0500 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate1.de.ibm.com (8.13.8/8.13.8) with ESMTP id l01DSHmY019438 for ; Mon, 1 Jan 2007 13:28:17 GMT Received: from d12av04.megacenter.de.ibm.com (d12av04.megacenter.de.ibm.com [9.149.165.229]) by d12nrmr1607.megacenter.de.ibm.com (8.13.6/8.13.6/NCO v8.1.1) with ESMTP id l01DSHAd2949164 for ; Mon, 1 Jan 2007 14:28:17 +0100 Received: from d12av04.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av04.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l01DSH6B023862 for ; Mon, 1 Jan 2007 14:28:17 +0100 Received: from d12mc102.megacenter.de.ibm.com (d12mc102.megacenter.de.ibm.com [9.149.167.114]) by d12av04.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l01DSHmn023858 for ; Mon, 1 Jan 2007 14:28:17 +0100 In-Reply-To: <20061229214209.44955.qmail@web51906.mail.yahoo.com> To: "Mallikarjun C." MIME-Version: 1.0 Subject: Re: [Ips] TMF text with updates X-Mailer: Lotus Notes Release 7.0.2 September 26, 2006 From: Julian Satran Message-ID: Date: Mon, 1 Jan 2007 15:28:14 +0200 X-MIMETrack: Serialize by Router on D12MC102/12/M/IBM(Release 7.0.2HF71 | November 3, 2006) at 01/01/2007 15:28:16, Serialize complete at 01/01/2007 15:28:16 X-Spam-Score: 0.5 (/) X-Scan-Signature: f946603c3d764423e4a93f9c16516a6d Cc: ips@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1624554507==" Errors-To: ips-bounces@ietf.org This is a multipart message in MIME format. --===============1624554507== Content-Type: multipart/alternative; boundary="=_alternative 0049FD42C2257256_=" This is a multipart message in MIME format. --=_alternative 0049FD42C2257256_= Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Mallikarjun, My reading was slightly different as bellow "Mallikarjun C." wrote on 29/12/2006 23:42:09: > David and Julian, >=20 > Just to be clear on the semantics: >=20 > "Fast abort" =3D early reporting of TMF completion despite=20 outstandingtransfers >=20 > RFC 3720 Not allowed for issuing session, Not allowed for=20 > third-party sessions >=20 RFC3270 pays only lip-service to third party sessions (there is little you = can do beside it. > IG (Last Call):=20 > FastMultiTaskAbort !=3DYes > Same as RFC3720 I would clarify/correct it to say that it is allowed for third party but I = can go for your interpretation =20 > FastMultiTaskAbort =3DYes=20 > Allowed for issuing session, Allowed for=20 > third-party sessions=20 See above > Latest updates:=20 > TaskReporting !=3DFastAbort > Not allowed for issuing session, Allowed=20 > for third-party sessions=20 > TaskReporting=3DFastAbort > Allowed for issuing session, Allowed for=20 > third-party sessions=20 >=20 If the mechanics is TM then as soon as TM rsponses are collected. > Before we sanction more combinations of legal behavior, let us=20 > analyze why the last two combinations do not address the use cases=20 > we are concerned about. More combinations mean more complexity..... >=20 > As far as Julian's reference to "target-scoped" queues, I assume it=20 > is about the scope of a task set when TST=3D0. IMHO, iSCSI needs to=20 > offer a reasonable processing model for this case with Clear Task=20 > Set TMF as well as that of a Logical Reset TMF (which always affects > tasks from multiple initiators even if TST=3D1). That is where the=20 > value of fast abort comes in. >=20 I agree except that I would say that the effects on initiators other than=20 the issuing may be unexpected if they use a mechanism with different=20 semantics. > Mallikarjun >=20 >=20 >=20 > ----- Original Message ---- > From: "Black=5FDavid@emc.com" > To: Julian=5FSatran@il.ibm.com > Cc: ips@ietf.org > Sent: Friday, December 29, 2006 9:45:25 AM > Subject: RE: [Ips] TMF text with updates > Julian, >=20 > I'm not sure I completely understand what you wrote, but if you're > suggesting that for a TMF that affects tasks from multiple initiators: > - Fast abort (early termination of data transfers) is used for the=20 sending > initiator. > - The existing 3270 abort mechanism is used with other initiators, with > the update that the TMF response does not have to wait for data=20 transfer > completion. > I think that suggestion is reasonable, and it actually helps with the=20 use > case that started this (3rd party initiator is dead). The draft text=20 would > need to change to allow this (right now it mandates fast abort in all=20 cases > if the key is negotiated to support it) >=20 > I'm not sure how target-scoped queues enter into this. >=20 > Thanks, > --David > ----------------------------------------------------=20 > David L. Black, Senior Technologist=20 > EMC Corporation, 176 South St., Hopkinton, MA 01748=20 > +1 (508) 293-7953 FAX: +1 (508) 293-7786=20 > black=5Fdavid@emc.com Mobile: +1 (978) 394-7754=20 > ----------------------------------------------------=20 >=20 > From: Julian Satran [mailto:Julian=5FSatran@il.ibm.com]=20 > Sent: Friday, December 29, 2006 6:16 AM > To: Black, David > Cc: cb=5Fmallikarjun@yahoo.com; ips@ietf.org > Subject: RE: [Ips] TMF text with updates >=20 > David,=20 >=20 > My point was that we can solve the TM issue only for a single=20 > initiator. So besides puting the burden on SCSI to cleanly finish=20 > other and advise that fast solutions really work if there are no=20 > target scoped queues there is little we can do. And if we limit=20 > ourselves to a single initiator the multiple TM solution is a=20 > simpler (and basically does not deviate from 3270). If you consider > how software stacks are layered I assume that some clever=20 > implementers have figured that already (and did it).=20 >=20 > Regards,=20 > Julo=20 >=20 >=20 > Black=5FDavid@emc.com=20 > 28/12/06 21:54=20 >=20 > To >=20 > Julian Satran/Haifa/IBM@IBMIL, =20 >=20 > cc >=20 > =20 >=20 > Subject >=20 > RE: [Ips] TMF text with updates >=20 >=20 >=20 >=20 > I agree with Julian that we should avoid discussing "buffer allocations" = and=20 > the like, even though we know that something like that has to happen in=20 at=20 > least iSER implementations. A general discussion of "resources" works.=20 >=20 > > You could achive the same effect by issuing the TM command on=20 > every affected connection.=20 >=20 > Not for TMF's that affect commands from other initiators. Also, asking=20 the=20 > target to coordinate receipt of the TM command on every connection in a=20 > multi-connection session is also a bit much.=20 >=20 > > The third party story is even more puzzling as in order to negotiate=20 any of > > the new TM modes the taget will have to ascertain that all other=20 initiators > > support it. I fail to understand how would you handle downgrading the=20 mode=20 > > for those that don't.=20 >=20 > I think the target has to track this initiator by initiator, and=20 notissue the > new async message to old initiators. This increases the importance of=20 being=20 > able to complete a TMF in the face of an uncooperative third party=20 "Legacy"=20 > initiator.=20 >=20 > > And if you don't downgrade why not state that fast-abort and target=20 scoped=20 > > queues don't go together and simplify the mechanics to a multiple=20 issue TM. > This didn't parse for me - could you explain in more detail?=20 >=20 > Thanks,=20 > --David=20 > ----------------------------------------------------=20 > David L. Black, Senior Technologist=20 > EMC Corporation, 176 South St., Hopkinton, MA 01748=20 > +1 (508) 293-7953 FAX: +1 (508) 293-7786=20 > black=5Fdavid@emc.com Mobile: +1 (978) 394-7754=20 > ----------------------------------------------------=20 >=20 > From: Julian Satran [mailto:Julian=5FSatran@il.ibm.com]=20 > Sent: Thursday, December 28, 2006 5:32 AM > To: Mallikarjun C. > Cc: ips@ietf.org > Subject: Re: [Ips] TMF text with updates >=20 >=20 > Mallikarjun,=20 >=20 > I would consider the text:=20 >=20 > c. MUST leave all active "affected TTTs" (i.e. active TTTs=20 > associated with affected tasks) valid along with any buffer=20 > allocations for the TTTs intact.=20 >=20 > somewhat excessive as it relates too much to implementation. I would > rather say:=20 >=20 > c. MUST leave all active "affected TTTs" (i.e. active TTTs=20 > associated with affected tasks) valid.=20 >=20 > and leave the buffer issue to the implementer (as I have stated=20 > already on this list).=20 >=20 > I also keep thinking (and mildly objecting to) that the whole fast=20 > abort is excesively complex.=20 >=20 > You could achive the same effect by issuing the TM command on every=20 > affected connection.=20 > The third party story is even more puzzling as in order to negotiate > any of the nem TM modes the taget will have to ascertain that all=20 > other initiators support it. I fail to understand how would you=20 > handle downgrading the mode for those that don't. And if you don't=20 > downgrade why not state that fast-abort and target scoped queues=20 > don't go together and simplify the mechanics to a multiple issue TM.=20 >=20 > Thanks,=20 > Julo=20 >=20 > "Mallikarjun C." =20 > 28/12/06 06:41=20 >=20 > To >=20 > ips@ietf.org=20 >=20 > cc >=20 > Subject >=20 > [Ips] TMF text with updates >=20 >=20 >=20 >=20 >=20 >=20 >=20 > Attached is the latest text that incorporates David's proposed=20 > enhancement. Please review and comment. Note especially two=20 > things: new section 4.1.4 that summarizes generic implementation=20 > considerations for both "clarified" and "updated" semantics, the=20 > changed text in 4.1.2 that says "MAY wait for ....target transfer=20 > tags.....from third-party initiators" from the previous blanket MUST. >=20 > Mallikarjun >=20 >=20 >=20 > 4.1.2 Clarified multi-task abort semantics > All iSCSI implementations MUST support the protocol behavior defined > in this section as the default behavior. The execution of ABORT=20 > TASK SET, CLEAR TASK SET, LOGICAL UNIT RESET, TARGET WARM RESET, and > TARGET COLD RESET TMF Requests consists of the following sequence of > actions in the specified order on the specified party.=20 > The initiator iSCSI layer: > a. MUST continue to respond to each TTT received for the affected tasks. = > b. Should receive any responses that the target may provide for some > tasks among the affected tasks (may process them as usual because=20 > they are guaranteed to have chronologically originated prior to the=20 > TMF response).=20 > c. Should receive the TMF Response concluding all the tasks in the=20 > set of affected tasks.=20 >=20 > The target iSCSI layer: > a. MUST wait for currently valid target transfer tags of the=20 > affected tasks from the issuing initiator to be responded to. MAY=20 > wait for responses on currently valid target transfer tags of the=20 > affected tasks from third-party initiators. > b. MUST wait (concurrent with the wait in Step.a) for all commands=20 > of the affected tasks to be received based on the CmdSN ordering.=20 > SHOULD NOT wait for new commands on third-party affected sessions -=20 > only the instantiated tasks have to be considered for the purpose of > determining the affected tasks. In the case of target-scoped=20 > requests (i.e. TARGET WARM RESET and TARGET COLD RESET), all the=20 > commands that are not yet received on the issuing session in the=20 > command stream however can be considered to have been received with=20 > no command waiting period - i.e. the entire CmdSN space up to the=20 > CmdSN of the task management function can be "plugged". > c. MUST propagate the TMF request to and receive the response from=20 > the target SCSI layer.=20 > d. MUST address the Response Fence flag on the TMF Response on=20 > issuing session as defined in 3.3.2. > e. MUST address the Response Fence flag on the first post-TMF=20 > Response on third-party sessions as defined in 3.3.2. If some tasks > originate from non-iSCSI I=5FT=5FL nexuses then the means by which the=20 > target ensures that all affected tasks have returned their status to > the initiator are defined by the specific non-iSCSI transport=20 protocol(s). > Implementation note: Technically, the TMF servicing is complete in=20 > Step.d. Data transfers corresponding to terminated tasks may=20 > however still be in progress on third-party iSCSI sessiosn even at=20 > the end of Step.e. TMF Response MUST NOT be sent by the target=20 > iSCSI layer before the end of Step.d, and MAY be sent at the end of=20 > Step.d despite these outstanding Data transfers until after Step.e. >=20 > 4.1.3 Updated multi-task abort semantics > Protocol behavior defined in this section MUST be implemented by all > iSCSI implementations complying with this document. Protocol=20 > behavior defined in this section MUST be exhibited by iSCSI=20 > implementations on an iSCSI session when they negotiate the=20 > TaskReporting (section 9.1) key to ?FastAbort? on that session. The > execution of ABORT TASK SET, CLEAR TASK SET, LOGICAL UNIT RESET,=20 > TARGET WARM RESET, and TARGET COLD RESET TMF Requests consists of=20 > the following sequence of actions in the specified order on the=20 > specified party.=20 > The initiator iSCSI layer: > a. MUST NOT send any more Data-Out PDUs for affected tasks on the=20 > issuing connection of the issuing iSCSI session once the TMF is sent > to the target. > b. Should receive any responses that the target may provide for some > tasks among the affected tasks (may process them as usual because=20 > they are guaranteed to have chronologically originated prior to the=20 > TMF response). > c. MUST respond to Async Message PDU with AsyncEvent=3D5 as defined in > section 8.1. > d. Should receive the TMF Response concluding all the tasks in the=20 > set of affected tasks. >=20 > The target iSCSI layer: > a. MUST wait for all commands of the affected tasks to be received=20 > based on the CmdSN ordering on the issuing session. SHOULD NOT wait > for new commands on third-party affected sessions - only the=20 > instantiated tasks have to be considered for the purpose of=20 > determining the affected tasks. In the case of target-scoped=20 > requests (i.e. TARGET WARM RESET and TARGET COLD RESET), all the=20 > commands that are not yet received on the issuing session in the=20 > command stream however can be considered to have been received with=20 > no command waiting period - i.e. the entire CmdSN space up to the=20 > CmdSN of the task management function can be "plugged". > b. MUST propagate the TMF request to and receive the response from=20 > the target SCSI layer.=20 > c. MUST leave all active "affected TTTs" (i.e. active TTTs=20 > associated with affected tasks) valid along with any buffer=20 > allocations for the TTTs intact. > d. MUST generate an Asynchronous Message PDU with AsyncEvent=3D5=20 > (section 8.1) on: > i) each connection of each third-party session that at least one=20 > affected task is allegiant to, and > ii) each connection except the issuing connection of the issuing=20 > session that has at least one allegiant affected task. > If there are multiple affected LUs (say due to a target reset), then > one Async Message PDU MUST be sent for each such LU on each=20 > connection that has at least one allegiant affected task. > e. MUST address the Response Fence flag on the TMF Response on=20 > issuing session as defined in 3.3.2. > f. MUST address the Response Fence flag on the first post-TMF=20 > Response on third-party sessions as defined in 3.3.2. If some tasks=20 > originate from non-iSCSI I=5FT=5FL nexuses then the means by which the=20 > target ensures that all affected tasks have returned their status to > the initiator are defined by the specific non-iSCSI transport=20 protocol(s). > g. MUST free up the affected TTTs (and STags, if applicable) and the > corresponding buffers once it receives the associated Nop-Out=20 > acknowledgement that the initiator generated in response to the=20 > Async Message.=20 > Implementation note: Technically, the TMF servicing is complete in=20 > Step.e. Data transfers corresponding to terminated tasks may=20 > however still be in progress even at the end of Step.f. TMF=20 > Response MUST NOT be sent by the target iSCSI layer before the end=20 > of Step.e, and MAY be sent at the end of Step.e despite these=20 > outstanding Data transfers until Step.g. Step.g specifies an event=20 > to free up any such resources that may have been reserved to support > outstanding data transfers.=20 > 4.1.3.1 Clearing effects update > Appendix F.1 of [RFC3720] specifies the clearing effects of target=20 > and LU resets on ?Incomplete TTTs? as ?Y?. This meant that a target > warm reset or a target cold reset or an LU reset would clear the=20 > active TTTs upon completion. The TaskReporting=3DFastAbort (section=20 > 9.1) semantics defined by this section however do not guarantee that > the active TTTs are cleared by the end of the reset operations. In=20 > fact, the new semantics are designed to allow clearing the TTTs in a > ?lazy? fashion after the TMF Response is delivered. Thus, when=20 > TaskReporting=3DFastAbort is operational on a session, the clearing=20 > effects of reset operations on ?Incomplete TTTs? is ?N?.=20 > 4.1.4 Implementation considerations > Both in clarified semantics (section 4.1.2) and updated semantics=20 > (section 4.1.3), there may be outstanding data transfers even after=20 > the TMF completion is reported on the issuing session. In the case=20 > of iSCSI/iSER [iSER], these would be tagged data transfers for STags > not owned by any active tasks. Whether or not real buffers support=20 > these data transfers is implementation-dependent. However, the data > transfers logically MUST be silently discarded by the target iSCSI=20 > layer in all cases. A target MAY, on an implementation-defined=20 > internal timeout, also choose to drop the connections on which it=20 > did not receive the expected Data-out sequences (section 4.1.2) or=20 > Nop-Out acknowledgements (section 4.1.3) so as to reclaim the=20 > associated buffer, STag and TTT resources as appropriate. >=20 >=20 > ----- Original Message ---- > From: "Black=5FDavid@emc.com" > To: Black=5FDavid@emc.com; cb=5Fmallikarjun@yahoo.com; ips@ietf.org > Sent: Wednesday, December 20, 2006 2:33:43 PM > Subject: RE: [Ips] Implementer's Guide - Task Management Issue >=20 >=20 > > Let's try this line of reasoning - the target issues the Nop-Out, now > when > > can it free the resources? Answer: > > - The Nop-In response comes back, OR > > - The connection times out and is torn down. > > Now, what if the Nop-Out is not issued - what does the target wait for > to > > free the resources? Answer: > > - The transfers complete, OR > > - The connection times out and is torn down.=20 > > Those look similar enough at the target (the worst case is the same - > the > > resources are tied up until an uncooperative initiator times out) that > > I don't see the harm in allowing the early TMF return without the new > > key. The clear distinction is that the first two bullets are > different; > > if the new key is not negotiated, the target has to wait for the > transfers > > to complete; the new key and the Nop-Out are necessary to walk away > earlier > > when the initiator involved is able to continue the transfers. >=20 > That got slightly twisted - what it should have talked about was the > target > issuing the new Async Message and the Nop-Out response coming back. >=20 > Thanks, > --David > ---------------------------------------------------- > David L. Black, Senior Technologist > EMC Corporation, 176 South St., Hopkinton, MA 01748 > +1 (508) 293-7953 FAX: +1 (508) 293-7786 > black=5Fdavid@emc.com Mobile: +1 (978) 394-7754 > ---------------------------------------------------- >=20 > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around=20 > http://mail.yahoo.com=20 >=20 > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F > Ips mailing list > Ips@ietf.org > https://www1.ietf.org/mailman/listinfo/ips > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F > Ips mailing list > Ips@ietf.org > https://www1.ietf.org/mailman/listinfo/ips >=20 >=20 > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around=20 > http://mail.yahoo.com =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F > Ips mailing list > Ips@ietf.org > https://www1.ietf.org/mailman/listinfo/ips --=_alternative 0049FD42C2257256_= Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable
Mallikarjun,
My reading was slightly different as bellow

"Mallikarjun C." <cb=5Fmallikarjun@yaho= o.com> wrote on 29/12/2006 23:42:09:

> David and Julian,
>
> Just to be clear on the semantics:
>
> "Fast abort" =3D early reporting of TMF completion despite outstandingtransfers
>
> RFC 3720          Not allowed for issuing session, Not allowed for
> third-party sessions
>
RFC3270 pays only lip-service to third party sessions (there is little you can do beside it.

> IG (Last Call):    
> FastMultiTaskAbort !=3DYes
>                            Same as RFC3720

I would clarify/correct it to say that it is allowed for third party but I can go for your interpretation
 
> FastMultiTaskAbort =3DYes                        
>                           Allowed for issuing session, Allowed for
> third-party sessions

See above

> Latest updates:  
> TaskReporting !=3DFastAbort
>                            Not allowed for issuing session, Allowed
> for third-party sessions
> TaskReporting=3DFastAbort
>                           Allowed for issuing session, Allowed for
> third-party sessions
>

If the mechanics is TM then as soon as TM rsponses are collected.

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

I agree except that I would say that the effects on initiators other than the issuing may be unexpected if they use a mechanism with different semantics.

> Mallikarjun
>
>
>

> ----- Original Message ----
> From: "Black=5FDavid@emc.com" <Black=5FDavid@emc.com><= br> > To: Julian=5FSatran@il.ibm.com
> Cc: ips@ietf.org
> Sent: Friday, December 29, 2006 9:45:25 AM
> Subject: RE: [Ips] TMF text with updates
> Julian,
>  
> I'm not sure I completely understand what you wrote, but if you're
> suggesting that for a TMF that affects tasks from multiple initiators:
> - Fast abort (early termination of data transfe= rs) is used for the sending
>     initiator.
> - The existing 3270 abort mechanism is used with other initiators, with
>     the update that the TMF response does not have to wait for data transfer
>     completion.
> I think that suggestion is reasonable, and it actually helps with the use
> case that started this (3rd party initiator is dead).  The draft text would
> need to change to allow this (right now it mand= ates fast abort in all cases
> if the key is negotiated to support it)<= /tt>
>  
> I'm not sure how target-scoped queues enter into this.
>  
> Thanks,
> --David
> -----------------------------------------------= -----
> David L. Black, Senior Technologist
> EMC Corporation, 176 South St., Hopkinton, MA  01748
> +1 (508) 293-7953             FAX: +1 (508) 293-7786
> black=5Fdavid@emc.com        Mobile: +1 (978) 394-= 7754
> ----------------------------------------------------
>
> From: Julian Satran [mailto:Julian=5FSatran@il.ibm.com]
> Sent: Friday, December 29, 2006 6:16 AM
> To: Black, David
> Cc: cb=5Fmallikarjun@yahoo.com; ips@ietf.org
> Subject: RE: [Ips] TMF text with updates
>
> David,
>
> My point was that we can solve the TM issue only for a single
> initiator. So besides puting the burden on SCSI to cleanly finish
> other and advise that fast solutions really work if there are no
> target scoped queues there is little we can do. And if we limit
> ourselves to a single initiator the multiple TM solution is a
> simpler (and basically does not deviate from 3270).  If you consi= der
> how software stacks are layered I assume that some clever
> implementers have figured that already (and did it).
>
> Regards,
> Julo
>

>
> Black=5FDavid@emc.com
> 28/12/06 21:54
>
> To
>
> Julian Satran/Haifa/IBM@IBMIL, <cb=5Fmallikarjun@yahoo.com>
>
> cc
>
> <ips@ietf.org>
>
> Subject
>
> RE: [Ips] TMF text with updates
>
>
>
>
> I agree with Julian that we should avoid discussing "buffer alloc= ations" and
> the like, even though we know that something like that has to happen in at
> least iSER implementations.  A general discussion of "resour= ces" works.
>  
> > You could achive the same effect by issuing the TM command on
> every affected connection.
>  
> Not for TMF's that affect commands from other initiators.  Also, asking the
> target to coordinate receipt of the TM command on every connection in a
> multi-connection session is also a bit much.
>  
> > The third party story is even more puzzling as in order to negoti= ate any of
> > the new TM modes the taget will have to ascertain that all other initiators
> > support it. I fail to understand how would you handle downgrading the mode
> > for those that don't.
>  
> I think the target has to track this initiator by initiator, and notis= sue the
> new async message to old initiators.  This increases the importan= ce of being
> able to complete a TMF in the face of an uncooperative third party "Legacy"
> initiator.
>  
> > And if you don't downgrade why not state that fast-abort and target scoped
> > queues don't go together and simplify the mechanics to a multiple issue TM.
> This didn't parse for me - could you explain in more detail?
>  
> Thanks,
> --David
> -----------------------------------------------= -----
> David L. Black, Senior Technologist
> EMC Corporation, 176 South St., Hopkinton, MA  01748
> +1 (508) 293-7953             FAX: +1 (508) 293-7786
> black=5Fdavid@emc.com        Mobile: +1 (978) 394-= 7754
> ----------------------------------------------------
>
> From: Julian Satran [mailto:Julian=5FSatran@il.ibm.com]
> Sent: Thursday, December 28, 2006 5:32 AM
> To: Mallikarjun C.
> Cc: ips@ietf.org
> Subject: Re: [Ips] TMF text with updates
>
>
> Mallikarjun,
>
> I would consider the text:
>
> c. MUST leave all active "affected TTTs" (i.e. active TTTs
> associated with affected tasks) valid along with any buffer
> allocations for the TTTs intact.
>
> somewhat excessive as it relates too much to implementation. I would > rather say:
>
> c. MUST leave all active "affected TTTs" (i.e. active TTTs
> associated with affected tasks) valid.
>
> and leave the buffer issue to the implementer (as I have stated
> already on this list).
>
> I also keep thinking (and mildly  objecting to) that the whole fast
> abort is excesively complex.
>
> You could achive the same effect by issuing the TM command on every
> affected connection.
> The third party story is even more puzzling as in order to negotiate > any of the nem TM modes the taget will have to ascertain that all
> other initiators support it. I fail to understand how would you
> handle downgrading the mode for those that don't. And if you don't
> downgrade why not state that fast-abort and target scoped queues
> don't go together and simplify the mechanics to a multiple issue TM.
>
> Thanks,
> Julo

>
> "Mallikarjun C." <cb=5Fmallikarjun@yahoo.com> <= /tt>
> 28/12/06 06:41
>
> To
>
> ips@ietf.org
>
> cc
>
> Subject
>
> [Ips] TMF text with updates
>
>

>
>
>
>
>
> Attached is the latest text that incorporates David's proposed
> enhancement.  Please review and comment.  Note especially two
> things: new section 4.1.4 that summarizes generic implementation
> considerations for both "clarified" and "updated" semantics, the
> changed text in 4.1.2 that says "MAY wait for ....target transfer
> tags.....from third-party initiators" from the previous blanket MUST.
>
> Mallikarjun
>
>
>
> 4.1.2 Clarified multi-task abort semantics
> All iSCSI implementations MUST support the protocol behavior defined > in this section as the default behavior.  The execution of ABORT
> TASK SET, CLEAR TASK SET, LOGICAL UNIT RESET, TARGET WARM RESET, and > TARGET COLD RESET TMF Requests consists of the following sequence of
> actions in the specified order on the specified party.
> The initiator iSCSI layer:
> a. MUST continue to respond to each TTT received for the affected tasks.
> b. Should receive any responses that the target may provide for some > tasks among the affected tasks (may process them as usual because
> they are guaranteed to have chronologically originated prior to the
> TMF response).
> c. Should receive the TMF Response concluding all the tasks in the
> set of affected tasks.
>
> The target iSCSI layer:
> a. MUST wait for currently valid target transfer tags of the
> affected tasks from the issuing initiator to be responded to.  MAY
> wait for responses on currently valid target transfer tags of the
> affected tasks from third-party initiators.
> b. MUST wait (concurrent with the wait in Step.a) for all commands
> of the affected tasks to be received based on the CmdSN ordering.  
> SHOULD NOT wait for new commands on third-party affected sessions -
> only the instantiated tasks have to be considered for the purpose of
> determining the affected tasks.  In the case of target-scoped
> requests (i.e. TARGET WARM RESET and TARGET COLD RESET), all the
> commands that are not yet received on the issuing session in the
> command stream however can be considered to have been received with
> no command waiting period - i.e. the entire CmdSN space up to the
> CmdSN of the task management function can be "plugged".
> c. MUST propagate the TMF request to and receive the response from
> the target SCSI layer.
> d. MUST address the Response Fence flag on the TMF Response on
> issuing session as defined in 3.3.2.
> e. MUST address the Response Fence flag on the first post-TMF
> Response on third-party sessions as defined in 3.3.2.  If some tasks
> originate from non-iSCSI I=5FT=5FL nexuses then the means by which the
> target ensures that all affected tasks have returned their status to
> the initiator are defined by the specific non-iSCSI transport protocol= (s).
> Implementation note: Technically, the TMF servicing is complete in
> Step.d.  Data transfers corresponding to terminated tasks may
> however still be in progress on third-party iSCSI sessiosn even at
> the end of Step.e.  TMF Response MUST NOT be sent by the target
> iSCSI layer before the end of Step.d, and MAY be sent at the end of
> Step.d despite these outstanding Data transfers until after Step.e.
>
> 4.1.3 Updated multi-task abort semantics
> Protocol behavior defined in this section MUST be implemented by all > iSCSI implementations complying with this document.  Protocol
> behavior defined in this section MUST be exhibited by iSCSI
> implementations on an iSCSI session when they negotiate the
> TaskReporting (section 9.1) key to “FastAbort” on that ses= sion.  The
> execution of ABORT TASK SET, CLEAR TASK SET, LOGICAL UNIT RESET,
> TARGET WARM RESET, and TARGET COLD RESET TMF Requests consists of
> the following sequence of actions in the specified order on the
> specified party.
> The initiator iSCSI layer:
> a. MUST NOT send any more Data-Out PDUs for affected tasks on the
> issuing connection of the issuing iSCSI session once the TMF is sent > to the target.
> b. Should receive any responses that the target may provide for some > tasks among the affected tasks (may process them as usual because
> they are guaranteed to have chronologically originated prior to the
> TMF response).
> c. MUST respond to Async Message PDU with AsyncEvent=3D5 as defined in
> section 8.1.
> d. Should receive the TMF Response concluding all the tasks in the
> set of affected tasks.
>
> The target iSCSI layer:
> a. MUST wait for all commands of the affected tasks to be received
> based on the CmdSN ordering on the issuing session.  SHOULD NOT wait
> for new commands on third-party affected sessions - only the
> instantiated tasks have to be considered for the purpose of
> determining the affected tasks.  In the case of target-scoped
> requests (i.e. TARGET WARM RESET and TARGET COLD RESET), all the
> commands that are not yet received on the issuing session in the
> command stream however can be considered to have been received with
> no command waiting period - i.e. the entire CmdSN space up to the
> CmdSN of the task management function can be "plugged".
> b. MUST propagate the TMF request to and receive the response from
> the target SCSI layer.
> c. MUST leave all active "affected TTTs" (i.e. active TTTs
> associated with affected tasks) valid along with any buffer
> allocations for the TTTs intact.
> d. MUST generate an Asynchronous Message PDU with AsyncEvent=3D5
> (section 8.1) on:
> i) each connection of each third-party session that at least one
> affected task is allegiant to, and
> ii) each connection except the issuing connection of the issuing
> session that has at least one allegiant affected task.
> If there are multiple affected LUs (say due to a target reset), then > one Async Message PDU MUST be sent for each such LU on each
> connection that has at least one allegiant affected task.
> e. MUST address the Response Fence flag on the TMF Response on
> issuing session as defined in 3.3.2.
> f. MUST address the Response Fence flag on the first post-TMF
> Response on third-party sessions as defined in 3.3.2. If some tasks
> originate from non-iSCSI I=5FT=5FL nexuses then the means by which the
> target ensures that all affected tasks have returned their status to
> the initiator are defined by the specific non-iSCSI transport protocol= (s).
> g. MUST free up the affected TTTs (and STags, if applicable) and the > corresponding buffers once it receives the associated Nop-Out
> acknowledgement that the initiator generated in response to the
> Async Message.  
> Implementation note: Technically, the TMF servicing is complete in
> Step.e.  Data transfers corresponding to terminated tasks may
> however still be in progress even at the end of Step.f.  TMF
> Response MUST NOT be sent by the target iSCSI layer before the end
> of Step.e, and MAY be sent at the end of Step.e despite these
> outstanding Data transfers until Step.g.  Step.g specifies an event
> to free up any such resources that may have been reserved to support > outstanding data transfers.  
> 4.1.3.1 Clearing effects update
> Appendix F.1 of [RFC3720] specifies the clearing effects of target
> and LU resets on “Incomplete TTTs” as “Y”. &nb= sp;This meant that a target
> warm reset or a target cold reset or an LU reset would clear the
> active TTTs upon completion.  The TaskReporting=3DFastAbort (sect= ion
> 9.1) semantics defined by this section however do not guarantee that > the active TTTs are cleared by the end of the reset operations.  = In
> fact, the new semantics are designed to allow clearing the TTTs in a
> “lazy” fashion after the TMF Response is delivered.  = Thus, when
> TaskReporting=3DFastAbort is operational on a session, the clearing
> effects of reset operations on “Incomplete TTTs” is “= ;N”.  
> 4.1.4 Implementation considerations
> Both in clarified semantics (section 4.1.2) and updated semantics
> (section 4.1.3), there may be outstanding data transfers even after
> the TMF completion is reported on the issuing session.  In the case
> of iSCSI/iSER [iSER], these would be tagged data transfers for STags > not owned by any active tasks.  Whether or not real buffers suppo= rt
> these data transfers is implementation-dependent.  However, the data
> transfers logically MUST be silently discarded by the target iSCSI
> layer in all cases.  A target MAY, on an implementation-defined
> internal timeout, also choose to drop the connections on which it
> did not receive the expected Data-out sequences (section 4.1.2) or
> Nop-Out acknowledgements (section 4.1.3) so as to reclaim the
> associated buffer, STag and TTT resources as appropriate.
>
>
> ----- Original Message ----
> From: "Black=5FDavid@emc.com" <Black=5FDavid@emc.com><= br> > To: Black=5FDavid@emc.com; cb=5Fmallikarjun@yahoo.com; ips@ietf.org
> Sent: Wednesday, December 20, 2006 2:33:43 PM
> Subject: RE: [Ips] Implementer's Guide - Task Management Issue
>
>
> > Let's try this line of reasoning - the target issues the Nop-Out, now
> when
> > can it free the resources?  Answer:
> >     - The Nop-In response comes back, OR
> >     - The connection times out and is torn down.
> > Now, what if the Nop-Out is not issued - what does the target wait for
> to
> > free the resources?  Answer:
> >     - The transfers complete, OR
> >     - The connection times out and is torn down.
> > Those look similar enough at the target (the worst case is the same -
> the
> > resources are tied up until an uncooperative initiator times out) that
> > I don't see the harm in allowing the early TMF return without the new
> > key.  The clear distinction is that the first two bullets are
> different;
> > if the new key is not negotiated, the target has to wait for the
> transfers
> > to complete; the new key and the Nop-Out are necessary to walk away
> earlier
> > when the initiator involved is able to continue the transfers.
>
> That got slightly twisted - what it should have talked about was the > target
> issuing the new Async Message and the Nop-Out response coming back.
>
> Thanks,
> --David
> ----------------------------------------------------
> David L. Black, Senior Technologist
> EMC Corporation, 176 South St., Hopkinton, MA  01748
> +1 (508) 293-7953             FAX: +1 (508) 293-7786
> black=5Fdavid@emc.com        Mobile: +1 (978) 394-= 7754
> ----------------------------------------------------
>
> =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
>
> =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
> Ips mailing list
> Ips@ietf.org
> https://www1.ietf.org/mailman/listinfo/ips
> =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F
> Ips mailing list
> Ips@ietf.org
> https://www1.ietf.org/mailman/listinfo/ips
>
>
> =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F
> Do You Yahoo!?
> Tired of spam? Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F
> Ips mailing list
> Ips@ietf.org
> https://www1.ietf.org/mailman/listinfo/ips
 --=_alternative 0049FD42C2257256_=-- --===============1624554507== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============1624554507==-- From ips-bounces@ietf.org Mon Jan 01 08:54:17 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1NcD-0006XH-8d; Mon, 01 Jan 2007 08:54:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1NcC-0006W6-8N for ips@ietf.org; Mon, 01 Jan 2007 08:54:12 -0500 Received: from imf25aec.mail.bellsouth.net ([205.152.59.73]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H1NcA-0000II-U0 for ips@ietf.org; Mon, 01 Jan 2007 08:54:12 -0500 Received: from ibm69aec.bellsouth.net ([74.245.52.54]) by imf25aec.mail.bellsouth.net with ESMTP id <20070101135405.LXIS21237.imf25aec.mail.bellsouth.net@ibm69aec.bellsouth.net> for ; Mon, 1 Jan 2007 08:54:05 -0500 Received: from IVVTDKV0981 ([74.245.52.54]) by ibm69aec.bellsouth.net with SMTP id <20070101135405.HXBX14910.ibm69aec.bellsouth.net@IVVTDKV0981>; Mon, 1 Jan 2007 08:54:05 -0500 Message-ID: <000b01c72dac$4f6bacf0$01faa8c0@ivivity.com> From: "Eddy Quicksall" To: , References: Subject: Re: [Ips] iSCSI Implementer's Guide - WG Last Call status Date: Mon, 1 Jan 2007 08:54:08 -0500 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ips-bounces@ietf.org Actually I didn't want to discourage targets from checking but to point out that checking is not required unless the RFC specifically requires it. The note could in fact encourage checking where performance is not affected. Eddy ----- Original Message ----- From: To: Sent: Thursday, December 28, 2006 3:27 PM Subject: [Ips] iSCSI Implementer's Guide - WG Last Call status The Working Group Last Call on this draft nominally ended on December 18th, but there was no reason to treat that as a hard cutoff. I am now ending the WG Last Call on this draft, although list discussion of issues should be continued. There have been two issues raised during this WGLC: (1) Task Management - how to deal with uncooperative third- party initiators. This issue has been resolved on the list. (2) Target checks - whether to discourage targets from checking for initiator mistakes that the target can tolerate. At the moment, I think the "rough consensus" of the WG is not to do this - if anyone other than Eddy thinks this is important to clarify, they need to speak up promptly after the holidays. The process from here is that Mallikarjun will submit a revised version of the draft in the near future (there are still some details to be worked out on the list). I will be completely out of action (no email) the first two weeks of January, so there will be time for people to check for problems/issues/etc. I will check the revised draft and send it to Lars with a request for RFC publication sometime in the second half of January (probably during the week of January 22nd). Thanks, --David ---------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From wheqzsg@t-dialin.net Mon Jan 01 15:01:47 2007 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1TLv-0004r3-JC for ips-archive@lists.ietf.org; Mon, 01 Jan 2007 15:01:47 -0500 Received: from pd957ff8d.dip.t-dialin.net ([217.87.255.141] helo=pD957CE0A.dip.t-dialin.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H1TLu-0006GU-5m for ips-archive@lists.ietf.org; Mon, 01 Jan 2007 15:01:47 -0500 From: "Peace Peony" To: ips-archive@lists.ietf.org Subject: Play and Win. Date: Mon, 1 Jan 2007 21:01:49 -0100 MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_000_0002_01C72DE8.0E1F1890" X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: Acct6A4fEP392U1/S92wlp8MEnbrsQ== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Message-Id: <03260DCC187F8D4.83E07827A8@t-dialin.net> X-Spam-Score: 4.8 (++++) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 ------=_NextPart_000_0002_01C72DE8.0E1F1890 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Online Casino

2210+ games

1 Hour Free Play
$500 FREE

Click here to play

------=_NextPart_000_0002_01C72DE8.0E1F1890-- From ips-bounces@ietf.org Mon Jan 01 20:06:08 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1Y69-0003cj-Mq; Mon, 01 Jan 2007 20:05:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1Y68-0003cd-AR for ips@ietf.org; Mon, 01 Jan 2007 20:05:48 -0500 Received: from mail-gw3.adaptec.com ([216.52.22.36]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H1Y64-0006nE-W4 for ips@ietf.org; Mon, 01 Jan 2007 20:05:47 -0500 Received: from aime2k302.adaptec.com (aime2k302.adaptec.com [10.25.8.48]) by mail-gw3.adaptec.com (Spam Firewall) with ESMTP id DFE00E7C5D; Mon, 1 Jan 2007 17:05:32 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ips] iSCSI Implementer's Guide - WG Last Call status Date: Mon, 1 Jan 2007 17:05:30 -0800 Message-ID: <368FBF3D8437A748BA8222526BF9309901229C2F@aime2k302.adaptec.com> In-Reply-To: <000b01c72dac$4f6bacf0$01faa8c0@ivivity.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ips] iSCSI Implementer's Guide - WG Last Call status Thread-Index: AcctrHnhoGtw7FHjQ1KCyh1UfNlxaQAVzpVQ From: "Sandars, Ken" To: "Eddy Quicksall" , , X-Virus-Scanned: by Barracuda Spam Firewall at adaptec.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Cc: X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ips-bounces@ietf.org Happy New Gregorian Year, I support Eddy's request for some words to suggest that target implementations should be allowed to handle initiator errors in a manner which does not damage the target behaviour. Target behaviour should be evaluated by its transmissions on the wire and via data integrity tests. Test suites and protocol analysers should not assume what the target's actions will be as a result of illegal initiator behaviour unless explicitly defined in RFC3720. For example, say an initiator issues a Logout Request PDU with reason code 0 (close the session), but sets the CID field to the current connection. The target MAY process this command as though there is no error on the part of the initiator. A test suite or protocol analyser MUST NOT penalise the target if it does so. Another example is an initiator which sets either the W or/and R bits in a SCSI Command Request PDU which has an Expected Data Transfer Length of 0. Finally, a test-suite which sets a non-zero value in reserved fields for initiator PDUs should not expect the target to check these values. Clearly a target which performs additional checking of the initiator's PDUs is likely to be more robust when faced with reception errors when not using digests. Cheers Ken -----Original Message----- From: Eddy Quicksall [mailto:Quicksall_iSCSI@Bellsouth.net]=20 Sent: Tuesday, 2 January 2007 00:54 To: Black_David@emc.com; ips@ietf.org Subject: Re: [Ips] iSCSI Implementer's Guide - WG Last Call status Actually I didn't want to discourage targets from checking but to point out that checking is not required unless the RFC specifically requires it. The note could in fact encourage checking where performance is not affected. Eddy ----- Original Message ----- From: To: Sent: Thursday, December 28, 2006 3:27 PM Subject: [Ips] iSCSI Implementer's Guide - WG Last Call status The Working Group Last Call on this draft nominally ended on December 18th, but there was no reason to treat that as a hard cutoff. I am now ending the WG Last Call on this draft, although list discussion of issues should be continued. There have been two issues raised during this WGLC: (1) Task Management - how to deal with uncooperative third- party initiators. This issue has been resolved on the list. (2) Target checks - whether to discourage targets from checking for initiator mistakes that the target can tolerate. At the moment, I think the "rough consensus" of the WG is not to do this - if anyone other than Eddy thinks this is important to clarify, they need to speak up promptly after the holidays. The process from here is that Mallikarjun will submit a revised version of the draft in the near future (there are still some details to be worked out on the list). I will be completely out of action (no email) the first two weeks of January, so there will be time for people to check for problems/issues/etc. I will check the revised draft and send it to Lars with a request for RFC publication sometime in the second half of January (probably during the week of January 22nd). Thanks, --David ---------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips=20 _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Tue Jan 02 14:36:44 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1pR2-0005le-Sl; Tue, 02 Jan 2007 14:36:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1pR0-0005lW-Pm for ips@ietf.org; Tue, 02 Jan 2007 14:36:30 -0500 Received: from web51915.mail.yahoo.com ([206.190.48.78]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H1pQw-0008Us-3i for ips@ietf.org; Tue, 02 Jan 2007 14:36:30 -0500 Received: (qmail 63015 invoked by uid 60001); 2 Jan 2007 19:36:18 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type; b=GKngk8iLQbKxBu35d/HpQBPInwMrZ+BZElbvHeILfAsrkmDGjEYH2locEr0U4EEL8RRhf1CAfb0Ixrqe22FZSBh4UTBpp7ISfgWO5T9lYnr/tpDegZCg+ruojPn63KOojgewPiLy2qgM+Dvgx5cNXHaZwVMGiL7XqoAs9ly3tzo= ; Message-ID: <20070102193618.63013.qmail@web51915.mail.yahoo.com> Received: from [15.227.217.76] by web51915.mail.yahoo.com via HTTP; Tue, 02 Jan 2007 11:36:18 PST Date: Tue, 2 Jan 2007 11:36:18 -0800 (PST) From: "Mallikarjun C." Subject: Re: [Ips] TMF text with updates To: ips@ietf.org MIME-Version: 1.0 X-Spam-Score: 0.5 (/) X-Scan-Signature: 85fe3afc5d9560be77aa81420052017a X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1199327214==" Errors-To: ips-bounces@ietf.org --===============1199327214== Content-Type: multipart/alternative; boundary="0-1074182379-1167766578=:56146" --0-1074182379-1167766578=:56146 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Julian,=0A=0AYour primary concern appears to be around unpredictability of = interactions between issuing and third-party sessions.=0A=0AIssuing and thi= rd-party sessions can assume one of three values for TaskReporting: Legacy,= ResponseFence, FastAbort=0A=0AThat makes for 9 combinations of issuing+th= ird-party modes. The homogeneous combinations (Legacy+Legacy, ResponseFenc= e+ResponseFence, FastAbort+FastAbort) I assume are not what you are concern= ed about.=0A=0AThat leaves us with 6 heterogeneous combinations of issuing+= third-party modes. AFAICT, the heterogeneous combinations appear benign as= well, but I am obviously missing something. Of course, whenever ResponseF= ence is not in effect, the inter-connection network skew could deliver the = UAs on any iSCSI session for certain SCSI events (e.g. ACA) in an unpredict= able order, but that is only to be expected (and that's what prompted us to= put in the notion of response fence).=0A=0AWhat would greatly help me is i= f you could identify a specific heterogeneous combination, its unpredictabl= e behavior with updated TMF text and the consequences of such unpredictabil= ity that you think are undesirable.=0A=0AYour secondary concern appears to = be around complexity. As always, I would welcome any suggestions from you = on that front as well.=0A=0AI'll wait until the end of this week before I p= ublish an updated draft revision as David suggested.=0A=0AThanks!=0A=0AMall= ikarjun=0A=0A=0A=0A----- Original Message ----=0AFrom: Julian Satran =0ATo: Mallikarjun C. =0ACc: = ips@ietf.org=0ASent: Monday, January 1, 2007 5:28:14 AM=0ASubject: Re: [Ips= ] TMF text with updates=0A=0A=0AMallikarjun, =0AMy reading was slightly dif= ferent as bellow =0A=0A"Mallikarjun C." wrote on= 29/12/2006 23:42:09:=0A=0A> David and Julian,=0A> =0A> Just to be clear on= the semantics:=0A> =0A> "Fast abort" =3D early reporting of TMF completion= despite outstandingtransfers=0A> =0A> RFC 3720 Not allowed for is= suing session, Not allowed for =0A> third-party sessions=0A> =0ARFC3270 pay= s only lip-service to third party sessions (there is little you can do besi= de it. =0A=0A> IG (Last Call): =0A> FastMultiTaskAbort !=3DYes=0A> = Same as RFC3720 =0A=0AI would clarify/correct it to = say that it is allowed for third party but I can go for your interpretation= =0A =0A> FastMultiTaskAbort =3DYes =0A> = Allowed for issuing session, Allowed for =0A> third-party s= essions =0A=0ASee above =0A=0A> Latest updates: =0A> TaskReporting !=3DFas= tAbort=0A> Not allowed for issuing session, Allo= wed =0A> for third-party sessions =0A> TaskReporting=3DFastAbort=0A> = Allowed for issuing session, Allowed for =0A> third-par= ty sessions =0A> =0A=0AIf the mechanics is TM then as soon as TM rsponses a= re collected. =0A=0A> Before we sanction more combinations of legal behavio= r, let us =0A> analyze why the last two combinations do not address the use= cases =0A> we are concerned about. More combinations mean more complexity= .....=0A> =0A> As far as Julian's reference to "target-scoped" queues, I as= sume it =0A> is about the scope of a task set when TST=3D0. IMHO, iSCSI ne= eds to =0A> offer a reasonable processing model for this case with Clear Ta= sk =0A> Set TMF as well as that of a Logical Reset TMF (which always affect= s=0A> tasks from multiple initiators even if TST=3D1). That is where the = =0A> value of fast abort comes in.=0A> =0A=0AI agree except that I would sa= y that the effects on initiators other than the issuing may be unexpected i= f they use a mechanism with different semantics. =0A=0A> Mallikarjun=0A> = =0A> =0A> =0A=0A> ----- Original Message ----=0A> From: "Black_David@emc.co= m" =0A> To: Julian_Satran@il.ibm.com=0A> Cc: ips@ietf.= org=0A> Sent: Friday, December 29, 2006 9:45:25 AM=0A> Subject: RE: [Ips] T= MF text with updates=0A=0A> Julian, =0A> =0A> I'm not sure I completely u= nderstand what you wrote, but if you're =0A> suggesting that for a TMF that= affects tasks from multiple initiators: =0A> - Fast abort (early terminati= on of data transfers) is used for the sending =0A> initiator. =0A> - Th= e existing 3270 abort mechanism is used with other initiators, with =0A> = the update that the TMF response does not have to wait for data transfer = =0A> completion. =0A> I think that suggestion is reasonable, and it act= ually helps with the use =0A> case that started this (3rd party initiator i= s dead). The draft text would =0A> need to change to allow this (right now= it mandates fast abort in all cases =0A> if the key is negotiated to suppo= rt it) =0A> =0A> I'm not sure how target-scoped queues enter into this. = =0A> =0A> Thanks, =0A> --David =0A> -------------------------------------= --------------- =0A> David L. Black, Senior Technologist =0A> EMC Corporati= on, 176 South St., Hopkinton, MA 01748 =0A> +1 (508) 293-7953 = FAX: +1 (508) 293-7786 =0A> black_david@emc.com Mobile: +1 (978) 394= -7754 =0A> ---------------------------------------------------- =0A> =0A> F= rom: Julian Satran [mailto:Julian_Satran@il.ibm.com] =0A> Sent: Friday, Dec= ember 29, 2006 6:16 AM=0A> To: Black, David=0A> Cc: cb_mallikarjun@yahoo.co= m; ips@ietf.org=0A> Subject: RE: [Ips] TMF text with updates=0A=0A> =0A> Da= vid, =0A> =0A> My point was that we can solve the TM issue only for a singl= e =0A> initiator. So besides puting the burden on SCSI to cleanly finish = =0A> other and advise that fast solutions really work if there are no =0A> = target scoped queues there is little we can do. And if we limit =0A> oursel= ves to a single initiator the multiple TM solution is a =0A> simpler (and b= asically does not deviate from 3270). If you consider=0A> how software sta= cks are layered I assume that some clever =0A> implementers have figured th= at already (and did it). =0A> =0A> Regards, =0A> Julo =0A> =0A=0A> =0A> Bla= ck_David@emc.com =0A> 28/12/06 21:54 =0A> =0A> To =0A> =0A> Julian Satran/H= aifa/IBM@IBMIL, =0A> =0A> cc =0A> =0A> =0A> =0A> Subject =0A> =0A> RE: [Ips] TMF text with updates =0A> =0A>= =0A> =0A> =0A> I agree with Julian that we should avoid discussing "buffer= allocations" and =0A> the like, even though we know that something like th= at has to happen in at =0A> least iSER implementations. A general discussi= on of "resources" works. =0A> =0A> > You could achive the same effect by = issuing the TM command on =0A> every affected connection. =0A> =0A> Not f= or TMF's that affect commands from other initiators. Also, asking the =0A>= target to coordinate receipt of the TM command on every connection in a = =0A> multi-connection session is also a bit much. =0A> =0A> > The third p= arty story is even more puzzling as in order to negotiate any of=0A> > the = new TM modes the taget will have to ascertain that all other initiators=0A>= > support it. I fail to understand how would you handle downgrading the mo= de =0A> > for those that don't. =0A> =0A> I think the target has to track= this initiator by initiator, and notissue the=0A> new async message to old= initiators. This increases the importance of being =0A> able to complete = a TMF in the face of an uncooperative third party "Legacy" =0A> initiator. = =0A> =0A> > And if you don't downgrade why not state that fast-abort and = target scoped =0A> > queues don't go together and simplify the mechanics to= a multiple issue TM.=0A> This didn't parse for me - could you explain in m= ore detail? =0A> =0A> Thanks, =0A> --David =0A> -------------------------= --------------------------- =0A> David L. Black, Senior Technologist =0A> E= MC Corporation, 176 South St., Hopkinton, MA 01748 =0A> +1 (508) 293-7953 = FAX: +1 (508) 293-7786 =0A> black_david@emc.com Mobile: = +1 (978) 394-7754 =0A> ----------------------------------------------------= =0A> =0A> From: Julian Satran [mailto:Julian_Satran@il.ibm.com] =0A> Sent:= Thursday, December 28, 2006 5:32 AM=0A> To: Mallikarjun C.=0A> Cc: ips@iet= f.org=0A> Subject: Re: [Ips] TMF text with updates=0A> =0A> =0A> Mallikarju= n, =0A> =0A> I would consider the text: =0A> =0A> c. MUST leave all active = "affected TTTs" (i.e. active TTTs =0A> associated with affected tasks) vali= d along with any buffer =0A> allocations for the TTTs intact. =0A> =0A> som= ewhat excessive as it relates too much to implementation. I would=0A> rathe= r say: =0A> =0A> c. MUST leave all active "affected TTTs" (i.e. active TTTs= =0A> associated with affected tasks) valid. =0A> =0A> and leave the buffer= issue to the implementer (as I have stated =0A> already on this list). =0A= > =0A> I also keep thinking (and mildly objecting to) that the whole fast = =0A> abort is excesively complex. =0A> =0A> You could achive the same effec= t by issuing the TM command on every =0A> affected connection. =0A> The thi= rd party story is even more puzzling as in order to negotiate=0A> any of th= e nem TM modes the taget will have to ascertain that all =0A> other initiat= ors support it. I fail to understand how would you =0A> handle downgrading = the mode for those that don't. And if you don't =0A> downgrade why not stat= e that fast-abort and target scoped queues =0A> don't go together and simpl= ify the mechanics to a multiple issue TM. =0A> =0A> Thanks, =0A> Julo =0A= =0A> =0A> "Mallikarjun C." =0A> 28/12/06 06:41 = =0A> =0A> To =0A> =0A> ips@ietf.org =0A> =0A> cc =0A> =0A> Subject =0A> =0A= > [Ips] TMF text with updates =0A> =0A> =0A=0A> =0A> =0A> =0A> =0A> =0A> At= tached is the latest text that incorporates David's proposed =0A> enhanceme= nt. Please review and comment. Note especially two =0A> things: new secti= on 4.1.4 that summarizes generic implementation =0A> considerations for bot= h "clarified" and "updated" semantics, the =0A> changed text in 4.1.2 that = says "MAY wait for ....target transfer =0A> tags.....from third-party initi= ators" from the previous blanket MUST.=0A> =0A> Mallikarjun=0A> =0A> =0A> = =0A> 4.1.2 Clarified multi-task abort semantics=0A> All iSCSI implementatio= ns MUST support the protocol behavior defined=0A> in this section as the de= fault behavior. The execution of ABORT =0A> TASK SET, CLEAR TASK SET, LOGI= CAL UNIT RESET, TARGET WARM RESET, and=0A> TARGET COLD RESET TMF Requests c= onsists of the following sequence of=0A> actions in the specified order on = the specified party. =0A> The initiator iSCSI layer:=0A> a. MUST continue t= o respond to each TTT received for the affected tasks. =0A> b. Should recei= ve any responses that the target may provide for some=0A> tasks among the a= ffected tasks (may process them as usual because =0A> they are guaranteed t= o have chronologically originated prior to the =0A> TMF response). =0A> c. = Should receive the TMF Response concluding all the tasks in the =0A> set of= affected tasks. =0A> =0A> The target iSCSI layer:=0A> a. MUST wait for cur= rently valid target transfer tags of the =0A> affected tasks from the issui= ng initiator to be responded to. MAY =0A> wait for responses on currently = valid target transfer tags of the =0A> affected tasks from third-party init= iators.=0A> b. MUST wait (concurrent with the wait in Step.a) for all comma= nds =0A> of the affected tasks to be received based on the CmdSN ordering. = =0A> SHOULD NOT wait for new commands on third-party affected sessions - = =0A> only the instantiated tasks have to be considered for the purpose of= =0A> determining the affected tasks. In the case of target-scoped =0A> req= uests (i.e. TARGET WARM RESET and TARGET COLD RESET), all the =0A> commands= that are not yet received on the issuing session in the =0A> command strea= m however can be considered to have been received with =0A> no command wait= ing period - i.e. the entire CmdSN space up to the =0A> CmdSN of the task m= anagement function can be "plugged".=0A> c. MUST propagate the TMF request = to and receive the response from =0A> the target SCSI layer. =0A> d. MUST a= ddress the Response Fence flag on the TMF Response on =0A> issuing session = as defined in 3.3.2.=0A> e. MUST address the Response Fence flag on the fir= st post-TMF =0A> Response on third-party sessions as defined in 3.3.2. If = some tasks=0A> originate from non-iSCSI I_T_L nexuses then the means by whi= ch the =0A> target ensures that all affected tasks have returned their stat= us to=0A> the initiator are defined by the specific non-iSCSI transport pro= tocol(s).=0A> Implementation note: Technically, the TMF servicing is comple= te in =0A> Step.d. Data transfers corresponding to terminated tasks may = =0A> however still be in progress on third-party iSCSI sessiosn even at =0A= > the end of Step.e. TMF Response MUST NOT be sent by the target =0A> iSCS= I layer before the end of Step.d, and MAY be sent at the end of =0A> Step.d= despite these outstanding Data transfers until after Step.e.=0A> =0A> 4.1.= 3 Updated multi-task abort semantics=0A> Protocol behavior defined in this = section MUST be implemented by all=0A> iSCSI implementations complying with= this document. Protocol =0A> behavior defined in this section MUST be exh= ibited by iSCSI =0A> implementations on an iSCSI session when they negotiat= e the =0A> TaskReporting (section 9.1) key to =93FastAbort=94 on that sessi= on. The=0A> execution of ABORT TASK SET, CLEAR TASK SET, LOGICAL UNIT RESE= T, =0A> TARGET WARM RESET, and TARGET COLD RESET TMF Requests consists of = =0A> the following sequence of actions in the specified order on the =0A> s= pecified party. =0A> The initiator iSCSI layer:=0A> a. MUST NOT send any mo= re Data-Out PDUs for affected tasks on the =0A> issuing connection of the i= ssuing iSCSI session once the TMF is sent=0A> to the target.=0A> b. Should = receive any responses that the target may provide for some=0A> tasks among = the affected tasks (may process them as usual because =0A> they are guarant= eed to have chronologically originated prior to the =0A> TMF response).=0A>= c. MUST respond to Async Message PDU with AsyncEvent=3D5 as defined in=0A>= section 8.1.=0A> d. Should receive the TMF Response concluding all the tas= ks in the =0A> set of affected tasks.=0A> =0A> The target iSCSI layer:=0A> = a. MUST wait for all commands of the affected tasks to be received =0A> bas= ed on the CmdSN ordering on the issuing session. SHOULD NOT wait=0A> for n= ew commands on third-party affected sessions - only the =0A> instantiated t= asks have to be considered for the purpose of =0A> determining the affected= tasks. In the case of target-scoped =0A> requests (i.e. TARGET WARM RESET= and TARGET COLD RESET), all the =0A> commands that are not yet received on= the issuing session in the =0A> command stream however can be considered t= o have been received with =0A> no command waiting period - i.e. the entire = CmdSN space up to the =0A> CmdSN of the task management function can be "pl= ugged".=0A> b. MUST propagate the TMF request to and receive the response f= rom =0A> the target SCSI layer. =0A> c. MUST leave all active "affected TTT= s" (i.e. active TTTs =0A> associated with affected tasks) valid along with = any buffer =0A> allocations for the TTTs intact.=0A> d. MUST generate an As= ynchronous Message PDU with AsyncEvent=3D5 =0A> (section 8.1) on:=0A> i) ea= ch connection of each third-party session that at least one =0A> affected t= ask is allegiant to, and=0A> ii) each connection except the issuing connect= ion of the issuing =0A> session that has at least one allegiant affected ta= sk.=0A> If there are multiple affected LUs (say due to a target reset), the= n=0A> one Async Message PDU MUST be sent for each such LU on each =0A> conn= ection that has at least one allegiant affected task.=0A> e. MUST address t= he Response Fence flag on the TMF Response on =0A> issuing session as defin= ed in 3.3.2.=0A> f. MUST address the Response Fence flag on the first post-= TMF =0A> Response on third-party sessions as defined in 3.3.2. If some task= s =0A> originate from non-iSCSI I_T_L nexuses then the means by which the = =0A> target ensures that all affected tasks have returned their status to= =0A> the initiator are defined by the specific non-iSCSI transport protocol= (s).=0A> g. MUST free up the affected TTTs (and STags, if applicable) and t= he=0A> corresponding buffers once it receives the associated Nop-Out =0A> a= cknowledgement that the initiator generated in response to the =0A> Async M= essage. =0A> Implementation note: Technically, the TMF servicing is comple= te in =0A> Step.e. Data transfers corresponding to terminated tasks may = =0A> however still be in progress even at the end of Step.f. TMF =0A> Resp= onse MUST NOT be sent by the target iSCSI layer before the end =0A> of Step= .e, and MAY be sent at the end of Step.e despite these =0A> outstanding Dat= a transfers until Step.g. Step.g specifies an event =0A> to free up any su= ch resources that may have been reserved to support=0A> outstanding data tr= ansfers. =0A> 4.1.3.1 Clearing effects update=0A> Appendix F.1 of [RFC3720= ] specifies the clearing effects of target =0A> and LU resets on =93Incompl= ete TTTs=94 as =93Y=94. This meant that a target=0A> warm reset or a targe= t cold reset or an LU reset would clear the =0A> active TTTs upon completio= n. The TaskReporting=3DFastAbort (section =0A> 9.1) semantics defined by t= his section however do not guarantee that=0A> the active TTTs are cleared b= y the end of the reset operations. In =0A> fact, the new semantics are des= igned to allow clearing the TTTs in a=0A> =93lazy=94 fashion after the TMF = Response is delivered. Thus, when =0A> TaskReporting=3DFastAbort is operat= ional on a session, the clearing =0A> effects of reset operations on =93Inc= omplete TTTs=94 is =93N=94. =0A> 4.1.4 Implementation considerations=0A> B= oth in clarified semantics (section 4.1.2) and updated semantics =0A> (sect= ion 4.1.3), there may be outstanding data transfers even after =0A> the TMF= completion is reported on the issuing session. In the case =0A> of iSCSI/= iSER [iSER], these would be tagged data transfers for STags=0A> not owned b= y any active tasks. Whether or not real buffers support =0A> these data tr= ansfers is implementation-dependent. However, the data=0A> transfers logic= ally MUST be silently discarded by the target iSCSI =0A> layer in all cases= . A target MAY, on an implementation-defined =0A> internal timeout, also c= hoose to drop the connections on which it =0A> did not receive the expected= Data-out sequences (section 4.1.2) or =0A> Nop-Out acknowledgements (secti= on 4.1.3) so as to reclaim the =0A> associated buffer, STag and TTT resourc= es as appropriate.=0A> =0A> =0A> ----- Original Message ----=0A> From: "Bla= ck_David@emc.com" =0A> To: Black_David@emc.com; cb_mal= likarjun@yahoo.com; ips@ietf.org=0A> Sent: Wednesday, December 20, 2006 2:3= 3:43 PM=0A> Subject: RE: [Ips] Implementer's Guide - Task Management Issue= =0A> =0A> =0A> > Let's try this line of reasoning - the target issues the N= op-Out, now=0A> when=0A> > can it free the resources? Answer:=0A> > - = The Nop-In response comes back, OR=0A> > - The connection times out and= is torn down.=0A> > Now, what if the Nop-Out is not issued - what does the= target wait for=0A> to=0A> > free the resources? Answer:=0A> > - The = transfers complete, OR=0A> > - The connection times out and is torn dow= n. =0A> > Those look similar enough at the target (the worst case is the sa= me -=0A> the=0A> > resources are tied up until an uncooperative initiator t= imes out) that=0A> > I don't see the harm in allowing the early TMF return = without the new=0A> > key. The clear distinction is that the first two bul= lets are=0A> different;=0A> > if the new key is not negotiated, the target = has to wait for the=0A> transfers=0A> > to complete; the new key and the No= p-Out are necessary to walk away=0A> earlier=0A> > when the initiator invol= ved is able to continue the transfers.=0A> =0A> That got slightly twisted -= what it should have talked about was the=0A> target=0A> issuing the new As= ync Message and the Nop-Out response coming back.=0A> =0A> Thanks,=0A> --Da= vid=0A> ----------------------------------------------------=0A> David L. B= lack, Senior Technologist=0A> EMC Corporation, 176 South St., Hopkinton, MA= 01748=0A> +1 (508) 293-7953 FAX: +1 (508) 293-7786=0A> black_= david@emc.com Mobile: +1 (978) 394-7754=0A> ------------------------= ----------------------------=0A> =0A> _____________________________________= _____________=0A> Do You Yahoo!?=0A> Tired of spam? Yahoo! Mail has the be= st spam protection around =0A> http://mail.yahoo.com =0A> =0A> ____________= ___________________________________=0A> Ips mailing list=0A> Ips@ietf.org= =0A> https://www1.ietf.org/mailman/listinfo/ips=0A=0A> ____________________= ___________________________=0A> Ips mailing list=0A> Ips@ietf.org=0A> https= ://www1.ietf.org/mailman/listinfo/ips =0A> =0A> =0A> ______________________= ____________________________=0A> Do You Yahoo!?=0A> Tired of spam? Yahoo! M= ail has the best spam protection around =0A> http://mail.yahoo.com ________= _______________________________________=0A> Ips mailing list=0A> Ips@ietf.o= rg=0A> https://www1.ietf.org/mailman/listinfo/ips=0A=0A____________________= ______________________________=0ADo You Yahoo!?=0ATired of spam? Yahoo! Ma= il has the best spam protection around =0Ahttp://mail.yahoo.com --0-1074182379-1167766578=:56146 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Julian,
=0A
 
=0A
 
= =0A
Issuing and third-party sessions can assume one of three value= s for TaskReporting: Legacy, ResponseFence, FastAbort
=0A
&nb= sp;
=0A
That makes for 9 combinations of  issuing+t= hird-party modes.  The homogeneous combinations (Legacy+Legacy, Respon= seFence+ResponseFence, FastAbort+FastAbort) I assume are not what you are c= oncerned about.
=0A
 
=0A
That leaves us w= ith 6 heterogeneous combinations of issuing+third-party modes.  AFAICT= , the heterogeneous combinations appear benign as well, but I am obviously = missing something.  Of course, whenever ResponseFence is not in effect= , the inter-connection network skew could deliver the UAs on any iSCSI=  session for certain SCSI events (e.g. ACA) in an unpredictable order,= but that is only to be expected (and that's what prompted us to put in the= notion of response fence).
=0A
 
=0A
What= would greatly help me is if you could identify a specific heterogeneous co= mbination, its unpredictable behavior with updated TMF text and the consequ= ences of such unpredictability that you think are undesirable.
=0A 
=0A
Your secondary concern appears to be around = complexity.  As always, I would welcome any suggestions from you on th= at front as well.
=0A
 
=0A
I'll wait unti= l the end of this week before I publish an updated draft revision as David = suggested.
=0A
 
=0A
Thanks!
=0A
 
=0A
Mallikarjun
=0A


 <= /DIV>=0A
----- Original Message ----
From: Julian Satran <Ju= lian_Satran@il.ibm.com>
To: Mallikarjun C. <cb_mallikarjun@yahoo.c= om>
Cc: ips@ietf.org
Sent: Monday, January 1, 2007 5:28:14 AM
S= ubject: Re: [Ips] TMF text with updates


Mallikarjun,
My readin= g was slightly different as bellow

"Malli= karjun C." <cb_mallikarjun@yahoo.com> wrote on 29/12/2006 23:42:09:
> David and Julian,
>
> Just to be clear on the seman= tics:
>
> "Fast abort" =3D early reporting of TMF completion d= espite outstandingtransfers
>
> RFC 3720       =    Not allowed for issuing session, Not allowed for
> thir= d-party sessions
>
RFC3270 pays on= ly lip-service to third party sessions (there is little you can do beside it.

> IG (Last Call):    
> FastMultiTaskAbort= !=3DYes
>                 &n= bsp;          Same as RFC3720

= I would clarify/correct it to say that it is allowed for= third party but I can go for your interpretation
 
> FastMultiTaskAbort =3DYes       &nb= sp;                
>  =                     &nbs= p;   Allowed for issuing session, Allowed for
> third-party ses= sions

See above
=
> Latest updates:  
> TaskReporting !=3DFa= stAbort
>                 &nb= sp;          Not allowed for issuing session, Allowed
> for third-p= arty sessions
> TaskReporting=3DFastAbort
>     &nbs= p;                     Al= lowed for issuing session, Allowed for
> third-party sessions
&g= t;

If the mechanics is TM then as so= on as TM rsponses are collected.

>= ; Before we sanction more combinations of legal behavior, let us
> a= nalyze why the last two combinations do not address the use cases
> = we are concerned about.  More combinations mean more complexity.....>
> As far as Julian's reference to "target-scoped" queues, I a= ssume it
> is about the scope of a task set when TST=3D0.  IMHO= , iSCSI needs to
> offer a reasonable processing model for this case= with Clear Task
> Set TMF as well as that of a Logical Reset TMF (w= hich always affects
> tasks from multiple initiators even if TST=3D1).  Tha= t is where the
> value of fast abort comes in.
> <= BR>
I agree except that I would say that the effects = on initiators other than the issuing may be unexpected if they use a mechan= ism with different semantics.

> M= allikarjun
>
>
>

> ----- Original Message ----
> From: "Black_David@emc.com" <B= lack_David@emc.com>
> To: Julian_Satran@il.ibm.com
> Cc: ips= @ietf.org
> Sent: Friday, December 29, 2006 9:45:25 AM
> Subjec= t: RE: [Ips] TMF text with updates

&g= t; Julian,
>  
<= TT>> I'm not sure I completely understand what you wrote,= but if you're
> suggesting that for = a TMF that affects tasks from multiple initiators:
> - Fast abort = (early termination of data transfers) is used for the sending <= BR>>     initiator.
> - The existing 3270 abort mechanism is used with other ini= tiators, with
>     the upd= ate that the TMF response does not have to wait for data transfer
>     completion.
> I think that suggestion is reasonable, and it actuall= y helps with the use
> case that star= ted this (3rd party initiator is dead).  The draft text would
> need to change to allow this (right now it = mandates fast abort in all cases
> if= the key is negotiated to support it)
&g= t;  
> I'm not sure how target-scoped queues enter in= to this.
>  
> Thanks,
> --Davi= d
> ---------------------------------= -------------------
> David L. Black, Senior Technologist
> E= MC Corporation, 176 South St., Hopkinton, MA  01748
> +1 (508) = 293-7953             FAX: +1 (508) 293-7786 <= BR>> black_david@emc.com        Mobile: +1 (978) 394= -7754
> ---------------------------------------------------- =
>
> From: Julian Satran [mailto:Julia= n_Satran@il.ibm.com]
> Sent: Friday, December 29, 2006 6:16 AM
&g= t; To: Black, David
> Cc: cb_mallikarjun@yahoo.com; ips@ietf.org
&= gt; Subject: RE: [Ips] TMF text with updates

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

>
> Black_David@emc.com
= > 28/12/06 21:54
>
> To
>
> Julian Satran/Haifa/IBM@IBMIL= , <cb_mallikarjun@yahoo.com>
> =
> cc
>
> <ips@ietf.org>
= >
> Subject
>
> RE: [Ips] TMF text with updates
>
>
>
>
> I agree with Julian that we= should avoid discussing "buffer allocations" and
> the like, even t= hough we know that something like that has to happen in at
> least i= SER implementations.  A general discussion of "resources" works.
&= gt;  
> > You could achive the same effect by issuing the TM= command on
> every affected connection.
>  
> No= t for TMF's that affect commands from other initiators.  Also, asking = the
> target to coordinate receipt of the TM command on every connec= tion in a
> multi-connection session is also a bit much.
> &n= bsp;
> > The third party story is even more puzzling as in order = to negotiate any of
> > the new TM modes the taget will have to ascertain that all= other initiators
> > support it. I fail to understand how would y= ou handle downgrading the mode
> > for those that don't.
>=  
> I think the target has to track this initiator by initiato= r, and notissue the
> new async message to old initiators.  This= increases the importance of being
> able to complete a TMF in the f= ace of an uncooperative third party "Legacy"
> initiator.
> &= nbsp;
> > And if you don't downgrade why not state that fast-abor= t and target scoped
> > queues don't go together and simplify the= mechanics to a multiple issue TM.
> This didn't parse for me - could= you explain in more detail?
>  
> Thanks,
> --Da= vid
> -------------------------------= ---------------------
> David L. Black, Senior Technologist
>= EMC Corporation, 176 South St., Hopkinton, MA  01748
> +1 (508) 29= 3-7953             FAX: +1 (508) 293-7786 > black_david@emc.com        Mobile: +1 (978) 394-7= 754
> ----------------------------------------------------
>
> From: Julian Satran [mailto:Julian_= Satran@il.ibm.com]
> Sent: Thursday, December 28, 2006 5:32 AM
&g= t; To: Mallikarjun C.
> Cc: ips@ietf.org
> Subject: Re: [Ips] T= MF text with updates
>
>
> Mallikarjun,
>
&g= t; I would consider the text:
>
> c. MUST leave all active "a= ffected TTTs" (i.e. active TTTs
> associated with affected tasks) va= lid along with any buffer
> allocations for the TTTs intact.
>= ;
> somewhat excessive as it relates too much to implementation. I w= ould
> rather say:
>
> c. MUST leave all active "affect= ed TTTs" (i.e. active TTTs
> associated with affected tasks) valid.
>
&= gt; and leave the buffer issue to the implementer (as I have stated
>= ; already on this list).
>
> I also keep thinking (and mildly=  objecting to) that the whole fast
> abort is excesively compl= ex.
>
> You could achive the same effect by issuing the TM co= mmand on every
> affected connection.
> The third party story= is even more puzzling as in order to negotiate
> any of the nem TM m= odes the taget will have to ascertain that all
> other initiators su= pport it. I fail to understand how would you
> handle downgrading th= e mode for those that don't. And if you don't
> downgrade why not st= ate that fast-abort and target scoped queues
> don't go together and= simplify the mechanics to a multiple issue TM.
>
> Thanks, <= BR>> Julo

>
> "Mallikar= jun C." <cb_mallikarjun@yahoo.com>
> 2= 8/12/06 06:41
>
> To
>
> ips@ietf.org
>
> cc
>
&= gt; Subject
>
> [Ips] TMF text= with updates
>
>
<= /TT>
>
>
>
>
>
>= ; Attached is the latest text that incorporates David's proposed
> e= nhancement.  Please review and comment.  Note especially two
= > things: new section 4.1.4 that summarizes generic implementation
&= gt; considerations for both "clarified" and "updated" semantics, the
&g= t; changed text in 4.1.2 that says "MAY wait for ....target transfer
&g= t; tags.....from third-party initiators" from the previous blanket MUST.>
> Mallikarjun
>
>
>
> 4.1.2 Clarified multi-task = abort semantics
> All iSCSI implementations MUST support the protocol= behavior defined
> in this section as the default behavior.  Th= e execution of ABORT
> TASK SET, CLEAR TASK SET, LOGICAL UNIT RESET,= TARGET WARM RESET, and
> TARGET COLD RESET TMF Requests consists of = the following sequence of
> actions in the specified order on the spe= cified party.
> The initiator iSCSI layer:
> a. MUST continue = to respond to each TTT received for the affected tasks.
> b. Should = receive any responses that the target may provide for some
> tasks am= ong the affected tasks (may process them as usual because
> they are= guaranteed to have chronologically originated prior to the
> TMF re= sponse).
> c. Should receive the TMF Response concluding all the tas= ks in the
> set of affected tasks.
>
> The target iSCS= I layer:
> a. MUST wait for currently valid target transfer tags of th= e
> affected tasks from the issuing initiator to be responded to. &n= bsp;MAY
> wait for responses on currently valid target transfer tags= of the
> affected tasks from third-party initiators.
> b. MUS= T wait (concurrent with the wait in Step.a) for all commands
> of th= e affected tasks to be received based on the CmdSN ordering.  
>= ; SHOULD NOT wait for new commands on third-party affected sessions -
&= gt; only the instantiated tasks have to be considered for the purpose of> determining the affected tasks.  In the case of target-scoped > requests (i.e. TARGET WARM RESET and TARGET COLD RESET), all the > commands that are not yet received on the issuing session in the
= > command stream however can be considered to have been received with > no command waiting period - i.e. the entire CmdSN space up to the > CmdSN of the task management function can be "plugged".
> c. MUST propagat= e the TMF request to and receive the response from
> the target SCSI= layer.
> d. MUST address the Response Fence flag on the TMF Respons= e on
> issuing session as defined in 3.3.2.
> e. MUST address = the Response Fence flag on the first post-TMF
> Response on third-pa= rty sessions as defined in 3.3.2.  If some tasks
> originate fro= m non-iSCSI I_T_L nexuses then the means by which the
> target ensur= es that all affected tasks have returned their status to
> the initia= tor are defined by the specific non-iSCSI transport protocol(s).
> Im= plementation note: Technically, the TMF servicing is complete in
> S= tep.d.  Data transfers corresponding to terminated tasks may
> = however still be in progress on third-party iSCSI sessiosn even at
>= the end of Step.e.  TMF Response MUST NOT be sent by the target
&= gt; iSCSI layer before the end of Step.d, and MAY be sent at the end of
> Ste= p.d despite these outstanding Data transfers until after Step.e.
> > 4.1.3 Updated multi-task abort semantics
> Protocol behavior d= efined in this section MUST be implemented by all
> iSCSI implementat= ions complying with this document.  Protocol
> behavior defined= in this section MUST be exhibited by iSCSI
> implementations on an = iSCSI session when they negotiate the
> TaskReporting (section 9.1) = key to =93FastAbort=94 on that session.  The
> execution of ABOR= T TASK SET, CLEAR TASK SET, LOGICAL UNIT RESET,
> TARGET WARM RESET,= and TARGET COLD RESET TMF Requests consists of
> the following sequ= ence of actions in the specified order on the
> specified party. > The initiator iSCSI layer:
> a. MUST NOT send any more Data-Out= PDUs for affected tasks on the
> issuing connection of the issuing = iSCSI session once the TMF is sent
> to the target.
> b. Should receive any = responses that the target may provide for some
> tasks among the affe= cted tasks (may process them as usual because
> they are guaranteed = to have chronologically originated prior to the
> TMF response).
= > c. MUST respond to Async Message PDU with AsyncEvent=3D5 as defined in=
> section 8.1.
> d. Should receive the TMF Response concluding= all the tasks in the
> set of affected tasks.
>
> The = target iSCSI layer:
> a. MUST wait for all commands of the affected t= asks to be received
> based on the CmdSN ordering on the issuing ses= sion.  SHOULD NOT wait
> for new commands on third-party affecte= d sessions - only the
> instantiated tasks have to be considered for= the purpose of
> determining the affected tasks.  In the case = of target-scoped
> requests (i.e. TARGET WARM RESET and TARGET COLD = RESET), all the
> commands that are not yet received on the issuing session in the =
> command stream however can be considered to have been received wit= h
> no command waiting period - i.e. the entire CmdSN space up to th= e
> CmdSN of the task management function can be "plugged".
> = b. MUST propagate the TMF request to and receive the response from
>= the target SCSI layer.
> c. MUST leave all active "affected TTTs" (= i.e. active TTTs
> associated with affected tasks) valid along with = any buffer
> allocations for the TTTs intact.
> d. MUST genera= te an Asynchronous Message PDU with AsyncEvent=3D5
> (section 8.1) o= n:
> i) each connection of each third-party session that at least one=
> affected task is allegiant to, and
> ii) each connection ex= cept the issuing connection of the issuing
> session that has at lea= st one allegiant affected task.
> If there are multiple affected LUs = (say due to a target reset), then
> one Async Message PDU MUST be sent for each su= ch LU on each
> connection that has at least one allegiant affected = task.
> e. MUST address the Response Fence flag on the TMF Response o= n
> issuing session as defined in 3.3.2.
> f. MUST address the= Response Fence flag on the first post-TMF
> Response on third-party= sessions as defined in 3.3.2. If some tasks
> originate from non-iS= CSI I_T_L nexuses then the means by which the
> target ensures that = all affected tasks have returned their status to
> the initiator are = defined by the specific non-iSCSI transport protocol(s).
> g. MUST fr= ee up the affected TTTs (and STags, if applicable) and the
> correspo= nding buffers once it receives the associated Nop-Out
> acknowledgem= ent that the initiator generated in response to the
> Async Message.=  
> Implementation note: Technically, the TMF servicing is comp= lete in
> Step.e.  Data transfers corresponding to terminated tasks ma= y
> however still be in progress even at the end of Step.f.  TM= F
> Response MUST NOT be sent by the target iSCSI layer before the e= nd
> of Step.e, and MAY be sent at the end of Step.e despite these <= BR>> outstanding Data transfers until Step.g.  Step.g specifies an = event
> to free up any such resources that may have been reserved to= support
> outstanding data transfers.  
> 4.1.3.1 Clearin= g effects update
> Appendix F.1 of [RFC3720] specifies the clearing e= ffects of target
> and LU resets on =93Incomplete TTTs=94 as =93Y=94= .  This meant that a target
> warm reset or a target cold reset = or an LU reset would clear the
> active TTTs upon completion.  = The TaskReporting=3DFastAbort (section
> 9.1) semantics defined by t= his section however do not guarantee that
> the active TTTs are clear= ed by the end of the reset operations.  In
> fact, the new semantics are des= igned to allow clearing the TTTs in a
> =93lazy=94 fashion after the = TMF Response is delivered.  Thus, when
> TaskReporting=3DFastAb= ort is operational on a session, the clearing
> effects of reset ope= rations on =93Incomplete TTTs=94 is =93N=94.  
> 4.1.4 Implement= ation considerations
> Both in clarified semantics (section 4.1.2) an= d updated semantics
> (section 4.1.3), there may be outstanding data= transfers even after
> the TMF completion is reported on the issuin= g session.  In the case
> of iSCSI/iSER [iSER], these would be = tagged data transfers for STags
> not owned by any active tasks. &nbs= p;Whether or not real buffers support
> these data transfers is impl= ementation-dependent.  However, the data
> transfers logically M= UST be silently discarded by the target iSCSI
> layer in all cases. =  A target MAY, on an implementation-defined
> internal timeout, also choose t= o drop the connections on which it
> did not receive the expected Da= ta-out sequences (section 4.1.2) or
> Nop-Out acknowledgements (sect= ion 4.1.3) so as to reclaim the
> associated buffer, STag and TTT re= sources as appropriate.
>
>
> ----- Original Message --= --
> From: "Black_David@emc.com" <Black_David@emc.com>
> = To: Black_David@emc.com; cb_mallikarjun@yahoo.com; ips@ietf.org
> Sen= t: Wednesday, December 20, 2006 2:33:43 PM
> Subject: RE: [Ips] Imple= menter's Guide - Task Management Issue
>
>
> > Let's= try this line of reasoning - the target issues the Nop-Out, now
> wh= en
> > can it free the resources?  Answer:
> >  = ;   - The Nop-In response comes back, OR
> >     - = The connection times out and is torn down.
> > Now, what if the No= p-Out is not issued - what does the target wait for
> to
> > free the re= sources?  Answer:
> >     - The transfers complete,= OR
> >     - The connection times out and is torn down.=
> > Those look similar enough at the target (the worst case is t= he same -
> the
> > resources are tied up until an uncoopera= tive initiator times out) that
> > I don't see the harm in allowin= g the early TMF return without the new
> > key.  The clear di= stinction is that the first two bullets are
> different;
> >= if the new key is not negotiated, the target has to wait for the
> t= ransfers
> > to complete; the new key and the Nop-Out are necessar= y to walk away
> earlier
> > when the initiator involved is = able to continue the transfers.
>
> That got slightly twisted = - what it should have talked about was the
> target
> issuing t= he new Async Message and the Nop-Out response coming back.
>
> Thanks,
= > --David
> ----------------------------------------------------> David L. Black, Senior Technologist
> EMC Corporation, 176 Sou= th St., Hopkinton, MA  01748
> +1 (508) 293-7953     &= nbsp;       FAX: +1 (508) 293-7786
> black_david@emc.c= om        Mobile: +1 (978) 394-7754
> -----------= -----------------------------------------
>
> ________________= __________________________________
> Do You Yahoo!?
> Tired of = spam?  Yahoo! Mail has the best spam protection around
> http:/= /mail.yahoo.com
>
> _________________________________________= ______
> Ips mailing list
> Ips@ietf.org
> https://www1.i= etf.org/mailman/listinfo/ips

> ___= ____________________________________________
> Ips mailing list
&g= t; Ips@ietf.org
> https://www1.ietf.org/mailman/listinfo/ips
>
>
> ___________________________= _______________________
> Do You Yahoo!?
> Tired of spam? Yahoo= ! Mail has the best spam protection around
> http://mail.yahoo.com _= ______________________________________________
> Ips mailing list
= > Ips@ietf.org
> https://www1.ietf.org/mailman/listinfo/ips
=0A


___________________________= _______________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail ha= s the best spam protection around
http://mail.yahoo.com --0-1074182379-1167766578=:56146-- --===============1199327214== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============1199327214==-- From ips-bounces@ietf.org Wed Jan 03 12:05:49 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H29YN-0003fY-LW; Wed, 03 Jan 2007 12:05:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H29YN-0003fF-3d for ips@ietf.org; Wed, 03 Jan 2007 12:05:27 -0500 Received: from imf23aec.mail.bellsouth.net ([205.152.59.71]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H29YL-00007f-Al for ips@ietf.org; Wed, 03 Jan 2007 12:05:27 -0500 Received: from ibm66aec.bellsouth.net ([74.245.52.54]) by imf23aec.mail.bellsouth.net with ESMTP id <20070103170520.DVZW18103.imf23aec.mail.bellsouth.net@ibm66aec.bellsouth.net> for ; Wed, 3 Jan 2007 12:05:20 -0500 Received: from IVVTDKV0981 ([74.245.52.54]) by ibm66aec.bellsouth.net with SMTP id <20070103170519.RBGX29829.ibm66aec.bellsouth.net@IVVTDKV0981>; Wed, 3 Jan 2007 12:05:19 -0500 Message-ID: <000301c72f59$59307050$01faa8c0@ivivity.com> From: "Eddy Quicksall" To: , , References: Subject: Re: [Ips] Re: iSCSI "compliance" text Date: Wed, 3 Jan 2007 12:05:19 -0500 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.0 (/) X-Scan-Signature: 3da7e5d5ca82d58872786934e4963616 Cc: X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ips-bounces@ietf.org There are two problems I have with your response to the examples: 1) for hardware to check the ITT ... it would take a lot of logic. For software to check it, it can take an external memory reference which could be a performance hit. If an initiator is going to use a bad ITT it will probably have even worse bugs that the target can't detect. For example, what if it uses the wrong ITT in the original command ... the target can't detect that. 2) for the immediate data case, if the target can handle it then why should it take the time on every single I/O to make the check? Also, note that I'm not saying the targets/initiators are discouraged from making checks ... in fact I already stated that during login, where performance is not an issue, that the target/initiator is encouraged to make checks. All I'm asking for is some simple text that clarifies that it is up to the target or initiator as to if a check should be made when the spec has not spelled it out. If the spec says MUST then clearly the check must be made. Eddy ----- Original Message ----- From: To: ; Sent: Thursday, December 28, 2006 3:08 PM Subject: RE: [Ips] Re: iSCSI "compliance" text Eddy, I think I agree with Mallikarjun on this. If there is specific text in RFC 3720 that says the recipient "MUST" check thus-and-such, we could look at whether that check is really needed, and weaken the text if it is not. There's certainly nothing wrong with making the checks - if the initiator "MUST" do , then the target is entitled to rely on and complain if it isn't being done. I hesitate to discourage targets from making checks. The two examples you cite: - Initiator uses wrong ITT value on data - Initiator sends immediate data when negotiation forbids it are things that I think I'd prefer to have blow up in the initiator's face sooner rather than later, as they could result in bad/wrong data being stored if the target guesses wrong about how to compensate for that initiator mistake. Thanks, --David ---------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- > -----Original Message----- > From: Mallikarjun C. [mailto:cb_mallikarjun@yahoo.com] > Sent: Thursday, December 28, 2006 12:03 AM > To: ips@ietf.org > Subject: [Ips] Re: iSCSI "compliance" text > > Eddy, > > Even if we say it in the draft, it would be pretty generic > and will have no mandatory force. So I do not see a lot of > value in attempting to state it in the draft. Unless I get > other inputs and/or advise from David and Lars, I prefer not > to attempt to craft such a text. I also suspect this is not > a case peculiar to iSCSI protocol, so I would welcome inputs > from other WG members. > > Mallikarjun > > > ----- Original Message ---- > From: Eddy Quicksall > To: ips@ietf.org > Sent: Thursday, December 21, 2006 9:20:14 AM > Subject: Fw: [Ips] ips WG Last Call: iSCSI Implementer's Guide > > > Sorry, I forgot to send this original request to the list. > > What I'm thinking is to say this in the iSCSI Implementer's > Guide, if it is > not too late. > > One of the problems I'm faced with is that our customers will > run 3rd party > tests on a final product. If 3rd party test says "failed" > then the customer > takes that to its word. I have found that many people think > that if the RFC > says the initiator MUST then they think that means the target > MUST check to > see that the initiator obeyed the rule (and visa versa) ... > some of the 3rd > party tests are in that category. > > Eddy > > ----- Original Message ----- > From: "Mallikarjun C." > To: "Eddy Quicksall" > Cc: ; "Julian Satran" > Sent: Thursday, December 14, 2006 6:55 PM > Subject: Re: [Ips] ips WG Last Call: iSCSI Implementer's Guide > > > I think I understand your question. Generally, the IETF > philosophy is to > "be liberal in what you accept, be conservative in what you send" (my > paraphrasing of it, anyway) - so if your target wants to be > more forgiving, > I think that should be alright. > > The UNH tests may be testing all MUST requirements - so in > your immediate > data example, the initiator must be held to this rule since > it initiates the > immediate data send. On the target side, I see no harm in > turning off those > checks in your production code when you think you can > gracefully deal even > with a badly-behaving initiator. On such occasions though, > you should be > sure to not flag SCSI protocol errors for those same iSCSI > protocol errors > that you had earlier forgiven. > > Hope that helps. > > Mallikarjun > > > ----- Original Message ---- > From: Eddy Quicksall > To: Mallikarjun C. > Sent: Wednesday, December 13, 2006 4:17:37 AM > Subject: Re: [Ips] ips WG Last Call: iSCSI Implementer's Guide > > > I know it is really late to ask this but I was wondering if > something could > be done to relax some of the requirements for the target or > initiator to > check for correctness of the protocol? For example, it could > be said that if > the protocol error will not affect the operation of the > device then it is > not necessary to check for the error. > > I ask this because all of these checks during Full Feature > Phase can cause > unnecessary performance degradation due to a check on every > command PDU even > when the initiator or target have been previously qualified. > This is off the > top of my head but one such check that comes to mind is the > check to be sure > the ITT of data matches the ITT of the original command... we > have hardware > acceleration and different types of memory with different > speeds. To cross > check against the command requires saving additional information and > accessing the slow memory (the fast memory is at a premium > and can't store > enough information). Another is the requirement for the > target to check for > immediate data received when immediate data was negotiated to > no (if the > target can deal with it and the initiator can't but the > initiator negotiated > it to no then the initiator should not send it anyway and > there should be no > need to make the checks on every command). > > Maybe some of these that I call "required checks" are > actually the result of > a test program (such as the UNH test program) putting on the > "requirement". > If so then a note in the guide may help to clear up that it > is not an error > for the initiator or target to double check the peer. > > I typed this kind of fast and I'm not a good linguist so if you don't > understand then please let me know. > > Eddy > > ----- Original Message ----- > From: "Mallikarjun C." > To: > Sent: Monday, December 11, 2006 12:34 PM > Subject: Re: [Ips] ips WG Last Call: iSCSI Implementer's Guide > > > Lars, > > Thanks for the comments and sorry for the delay in getting back. > > As far as volunteers for reviewing, we could request the > contributors at the > end of the document to review. David may have already > reviewed, based on > his comments. Julian Satran had some offline feedback for me > on TMF topics. > As the editor of the document, I was sure that each of the topics were > discussed in detail (or at least clearly noted) on the list before I > included them in the doc. Hope that gives you some reassurance. > > >whether it is merely the original text that can be > >misunderstood or if there is a technical error in the original text. > > (It already does in some cases.) > > Yes, I'd appreciate if you could point out where you think additional > clarifications could help. > > > OK, so this document not only updates 3720, but also 3721, 3722 and > > 3723? That needs to be stated in the document header and abstract. > > (Also, 3721 needs to be normatively cited in this case.) > > We could. My intent was to make it clear that this document prevails > whenever a subtle interpretation in future of one of these > RFCs differs from > what's in this document. Now that we are nearing the end of > the work on > this document, we could delete some although I personally am > tempted to > leave it this way....from what I can think of today though, > this doc updates > 3720 and 3721, but does not update 3722 and 3723. > > 3721 is not a standards-track RFC and I wasn't sure if it needs to be > normatively cited as such. But I could if that's the right > thing to do. > > >Suggest to find a better title, because implementer's guides don't > >typically update the base specification in a normative way. (Maybe > > "iSCSI Corrections and Implementer's Guide" or something like that?) > > FIne by me. How about "iSCSI Corrections, Clarifications, > Additions and > Implementation Guidance", or is it too long? If it is, we > could try "iSCSI > Changes Based on Implementers' Experience" or something like it. > > > The specification of the fence mechanisms should use RFC2119 terms, > > especially in Section 3.3.2. > > It actually does, with a MUST preceding the bulleted list.... > As far as > 3.3.1, I intentionally left the model description very > generic with the hope > that it can be incorporated into a future T10 spec verbatim. > > > Nit: s/mult/multi-/ > > Done. > > > I'm not sure if "should receive" describes something that should be > > started in RFC2119 language or not. If that is the intent, a better > > phrasing should be found. (Also elsewhere in this document where the > > same phrasing is used.) > > I left the "should"s intentionally in, because they really are the > prerogatives of the initiator's run-time behavior, i.e. > initiator may at his > discretion choose to discard a message for some other reason (e.g. bad > digest) beyond the 2119 protocol requirements. > > >Should the sentence starting with "SHOULD NOT" start a new item in > > this list? > > No, I don't think so. This bullet is all about waiting for > missing CmdSN's. > It happens to have a different prescription for third-party affected > sessions. > > >Remove text after "considerations" to not confuse IANA. May want > > to add a note to the RFC Editor to remove this section upon > >publication. > > Done. > > > Nit: Cited also as [RFC 3720], which confuses idnits. Remove the > space > > in the other citations. > > Done. > > >iSER Not cited. > > It does now. > > > ID does not include the required 2119 boilerplate. Also, 2119 should > > be cited normatively. > > Fixed now. > > > Mallikarjun > > > > > > > > > > ----- Original Message ---- > From: Lars Eggert > To: ips@ietf.org > Sent: Friday, December 1, 2006 4:57:59 PM > Subject: Re: [Ips] ips WG Last Call: iSCSI Implementer's Guide > > > Summary: Minor revision needed to address editorial issues. Note: I'm > no iSCSI expert, so I cannot fully review the technical > recommendations made in this document. I'd like to see at least one > other review from someone who has the necessary background before > this > document moves forward - volunteers? > > Contains non-ASCII characters, boilerplate issues and other idnits. > Please fix. Header should indicate that this document updates 3720 > and potentially other IDs (abstract already partially does - good!) > > It would be good if this document would state for each item it > discusses, whether this is a clarification to the original > RFCs or a > correction, i.e., whether it is merely the original text > that can be > misunderstood or if there is a technical error in the > original text. > (It already does in some cases.) > > > INTRODUCTION, paragraph 1: > > iSCSI Implementer's Guide > > Suggest to find a better title, because implementer's guides don't > typically update the base specification in a normative way. (Maybe > "iSCSI Corrections and Implementer's Guide" or something > like that?) > > > Section 2, paragraph 2: > > iSCSI implementers are required to reference [RFC3722] and > > [RFC3723] in addition to [RFC3720] for mandatory requirements. > > In addition, [RFC3721] also contains useful information for > > iSCSI implementers. The text in this document, however, updates > > and supersedes the text in all the noted RFCs whenever there is > > such a question. > > OK, so this document not only updates 3720, but also 3721, 3722 and > 3723? That needs to be stated in the document header and abstract. > (Also, 3721 needs to be normatively cited in this case.) > > > Section 3.3, paragraph 0: > > 3.3 SCSI Protocol Interface Model for Response Ordering > > The specification of the fence mechanisms should use RFC2119 terms, > especially in Section 3.3.2. > > > Section 3.3.3, paragraph 4: > > 2. The TMF Response carrying the mult-task TMF Response on the > > issuing session. > > Nit: s/mult/multi-/ > > > Section 4.1.2, paragraph 4: > > b. Should receive any responses that the target may provide > > for some tasks among the affected tasks (may process them > > as usual because they are guaranteed to have > > chronologically originated prior to the TMF response). > > I'm not sure if "should receive" describes something that should be > started in RFC2119 language or not. If that is the intent, a better > phrasing should be found. (Also elsewhere in this document > where the > same phrasing is used.) > > > Section 4.1.2, paragraph 8: > > b. MUST wait (concurrent with the wait in Step.a) for all > > commands of the affected tasks to be received > based on the > > CmdSN ordering. SHOULD NOT wait for new commands on > > third-party affected sessions - only the instantiated > tasks > > have to be considered for the purpose of determining the > > affected tasks. In the case of target-scoped requests > > (i.e. TARGET WARM RESET and TARGET COLD RESET), all the > > commands that are not yet received on the issuing session > > in the command stream however can be considered to have > > been received with no command waiting period - i.e. the > > entire CmdSN space up to the CmdSN of the task management > > function can be "plugged". > > Should the sentence starting with "SHOULD NOT" start a new item in > this list? > > > Section 4.1.3, paragraph 8: > > a. MUST wait for all commands of the affected tasks to be > > received based on the CmdSN ordering on the issuing > > session. SHOULD NOT wait for new commands on third-party > > affected sessions - only the instantiated tasks have to be > > considered for the purpose of determining the affected > > tasks. In the case of target-scoped requests (i.e. TARGET > > WARM RESET and TARGET COLD RESET), all the commands that > > are not yet received on the issuing session in the command > > stream however can be considered to have been > received with > > no command waiting period - i.e. the entire CmdSN space up > > to the CmdSN of the task management function can be > > "plugged". > > Should the sentence starting with "SHOULD NOT" start a new item in > this list? > > > Section 11, paragraph 1: > > This draft does not have any specific IANA considerations other > than > > those already noted in [RFC3720]. > > Remove text after "considerations" to not confuse IANA. May want > to add a note to the RFC Editor to remove this section upon > publication. > > > Section 12.1, paragraph 1: > > [RFC3720] Satran, J., Meth, K., Sapuntzakis, C., Chadalapaka, > > M., and E. Zeidner, "Internet Small Computer Systems > > Interface (iSCSI)", RFC 3720, April 2004. > > Nit: Cited also as [RFC 3720], which confuses idnits. Remove the > space > in the other citations. > > > Section 12.2, paragraph 1: > > [RFC3721] Bakke, M., Hafner, J., Hufferd, J., Voruganti, K., > > and M. Krueger, "Internet Small Computer Systems Interface > > (iSCSI) Naming and Discovery", RFC 3721, April 2004. > > See above, if this ID updates 3721, it needs to > normatively cite it. > > > Section 12.2, paragraph 2: > > [iSER] Ko, M., Chadalapaka, M., Elzur, U., Shah, H., Thaler, > > P., J. Hufferd, "iSCSI Extensions for RDMA", IETF > > Internet Draft draft-ietf-ips-iser-04.txt (work in > > progress), June 2005. > > Not cited. > > > Section 12.2, paragraph 3: > > [RFC2119] Bradner, S. "Key Words for use in RFCs to Indicate > > Requirement Levels", BCP 14, RFC 2119, March 1997. > > ID does not include the required 2119 boilerplate. Also, > 2119 should > be cited normatively. > _______________________________________________ > Ips mailing list > Ips@ietf.org > https://www1.ietf.org/mailman/listinfo/ips > > > > ______________________________________________________________ > ______________________ > Do you Yahoo!? > Everyone is raving about the all-new Yahoo! Mail beta. > http://new.mail.yahoo.com > > _______________________________________________ > Ips mailing list > Ips@ietf.org > https://www1.ietf.org/mailman/listinfo/ips > > > > ______________________________________________________________ > ______________________ > Want to start your own business? > Learn how on Yahoo! Small Business. > http://smallbusiness.yahoo.com/r-index > > > _______________________________________________ > Ips mailing list > Ips@ietf.org > https://www1.ietf.org/mailman/listinfo/ips > > __________________________________________________ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around > http://mail.yahoo.com > > _______________________________________________ > Ips mailing list > Ips@ietf.org > https://www1.ietf.org/mailman/listinfo/ips > > _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Wed Jan 03 15:00:15 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2CHK-0000d2-38; Wed, 03 Jan 2007 15:00:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2CHJ-0000cw-L1 for ips@ietf.org; Wed, 03 Jan 2007 15:00:01 -0500 Received: from imf24aec.mail.bellsouth.net ([205.152.59.72]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2CHI-0004pR-Cg for ips@ietf.org; Wed, 03 Jan 2007 15:00:01 -0500 Received: from ibm68aec.bellsouth.net ([74.245.52.54]) by imf24aec.mail.bellsouth.net with ESMTP id <20070103195953.LSIY9111.imf24aec.mail.bellsouth.net@ibm68aec.bellsouth.net> for ; Wed, 3 Jan 2007 14:59:53 -0500 Received: from IVVTDKV0981 ([74.245.52.54]) by ibm68aec.bellsouth.net with SMTP id <20070103195952.UHVP16056.ibm68aec.bellsouth.net@IVVTDKV0981> for ; Wed, 3 Jan 2007 14:59:52 -0500 Message-ID: <006201c72f71$b9121b50$01faa8c0@ivivity.com> From: "Eddy Quicksall" To: Date: Wed, 3 Jan 2007 14:59:48 -0500 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.1 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Subject: [Ips] Response Fence Flag X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0389528189==" Errors-To: ips-bounces@ietf.org This is a multi-part message in MIME format. --===============0389528189== Content-Type: multipart/alternative; boundary="----=_NextPart_000_005F_01C72F47.CFF93DF0" This is a multi-part message in MIME format. ------=_NextPart_000_005F_01C72F47.CFF93DF0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Section 3.3.1 talks about a Response Fence Flag: SCSI protocol layer instructs the SCSI transport layer of a=20 "Response Fence" associated with the response in question when=20 the "Send Command Complete" protocol data service (SAM-2, clause=20 5.4.2) ... But I don't see any reference to that in SAM-2. Is this strictly an iSCSI flag? Where is the flag specified? Eddy ------=_NextPart_000_005F_01C72F47.CFF93DF0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Section 3.3.1 talks about a Response Fence = Flag:
 
SCSI protocol layer instructs the SCSI transport layer of a =
"Response=20 Fence" associated with the response in question when
the "Send = Command=20 Complete" protocol data service (SAM-2, clause
5.4.2) ...
 
But I don't see any reference to that in = SAM-2.
 
Is this strictly an iSCSI flag? Where is the flag=20 specified?
 
Eddy
------=_NextPart_000_005F_01C72F47.CFF93DF0-- --===============0389528189== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============0389528189==-- From ips-bounces@ietf.org Wed Jan 03 16:56:13 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2E5T-0001W7-50; Wed, 03 Jan 2007 16:55:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2E5R-0001W1-Kq for ips@ietf.org; Wed, 03 Jan 2007 16:55:53 -0500 Received: from ccerelbas03.cce.hp.com ([161.114.21.106]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2E5J-0000ny-4W for ips@ietf.org; Wed, 03 Jan 2007 16:55:53 -0500 Received: from G3W0059.americas.hpqcorp.net (g3w0059.americas.hpqcorp.net [16.232.1.16]) by ccerelbas03.cce.hp.com (Postfix) with ESMTP id A078A3453A for ; Wed, 3 Jan 2007 15:55:44 -0600 (CST) Received: from cceexcsp04.americas.cpqcorp.net ([16.81.1.18]) by G3W0059.americas.hpqcorp.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 3 Jan 2007 15:55:38 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ips] Response Fence Flag Date: Wed, 3 Jan 2007 15:55:37 -0600 Message-ID: In-Reply-To: <006201c72f71$b9121b50$01faa8c0@ivivity.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [Ips] Response Fence Flag Thread-Index: AccvclHDNhdyvEmuS1aoDWtomSCtTAAD24Wg From: "Elliott, Robert (Server Storage)" To: X-OriginalArrivalTime: 03 Jan 2007 21:55:38.0099 (UTC) FILETIME=[E7498430:01C72F81] X-Spam-Score: 0.0 (/) X-Scan-Signature: 16c9da4896bf5539ae3547c6c25f06a0 X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0328013476==" Errors-To: ips-bounces@ietf.org This is a multi-part message in MIME format. --===============0328013476== Content-class: urn:content-classes:message Content-Type: multipart/signed; boundary="----=_NextPart_000_024F_01C72F4F.9C466750"; protocol="application/x-pkcs7-signature"; micalg=SHA1 This is a multi-part message in MIME format. ------=_NextPart_000_024F_01C72F4F.9C466750 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0250_01C72F4F.9C466750" ------=_NextPart_001_0250_01C72F4F.9C466750 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit If T10 agrees, T10 proposal 06-341 will add it to SAM-4. -- Rob Elliott, elliott@hp.com Hewlett-Packard Industry Standard Server Storage Advanced Technology https://ecardfile.com/id/RobElliott _____ From: Eddy Quicksall [mailto:Quicksall_iSCSI@Bellsouth.net] Sent: Wednesday, January 03, 2007 2:00 PM To: ips@ietf.org Subject: [Ips] Response Fence Flag Section 3.3.1 talks about a Response Fence Flag: SCSI protocol layer instructs the SCSI transport layer of a "Response Fence" associated with the response in question when the "Send Command Complete" protocol data service (SAM-2, clause 5.4.2) ... But I don't see any reference to that in SAM-2. Is this strictly an iSCSI flag? Where is the flag specified? Eddy ------=_NextPart_001_0250_01C72F4F.9C466750 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
If T10 agrees, T10 proposal 06-341 will add = it to=20 SAM-4.
 

-- =
Rob Elliott, = elliott@hp.com=20
Hewlett-Packard = Industry Standard=20 Server Storage Advanced Technology
https://ecardfile.com/id/Rob= Elliott=20



From: Eddy Quicksall=20 [mailto:Quicksall_iSCSI@Bellsouth.net]
Sent: Wednesday, = January 03,=20 2007 2:00 PM
To: ips@ietf.org
Subject: [Ips] = Response=20 Fence Flag

Section 3.3.1 talks about a Response Fence=20 Flag:
 
SCSI protocol layer instructs the SCSI transport layer of a =
"Response=20 Fence" associated with the response in question when
the "Send = Command=20 Complete" protocol data service (SAM-2, clause
5.4.2) ...
 
But I don't see any reference to that in = SAM-2.
 
Is this strictly an iSCSI flag? Where is the flag=20 specified?
 
Eddy
------=_NextPart_001_0250_01C72F4F.9C466750-- ------=_NextPart_000_024F_01C72F4F.9C466750 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIN9TCCAwMw ggJsAhEAuS9gzIifoXpGCbhbcGyKrzANBgkqhkiG9w0BAQUFADCBwTELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMTwwOgYDVQQLEzNDbGFzcyAyIFB1YmxpYyBQcmltYXJ5IENl cnRpZmljYXRpb24gQXV0aG9yaXR5IC0gRzIxOjA4BgNVBAsTMShjKSAxOTk4IFZlcmlTaWduLCBJ bmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmswHhcNOTgwNTE4MDAwMDAwWhcNMjgwODAxMjM1OTU5WjCBwTELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMTwwOgYDVQQLEzNDbGFzcyAyIFB1YmxpYyBQcmltYXJ5IENl cnRpZmljYXRpb24gQXV0aG9yaXR5IC0gRzIxOjA4BgNVBAsTMShjKSAxOTk4IFZlcmlTaWduLCBJ bmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmswgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAKeIASF0LOcaA/CY4Zc8DyEI8Zzbl+ma /MIEBhO+X1LIzB4sElYsuAFpLMyZH62wlq55BPITOcF7mLoILOjChBMsqmnpCfTHqQKkQsIjT0rY 8A6i+zFsyeZvmScH9eb0THiebetGhvq5hslU8rLEr9RGHFrJFTD/DWz1LQ5tzn93AgMBAAEwDQYJ KoZIhvcNAQEFBQADgYEAci75f9HxcfvEnvbFXlGKQJi4aPibHIPY4p29/+2h5mbqLwn0ytfqpSuV 9iRghk1ELoOlxC2g0654aW9y2myuCPBjkjfmu8QwF613zEk1qs/Yj9G+txiWR3NqVCI0ZC22FptZ W7RRWTqzCxT0Et9noPStMmResUZyJ4wSe8VEtK4wggQlMIIDjqADAgECAhBWO27ntnEulADNe55i te6UMA0GCSqGSIb3DQEBBQUAMIHBMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIElu Yy4xPDA6BgNVBAsTM0NsYXNzIDIgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3Jp dHkgLSBHMjE6MDgGA1UECxMxKGMpIDE5OTggVmVyaVNpZ24sIEluYy4gLSBGb3IgYXV0aG9yaXpl ZCB1c2Ugb25seTEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazAeFw0wMTA0MjQwMDAw MDBaFw0wOTA0MjMyMzU5NTlaMIHiMSAwHgYDVQQKExdIZXdsZXR0LVBhY2thcmQgQ29tcGFueTEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0 IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDExMDAuBgNVBAsTJ0NsYXNzIDIgT25T aXRlIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQTEuMCwGA1UEAxMlQ29sbGFib3JhdGlvbiBDZXJ0 aWZpY2F0aW9uIEF1dGhvcml0eTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAwHBTCwUTa0hb aHog6TMn4eE7398EjzwgM69HP+K7kNyVfFWph26qBIDYAZLebCYtGIb7k9yTmPRVIWAdYDgw28tQ +Q8belgqEWmwzmv9ISTlEgFvOFLKc+cgI9/FKCiRN2QW12uHsugJhKBwNJ21zB7MDoEdBjGY1MyY 5T1+5TsCAwEAAaOB+jCB9zAPBgNVHRMECDAGAQH/AgEAMEQGA1UdIAQ9MDswOQYLYIZIAYb4RQEH AQEwKjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYTALBgNVHQ8EBAMC AQYwEQYJYIZIAYb4QgEBBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFi ZWwxLTM4MjA0BgNVHR8ELTArMCmgJ6AlhiNodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9wY2EyLWcy LmNybDAdBgNVHQ4EFgQU7+0gzUNFH4NHYBWWQ3JK5MbM5z0wDQYJKoZIhvcNAQEFBQADgYEAQZJR XIBAaNmQVGuF68nKEMhda/Wl56rvk9AuHYkKV0sP/9ktuyn7KMuHKiFj4uAKwCZLiq36wjYqiK3j gk9MZ5TPkAuf1TyWJ1MqnoFn6+7WcQk/leJwbVDTtKV7T0bfTP8fGF57cV8qJ6SSWifpDseYdKh+ CnjP1kI3jkLTJ28wggbBMIIGKqADAgECAhAKdHan+h3w0DJ5y2g6sZ4+MA0GCSqGSIb3DQEBBQUA MIHiMSAwHgYDVQQKExdIZXdsZXR0LVBhY2thcmQgQ29tcGFueTEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlz aWduLmNvbS9ycGEgKGMpMDExMDAuBgNVBAsTJ0NsYXNzIDIgT25TaXRlIEluZGl2aWR1YWwgU3Vi c2NyaWJlciBDQTEuMCwGA1UEAxMlQ29sbGFib3JhdGlvbiBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0 eTAeFw0wNTA2MTkwMDAwMDBaFw0wNzA2MTkyMzU5NTlaMIGTMSAwHgYDVQQKFBdIZXdsZXR0LVBh Y2thcmQgQ29tcGFueTEmMCQGA1UECxQdRW1wbG95bWVudCBTdGF0dXMgLSBFbXBsb3llZXMxDzAN BgNVBAsUBlMvTUlNRTEXMBUGA1UEAxMOUm9iZXJ0IEVsbGlvdHQxHTAbBgkqhkiG9w0BCQEWDmVs bGlvdHRAaHAuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC/MZfCi58Dp+1cot3dstzT F6CfjU4trSwBW89oZZ4j1zB1kHMbZz/fVOandm3r2kg4n2GsVEAyAWWGLXwCIGHoRzx5yQ/Mdo99 yLnoXKPRRNe+ish2MTHHbuBdNWHZ2gAliEenkEacaMlKsTvzJ1lxCPL1XyM9SAhsU2g3ug2KBQID AQABo4IDwzCCA78wKQYDVR0RBCIwIIEOZWxsaW90dEBocC5jb22BDkVsbGlvdHRAaHAuY29tMAwG A1UdEwEB/wQCMAAwDgYDVR0PAQH/BAQDAgWgMB8GA1UdIwQYMBaAFO/tIM1DRR+DR2AVlkNySuTG zOc9MB0GA1UdDgQWBBSH3KjM077e0B3Y+Ur0isKkVCX1rzBXBgNVHR8EUDBOMEygSqBIhkZodHRw Oi8vb25zaXRlY3JsLnZlcmlzaWduLmNvbS9IZXdsZXR0UGFja2FyZENvbXBhbnlTTUlNRS9MYXRl c3RDUkwuY3JsMBYGA1UdJQEB/wQMMAoGCCsGAQUFBwMEMIIBPQYDVR0gBIIBNDCCATAwggEsBgtg hkgBhvhFAQcXAjCCARswKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9DUFMw ge4GCCsGAQUFBwICMIHhMB4WF0hld2xldHQtUGFja2FyZCBDb21wYW55MAMCAQIagb5BdXRob3Jp dHkgdG8gYmluZCBIUCBkb2VzIG5vdCBjb3JyZXNwb25kIHdpdGggdXNlIG9yIHBvc3Nlc3Npb24g b2YgdGhpcyBjZXJ0aWZpY2F0ZS4gSXNzdWVkIHRvIGZhY2lsaXRhdGUgY29tbXVuaWNhdGlvbiB3 aXRoIEhQLiBWZXJpU2lnbidzIENQUyBpbmNvcnAuIEJ5IHJlZmVyZW5jZSBsaWFiLiBsdGQuIChj KTk3IFZlcmlTaWduMIIBMwYIKwYBBQUHAQEEggElMIIBITArBggrBgEFBQcwAYYfaHR0cDovL29u c2l0ZS1vY3NwLnZlcmlzaWduLmNvbTCB8QYIKwYBBQUHMAKkgeQwgeExLjAsBgNVBAMTJUNvbGxh Ym9yYXRpb24gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxMDAuBgNVBAsTJ0NsYXNzIDIgT25TaXRl IEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQTE6MDgGA1UECxMxVGVybXMgb2YgdXNlIGF0IGh0dHBz Oi8vd3d3LnZlcmlzaWduLmNvbS9ycGEoYykwMTEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0 d29yazEgMB4GA1UEChMXSGV3bGV0dC1QYWNrYXJkIENvbXBhbnkwSwYJKoZIhvcNAQkPBD4wPDAO BggqhkiG9w0DAgICAIAwDgYIKoZIhvcNAwICAgBAMA4GCCqGSIb3DQMEAgIAgDAKBggqhkiG9w0D BzANBgkqhkiG9w0BAQUFAAOBgQBLOiJhtw+czXKryTgRylHQ2rKaKxWhiRYdN2fk4zuu1ez9QHIF 8jSnaYG/3TeyjeRCHzH1AanRRVijHPkq/BUtvEEet40rrjckg1DzCQUldlTNjNNmqF7iCXEzxsry T9on3gWRBf3HkiEFCuzYsGDfOlPG6J0wdaaZT+CJOaB+/zGCBIIwggR+AgEBMIH3MIHiMSAwHgYD VQQKExdIZXdsZXR0LVBhY2thcmQgQ29tcGFueTEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0 d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9y cGEgKGMpMDExMDAuBgNVBAsTJ0NsYXNzIDIgT25TaXRlIEluZGl2aWR1YWwgU3Vic2NyaWJlciBD QTEuMCwGA1UEAxMlQ29sbGFib3JhdGlvbiBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eQIQCnR2p/od 8NAyectoOrGePjAJBgUrDgMCGgUAoIIC4DAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0wNzAxMDMyMTU1MzdaMCMGCSqGSIb3DQEJBDEWBBT8yIlkUG55m/LvLeTMbqOc DxgpQjBnBgkqhkiG9w0BCQ8xWjBYMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG 9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjAKBggqhkiG9w0CBTCCAQgG CSsGAQQBgjcQBDGB+jCB9zCB4jEgMB4GA1UEChMXSGV3bGV0dC1QYWNrYXJkIENvbXBhbnkxHzAd BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBo dHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTAxMTAwLgYDVQQLEydDbGFzcyAyIE9uU2l0 ZSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0ExLjAsBgNVBAMTJUNvbGxhYm9yYXRpb24gQ2VydGlm aWNhdGlvbiBBdXRob3JpdHkCEAp0dqf6HfDQMnnLaDqxnj4wggEKBgsqhkiG9w0BCRACCzGB+qCB 9zCB4jEgMB4GA1UEChMXSGV3bGV0dC1QYWNrYXJkIENvbXBhbnkxHzAdBgNVBAsTFlZlcmlTaWdu IFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJp c2lnbi5jb20vcnBhIChjKTAxMTAwLgYDVQQLEydDbGFzcyAyIE9uU2l0ZSBJbmRpdmlkdWFsIFN1 YnNjcmliZXIgQ0ExLjAsBgNVBAMTJUNvbGxhYm9yYXRpb24gQ2VydGlmaWNhdGlvbiBBdXRob3Jp dHkCEAp0dqf6HfDQMnnLaDqxnj4wDQYJKoZIhvcNAQEBBQAEgYADUuYUMVhzBZhy6AWnWfg/wT2J UENrJ0j1GvwkNQelsEjRH5mHDHoJaAa0eGxB2r4nBcheWe6lOL7nQB6aZnbVeUQFx8JteP4FQ5GQ SIm7vdpJ4R7Pz0Kq0xl0L0LjEICxSowBbuFl4Naqw9IVW8omxBH0+MMNex7golatgZFDagAAAAAA AA== ------=_NextPart_000_024F_01C72F4F.9C466750-- --===============0328013476== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============0328013476==-- From for@amyjacobsen.com Wed Jan 03 16:57:58 2007 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2E7S-00048g-Oe for ips-archive@lists.ietf.org; Wed, 03 Jan 2007 16:57:58 -0500 Received: from 10001295290.0000041933.acesso.oni.pt ([213.58.24.57]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1H2E7H-0005rJ-Gb for ips-archive@lists.ietf.org; Wed, 03 Jan 2007 16:57:56 -0500 Received: from xpto ([132.186.74.23]) by 10001295290.0000041933.acesso.oni.pt with Microsoft SMTPSVC(6.0.3790.1830); Wed, 3 Jan 2007 21:57:47 -0000 Message-ID: <000f01c72f82$269d1070$bf183ad5@xpto> From: "Recommend Webmaster" To: ips-archive@lists.ietf.org Subject: MooreJulie BenzKate HudsonKate MeluaKaty Date: Wed, 3 Jan 2007 21:57:24 -0000 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_000B_01C72F82.269D1070" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 2.6 (++) X-Scan-Signature: 7a0494a0224ca59418dd8f92694c1fdb ------=_NextPart_000_000B_01C72F82.269D1070 Content-Type: multipart/alternative; boundary="----=_NextPart_001_000C_01C72F82.269D1070" ------=_NextPart_001_000C_01C72F82.269D1070 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hartmena suvarimia bartonmya klassnaomi? Forum, blog upload contact help = charts current. Connertera, klerktyra diazyvonne catterfeld links download! Free, model = amp celebrity wallpaper for desktop. Di neziocarre otiscassie lanecat = nealechina chowchloe airdonna canadaseva van. Lovedani, behrdannii = aokidiane lanediane nealdina. Hartmena suvarimia bartonmya klassnaomi coxnikki rubiopaz. Meyerdita von jacobidrew, du toitemilie, de. Links download your free, model amp celebrity wallpaper? Brittany murphy wallpapers and, high resolution. May april january = november september, august stripsaver advert beautiful. Lovedani behrdannii aokidiane lanediane. Mosscate zeta lovedani = behrdannii, aokidiane lanediane nealdina meyerdita von. Desktop bed kbx kb hotness added december. Babe of the day. Connertera klerktyra diazyvonne catterfeld, links, = download your free model. Gaydajaime kingjamie, lynn love. Silvaslucy gracemandy crossmaria bellomaria grazia goodmeg cmelinda, = joan. Gracemandy crossmaria, bellomaria grazia goodmeg cmelinda joan? Browse celebs cec curryalexa kampalexis bledelali. Dallas howardbusy mosscate zeta? Mansonshu qisilvie meissophia bushsophie ellis. Sursoktara reidtaryn, amber stratusuma ziyi. Millermay marshmilla simsmonica novanikki millersky lopezsofia = alticesung hi. Connertera klerktyra diazyvonne catterfeld, links. Wallpaper for = desktop, bed kbx. Mendesevan rachel lillyfaith hillfamke. Leetara connertera klerktyra diazyvonne catterfeld links download your. = Bibblil kimlinda lohanlisa gleavelisa kudrowliv silvaslucy. Gloverlucy cornalujan, millermay marshmilla simsmonica novanikki = millersky? Hartmena suvarimia bartonmya klassnaomi? Coxnikki rubiopaz cruzpeta = alecia. Neziocarre otiscassie lanecat, nealechina chowchloe. Lynn, love skyjessica stonejulia moorejulie benzkate hudsonkate = meluakaty. Babe, of the day browse celebs, cec. September august stripsaver advert beautiful, babes stripping. Weberana, = beatriz barrosana claudia michelsana hickmanana. ------=_NextPart_001_000C_01C72F82.269D1070 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
3D""
Hartmena suvarimia bartonmya = klassnaomi? Forum,=20 blog upload contact help charts current.
Connertera, klerktyra diazyvonne = catterfeld links=20 download! Free, model amp celebrity wallpaper for desktop. Di neziocarre = otiscassie lanecat nealechina chowchloe airdonna canadaseva van. = Lovedani,=20 behrdannii aokidiane lanediane nealdina.
Hartmena suvarimia bartonmya klassnaomi = coxnikki rubiopaz.
Meyerdita von jacobidrew, du = toitemilie, de.
Links download your free, model amp = celebrity wallpaper?
Brittany murphy wallpapers and, high = resolution.=20 May april january november september, august stripsaver advert = beautiful.
Lovedani behrdannii aokidiane = lanediane. Mosscate=20 zeta lovedani behrdannii, aokidiane lanediane nealdina meyerdita = von.
Desktop bed kbx kb hotness added = december.
Babe of the day. Connertera klerktyra = diazyvonne=20 catterfeld, links, download your free model. Gaydajaime kingjamie, lynn = love.
Silvaslucy gracemandy crossmaria = bellomaria grazia=20 goodmeg cmelinda, joan. Gracemandy crossmaria, bellomaria grazia goodmeg = cmelinda joan?
Browse celebs cec curryalexa kampalexis = bledelali.
Dallas howardbusy mosscate = zeta?
Mansonshu qisilvie meissophia = bushsophie ellis.
Sursoktara reidtaryn, amber stratusuma = ziyi.
Millermay marshmilla simsmonica = novanikki millersky=20 lopezsofia alticesung hi.
Connertera klerktyra diazyvonne = catterfeld, links.=20 Wallpaper for desktop, bed kbx. Mendesevan rachel lillyfaith = hillfamke.
Leetara connertera klerktyra diazyvonne = catterfeld=20 links download your. Bibblil kimlinda lohanlisa gleavelisa kudrowliv = silvaslucy.
Gloverlucy cornalujan, millermay = marshmilla=20 simsmonica novanikki millersky?
Hartmena suvarimia bartonmya = klassnaomi? Coxnikki=20 rubiopaz cruzpeta alecia.
Neziocarre otiscassie lanecat, = nealechina chowchloe.
Lynn, love skyjessica stonejulia = moorejulie=20 benzkate hudsonkate meluakaty.
Babe, of the day browse celebs, = cec.
September august stripsaver advert = beautiful, babes=20 stripping. Weberana, beatriz barrosana claudia michelsana=20 hickmanana.
------=_NextPart_001_000C_01C72F82.269D1070-- ------=_NextPart_000_000B_01C72F82.269D1070 Content-Type: image/gif; name="new is.gif" Content-Transfer-Encoding: base64 Content-ID: <000a01c72f82$269d1070$bf183ad5@xpto> R0lGODlhzAGMAIfoAAgODIsGBwCHAICCAAwAf4UAgQCFc7m7t7jayLDM6DUhAG0XAH8sCJMZBcoi AO0sCQBACC1ICkdOAGZMBHgzAKw8DspCANtLAABUDS5WADlcAGVTAHRuAKFYAMxUA9NmCQCFDR2F BEGFAGuFDH2ECZh7AMqAANGDAACuCRWcATaUAG6rAIqfCamhAMWbBdKWCQCzCinFAUTOAGC7AHzC AZuxALjNAunFCwTmABblCUPUAGfUAHLbAJ7cALLcAe3SAA0JMRQASDcAQ2YNM3UJS6UHPc0AON4A TQckNx8TND4XOmMaSHclP5wrTrkiMuMYRwtMSypOTkBNPGFMSnc6TqVAQcNOTdRCOgBdMy5gQT5u R2FnPoJcA5JgNc5gOttfRgqNQxWLSEJ1SmmJP4WASah6MsSBTNeCSwieThmtSjakPWCZMXOkQ5ua TsaUTtmUMQDDTCnEOjS3N2C5SYmzTZ27PMrDNevIPQLiRyPrNkXUTWvWOI3kQKnXOM7kRdPSQQEA iRsAiDgNcloEhnIAe5YAjboAhd4AggMhcRIifzwUi1MtjYkud6IeibEqeN8figA9gBM8dD4/glky dYJGeqkzgbk8jNZIdQxkchtdd0xad1hUcXdYi6Jleb1ujetkiweAdROMezZ+jlyKfIKEc5t6jMp5 jOSKjQ2ZfBqSh0qVfWCSh4akg5uhgLiqjuepewy6hR/NfEnJh1HLiH3LiZK/fMq7iOC6jA7diSLu dEPYcmvogHvkep7odcPqhd7sfwAAxBkAvj8AzWEKt3IAuqEHu8QFy+oItwAZsikmuzUTy2Ept4wX vZciuMEVyeAdvAsysiJKw0hBxG4/x304zK4+zc02t+s8ugBoxydSuUtdtmVss3hpyK1tystjzN1X yw15zR93wUOIsl5zsYOItqx7vsOAx958zgCZshedzECTt2iRyYGjv5GRvbGuxNSZxgzNxBzCyDS8 y2fBtHm+yp/Ozv7w86WYoY2LhPoAAAf2APn/BAUA//8A/wT/8P3//iH5BADk0kMALAAAAADMAYwA Bwj/AO0JHEiwoMGDCBMqXMiwocOHECNKVPivosWLGDNq3Mixo8ePIEOKHEmypMmTKFOqtDixpcuX MGPKnEmzps2bOHPq3Mmzp8+fQIMKHepypdGjSJMq3Ui0qdOnUKNOXEq1qtWrTKVq3cq1q9evYMOK HUu2rNmzaNOqXcu2rVu3WOPKnUu3rt27ePPqPfm2r9+/DfcKHky4sOHDiBMrXsy4sePHkCNLnky5 suXLjwFrfoi5s+fEm0ML/Uy6tGnRqA8ihgGDpAABpiGnnk2bJpjbuGMCARLxdu2whncLtyh8OHEg xysCWA4gtvOOLwkQICgd5u6I1Ws/TyrdYvd/38ET/0j+b/fF8NvTr0R/frx479K7xz9e/CKw+/ft A7u4XH3K1NcddB9BA9rDDz8GIkjddL+FllJ/GkEI4T/4UZhffv8wp1xzGXLYoUUTfugfXWZlZ9By BKFoD3MAGHRggw4+yKKHFmK44Y0imleRjhNOqOOIQFY0kYoGmWhPdswdRCSMTDpEJIsLCpQdki0K pKKJJi7Z5JYHvZigl0Zmhx8wJ1bJ5ZlKmhkfg1ZWqeKVbFI50JNmommnlwJ5ueSbLWqppZ1ppfRj ecjBh5GEHEJoI4Y9ehhiiEFG2lGjFYVnYoEFtgnomWsaeSSbmq7oZpWdgtppinV6uulvpUp56pxm 8v/556pkXQWppLjmqitlOs1K66827SosR73WCeyxyCbL2bDMNquRstBGK+20wDprbaTU9nXttond upe33IJIY7jkBnnrjJOyyJ+6IoGrkrsjeQvvuutqWK+4h47LWAD89uuRAgqUi9VbCxRssED8DpRw mrCGKqpDAOe0sEv9BlBQxQ0BrIDCFiPcsT0NNACyyCEfFDFZdMKk8ckD5ZNPtoBhjGrDDC088cQL EXlzxzMai9DKG9tjcMEQsUwQzj9rjJDOFieMtEAOOFDWzm0mKRDLQHvM8dEfw4xTXRVj9MADFo0N Er8VoZ12ACCFfJHa/6itcUUAn8322hbB/ZHLEer/ixHael9Ud0VR/xN14RsFbtVLVNvj8ssEje3w QFFTLrXXEUVmMEaIG+5AR2FXZLboZH80ON6on356R6fDrThHbmdUMOsB/7P6P0NjBLTtt//Dt1wv HX74QEZfHXTlBQFdPOaAQWk88UEv5DLHMi8Ue0WzY7+A9hZl79H14Dcg0u+cf86R8Idr9Lq6kM5L 2PUXdW7R4AwwkJH7Avvndsn2SC6Q/wtZ3sMYYjSiCcSA/BtZQ4iUwAQSMHozyxgEI/cAg5TsgiIj iAC/hpL16QtCvaOUReSXv+f0B0Kd69zpUmg+wdXOdC8Ukb1E6JH64QtHIPHW7Xrnufm9sHc2DKL9 /952t7i8hAIUOAgEIFCmyQ2kflAsCBKZ95YlWpGJT4QiAwiyRIJocYsDuSJEuhjGK2KxZw+xokDM 6BAzYtEeXwSjPaZoEDKuUYwFsaMaufhGsbzmIBjAgEFQgIKBEPKQ0mrWEgsTyI8scluPBB4VJzkR OwZlI5HcCGsgCYESSoqSPAmkQvShD1r9EZSoTKUqX+LJVlJllbCMpSxnSctVsaaWuOSgXW5TGvzF 5TUbGZQrh+mcUrnnI74UiTGPeRVh4qVn8GEPMaf5mQOZxJpUcaZROiUue72HLvXRiI2o+Y9cdkVV CWmVQIrDm1D5imEFmdFAXvWpNTksZQQiE1CcV/8kUJnzn8XiJzwHWJAA8ekh77RHgIQTwQFmKlPo FIrVmgjQilLkKN9Bl4g2Sq8NJdNC6cIhDiFkzBsKZkwZwWYJLcoTpLiLhtCs1HyUyUyZrkmmGFnU fjja0ZPuZ5w8JadQ80KTd+ITn/X0Z86MdVRjPVSfAVJoOwnqqqGgyE8+k8hQt4qSlyCVolabkpES OtCq1tOsNJuoPFEVq6wGdKKiEmhUuErXdHlzIzHtELtEmsMPavRcGoXMR+tK2FeGhaw7QexWFMvS xgqEMYNVSmQLS9nKvstvWAmsZTfL2c569rN7caxoZwLao4z2LKVNrWpXa5TTuva1sI2tbGdL29r/ 2va2uM0tjFjL29769rdK0S1UgBtc4Rr3uMhNrnKXy9zmOve50K0JcRen3Ola9yPRza4srzsi7Xo3 WtwNr3jHS97ygua76E3vc83L3va6973wha96Vxnf+k53vvjNr37321L7rpa/AAbvewNMYED5t7gF 1s6BF8xg9yb4wchtsF0gTOHfSPjCnK3wQDDMLQ23hcNV8XCMQGwSEZsYMCRO8VZPzOIWu/jFMI6x PVRM4xrb+MZ6kbGOd5xbHPvYMi7+sZCH7B8eGxnFRP7kkZfM5CY3Kcnbyi+Up5wrJyOEylg2jJW3 rKws84XLYA6zmMsS3zGb+cxoTjMtvczm7aj5NMptluSb53zkOH+GznhOiJ33zGdypnnKeQ50S/oc GUGLhdCITrQRDc3oRuNZ0ZCOtKSHGRAAOw== ------=_NextPart_000_000B_01C72F82.269D1070-- From ips-bounces@ietf.org Wed Jan 03 17:16:26 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2EPE-0007ND-On; Wed, 03 Jan 2007 17:16:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2EPC-0007N4-R3 for ips@ietf.org; Wed, 03 Jan 2007 17:16:18 -0500 Received: from imf17aec.mail.bellsouth.net ([205.152.59.65]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2EPB-0005zm-Ef for ips@ietf.org; Wed, 03 Jan 2007 17:16:18 -0500 Received: from ibm57aec.bellsouth.net ([74.245.52.54]) by imf17aec.mail.bellsouth.net with ESMTP id <20070103221616.BPKM3568.imf17aec.mail.bellsouth.net@ibm57aec.bellsouth.net> for ; Wed, 3 Jan 2007 17:16:16 -0500 Received: from IVVTDKV0981 ([74.245.52.54]) by ibm57aec.bellsouth.net with SMTP id <20070103221616.ERMX16959.ibm57aec.bellsouth.net@IVVTDKV0981>; Wed, 3 Jan 2007 17:16:16 -0500 Message-ID: <008601c72f84$c95296d0$01faa8c0@ivivity.com> From: "Eddy Quicksall" To: "Elliott, Robert \(Server Storage\)" , References: Subject: Re: [Ips] Response Fence Flag Date: Wed, 3 Jan 2007 17:16:15 -0500 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.2 (/) X-Scan-Signature: 17e5edc4dfd335965c1d21372171c01c Cc: X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1568447031==" Errors-To: ips-bounces@ietf.org This is a multi-part message in MIME format. --===============1568447031== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0083_01C72F5A.E0304390" This is a multi-part message in MIME format. ------=_NextPart_000_0083_01C72F5A.E0304390 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable How do I get that? T10.org references it as "missing": =20 06-341r1 SAM-4 Response Fence for protocol services Rob Elliott Missing =20 ----- Original Message -----=20 From: Elliott, Robert (Server Storage)=20 To: ips@ietf.org=20 Sent: Wednesday, January 03, 2007 4:55 PM Subject: RE: [Ips] Response Fence Flag If T10 agrees, T10 proposal 06-341 will add it to SAM-4. --=20 Rob Elliott, elliott@hp.com=20 Hewlett-Packard Industry Standard Server Storage Advanced Technology=20 https://ecardfile.com/id/RobElliott=20 -------------------------------------------------------------------------= --- From: Eddy Quicksall [mailto:Quicksall_iSCSI@Bellsouth.net]=20 Sent: Wednesday, January 03, 2007 2:00 PM To: ips@ietf.org Subject: [Ips] Response Fence Flag Section 3.3.1 talks about a Response Fence Flag: SCSI protocol layer instructs the SCSI transport layer of a=20 "Response Fence" associated with the response in question when=20 the "Send Command Complete" protocol data service (SAM-2, clause=20 5.4.2) ... But I don't see any reference to that in SAM-2. Is this strictly an iSCSI flag? Where is the flag specified? Eddy -------------------------------------------------------------------------= ----- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips ------=_NextPart_000_0083_01C72F5A.E0304390 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

How do I get that? T10.org = references it=20 as =93missing=94:

 

06-341r1

SAM-4 = Response=20 Fence for protocol services

Rob=20 Elliott

Missing

----- Original Message -----
From:=20 Elliott, = Robert (Server=20 Storage)
Sent: Wednesday, January 03, = 2007 4:55=20 PM
Subject: RE: [Ips] Response = Fence=20 Flag

If T10 agrees, T10 proposal 06-341 will add = it to=20 SAM-4.
 

-- =
Rob Elliott, elliott@hp.com =
Hewlett-Packard Industry = Standard Server=20 Storage Advanced Technology
https://ecardfile.com/id/Rob= Elliott=20



From: Eddy Quicksall=20 [mailto:Quicksall_iSCSI@Bellsouth.net]
Sent: Wednesday, = January=20 03, 2007 2:00 PM
To: ips@ietf.org
Subject: [Ips] = Response Fence Flag

Section 3.3.1 talks about a Response Fence=20 Flag:
 
SCSI protocol layer instructs the SCSI transport layer of a=20
"Response Fence" associated with the response in question when =
the=20 "Send Command Complete" protocol data service (SAM-2, clause =
5.4.2)=20 ...
 
But I don't see any reference to that in=20 SAM-2.
 
Is this strictly an iSCSI flag? Where is the = flag=20 specified?
 
Eddy

_______________________________________________
Ips mailing=20 = list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips
------=_NextPart_000_0083_01C72F5A.E0304390-- --===============1568447031== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============1568447031==-- From ips-bounces@ietf.org Wed Jan 03 17:45:59 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2Erg-0007mh-8t; Wed, 03 Jan 2007 17:45:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2Ere-0007mc-TJ for ips@ietf.org; Wed, 03 Jan 2007 17:45:42 -0500 Received: from [66.243.153.19] (helo=mx20.brocade.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2Era-0004MB-9x for ips@ietf.org; Wed, 03 Jan 2007 17:45:42 -0500 Received: from blasphemy.brocade.com ([192.168.38.107]) by mx20.brocade.com with ESMTP; 03 Jan 2007 14:45:29 -0800 X-IronPort-AV: i="4.12,234,1165219200"; d="scan'208,217"; a="4708934:sNHT35201033" Received: from hq-exch-1.corp.brocade.com (brono-exch.brocade.com [10.3.8.21]) by blasphemy.brocade.com (Postfix) with ESMTP id E71CC142C8; Wed, 3 Jan 2007 14:45:28 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ips] Response Fence Flag Date: Wed, 3 Jan 2007 14:46:01 -0800 Message-ID: <6002A63FDB393D4F9ADB36DE70C4847501C2F88C@hq-exch-1.corp.brocade.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ips] Response Fence Flag thread-index: AccvclHDNhdyvEmuS1aoDWtomSCtTAAD24WgAAE/FJA= From: "Robert Snively" To: "Elliott, Robert (Server Storage)" , X-Spam-Score: 0.1 (/) X-Scan-Signature: a0534e6179a1e260079328e8b03c7901 Cc: X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0609579760==" Errors-To: ips-bounces@ietf.org This is a multi-part message in MIME format. --===============0609579760== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C72F88.F123717A" This is a multi-part message in MIME format. ------_=_NextPart_001_01C72F88.F123717A Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I need a little tutorial here. Note that this is an architectural hack that is very "un-SCSI" and is not required if the response is qualified with identification information associated with the original request. I know that such qualification exists for commands, but does it exist for task management requests in iSCSI? =20 =20 I know that it does exist for parallel SCSI (which is strictly interlocked) and for SAS and Fibre Channel SCSI, making such "fences" unrequired by those technologies. =20 Note that Rob's previous revision of 06-341 is available on www.t10.org. =20 I would hate to see such a hack creep into the SCSI architecture. =20 Bob =20 ________________________________ From: Elliott, Robert (Server Storage) [mailto:Elliott@hp.com]=20 Sent: Wednesday, January 03, 2007 1:56 PM To: ips@ietf.org Subject: RE: [Ips] Response Fence Flag If T10 agrees, T10 proposal 06-341 will add it to SAM-4. =20 --=20 Rob Elliott, elliott@hp.com=20 Hewlett-Packard Industry Standard Server Storage Advanced Technology=20 https://ecardfile.com/id/RobElliott=20 ________________________________ From: Eddy Quicksall [mailto:Quicksall_iSCSI@Bellsouth.net]=20 Sent: Wednesday, January 03, 2007 2:00 PM To: ips@ietf.org Subject: [Ips] Response Fence Flag =09 =09 Section 3.3.1 talks about a Response Fence Flag: =20 SCSI protocol layer instructs the SCSI transport layer of a=20 "Response Fence" associated with the response in question when=20 the "Send Command Complete" protocol data service (SAM-2, clause 5.4.2) ... =20 But I don't see any reference to that in SAM-2. =20 Is this strictly an iSCSI flag? Where is the flag specified? =20 Eddy ------_=_NextPart_001_01C72F88.F123717A Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I need a little tutorial here.  Note that = this is an=20 architectural hack that
is very "un-SCSI" and is not required if the = response is=20 qualified with identification
information associated with the original = request.  I=20 know that such qualification
exists for commands, but does it exist for task = management=20 requests in
iSCSI? 
 
I know that it does exist for parallel SCSI = (which is=20 strictly interlocked)
and for SAS and Fibre Channel SCSI, making such = "fences"=20 unrequired by
those technologies.
 
Note that Rob's previous revision of 06-341 is = available on=20 www.t10.org.
 
I would hate to see such a hack creep into the = SCSI=20 architecture.
 
Bob
 

From: Elliott, Robert (Server = Storage)=20 [mailto:Elliott@hp.com]
Sent: Wednesday, January 03, 2007 = 1:56=20 PM
To: ips@ietf.org
Subject: RE: [Ips] Response = Fence=20 Flag

If T10 agrees, T10 proposal 06-341 will add = it to=20 SAM-4.
 

-- =
Rob Elliott, = elliott@hp.com=20
Hewlett-Packard = Industry Standard=20 Server Storage Advanced Technology
https://ecardfile.com/id/Rob= Elliott=20



From: Eddy Quicksall=20 [mailto:Quicksall_iSCSI@Bellsouth.net]
Sent: Wednesday, = January 03,=20 2007 2:00 PM
To: ips@ietf.org
Subject: [Ips] = Response=20 Fence Flag

Section 3.3.1 talks about a Response Fence=20 Flag:
 
SCSI protocol layer instructs the SCSI transport layer of a =
"Response=20 Fence" associated with the response in question when
the "Send = Command=20 Complete" protocol data service (SAM-2, clause
5.4.2) ...
 
But I don't see any reference to that in = SAM-2.
 
Is this strictly an iSCSI flag? Where is the flag=20 specified?
 
Eddy
------_=_NextPart_001_01C72F88.F123717A-- --===============0609579760== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============0609579760==-- From ips-bounces@ietf.org Wed Jan 03 18:35:00 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2FdC-0003Vs-9J; Wed, 03 Jan 2007 18:34:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2FdB-0003TC-Hu for ips@ietf.org; Wed, 03 Jan 2007 18:34:49 -0500 Received: from ccerelbas03.cce.hp.com ([161.114.21.106]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2Fd3-00005v-P4 for ips@ietf.org; Wed, 03 Jan 2007 18:34:49 -0500 Received: from cceexg12.americas.cpqcorp.net (cceexg12.americas.cpqcorp.net [16.81.1.38]) by ccerelbas03.cce.hp.com (Postfix) with ESMTP id 5A6F8345C2 for ; Wed, 3 Jan 2007 17:34:41 -0600 (CST) Received: from cceexcsp04.americas.cpqcorp.net ([16.81.1.18]) by cceexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 3 Jan 2007 17:34:40 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ips] Response Fence Flag Date: Wed, 3 Jan 2007 17:34:40 -0600 Message-ID: In-Reply-To: <6002A63FDB393D4F9ADB36DE70C4847501C2F88C@hq-exch-1.corp.brocade.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [Ips] Response Fence Flag Thread-Index: AccvclHDNhdyvEmuS1aoDWtomSCtTAAD24WgAAE/FJAAAOleEA== From: "Elliott, Robert (Server Storage)" To: X-OriginalArrivalTime: 03 Jan 2007 23:34:40.0813 (UTC) FILETIME=[BD6BB5D0:01C72F8F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 6e8a3b85ef670172081194f0b0f68e6f X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0221917181==" Errors-To: ips-bounces@ietf.org This is a multi-part message in MIME format. --===============0221917181== Content-class: urn:content-classes:message Content-Type: multipart/signed; boundary="----=_NextPart_000_0284_01C72F5D.7238FD70"; protocol="application/x-pkcs7-signature"; micalg=SHA1 This is a multi-part message in MIME format. ------=_NextPart_000_0284_01C72F5D.7238FD70 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0285_01C72F5D.7238FD70" ------=_NextPart_001_0285_01C72F5D.7238FD70 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit SAM-3 and SAM-4 require all transport protocols to tag the TMF responses with the requests: "Each SCSI transport protocol shall allow a Received Task Management Function Executed confirming completion of the requested task to be associated with the corresponding Send Task Management Request." Although iSCSI was based on SAM-2, it complies with that rule. The Fence concept is asking for more than that - it wants the target to be able to ensure that all previous commands/TMFs are complete before delivering a particular TMF response (e.g., for a LOGICAL UNIT RESET). Since iSCSI doesn't have ACKs, the target must wait for the next PDU from the initiator with an updated ExpStatSN. 06-341r0 discussed an alternative - add a Delivery Result output to the Send Command Complete and Task Management Function Executed confirmations (as previously proposed in 04-072r0 for a different purpose). This would let the device server/task manager wait for all the previous commands/TMF responses to complete (be ACKed) before proceeding to make additional calls (e.g., Task Management Function Executed for a LOGICAL UNIT RESET). However, iSCSI allows the target port to send a NOP-IN to force delivery of a NOP-OUT with ExpStatSN, rather than passively wait for a PDU to show up. The device server/task manager must instruct the target port when to do this, and the Request Fence argument serves that purpose. Target ports using protocols without such a force mechanism are still OK - they will just wait for protocol-specific delivery confirmations (e.g. ACKs). -- Rob Elliott, elliott@hp.com Hewlett-Packard Industry Standard Server Storage Advanced Technology https://ecardfile.com/id/RobElliott _____ From: Robert Snively [mailto:rsnively@Brocade.COM] Sent: Wednesday, January 03, 2007 4:46 PM To: Elliott, Robert (Server Storage); ips@ietf.org Subject: RE: [Ips] Response Fence Flag I need a little tutorial here. Note that this is an architectural hack that is very "un-SCSI" and is not required if the response is qualified with identification information associated with the original request. I know that such qualification exists for commands, but does it exist for task management requests in iSCSI? I know that it does exist for parallel SCSI (which is strictly interlocked) and for SAS and Fibre Channel SCSI, making such "fences" unrequired by those technologies. Note that Rob's previous revision of 06-341 is available on www.t10.org. I would hate to see such a hack creep into the SCSI architecture. Bob _____ From: Elliott, Robert (Server Storage) [mailto:Elliott@hp.com] Sent: Wednesday, January 03, 2007 1:56 PM To: ips@ietf.org Subject: RE: [Ips] Response Fence Flag If T10 agrees, T10 proposal 06-341 will add it to SAM-4. -- Rob Elliott, elliott@hp.com Hewlett-Packard Industry Standard Server Storage Advanced Technology https://ecardfile.com/id/RobElliott _____ From: Eddy Quicksall [mailto:Quicksall_iSCSI@Bellsouth.net] Sent: Wednesday, January 03, 2007 2:00 PM To: ips@ietf.org Subject: [Ips] Response Fence Flag Section 3.3.1 talks about a Response Fence Flag: SCSI protocol layer instructs the SCSI transport layer of a "Response Fence" associated with the response in question when the "Send Command Complete" protocol data service (SAM-2, clause 5.4.2) ... But I don't see any reference to that in SAM-2. Is this strictly an iSCSI flag? Where is the flag specified? Eddy ------=_NextPart_001_0285_01C72F5D.7238FD70 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

SAM-3 and SAM-4 require all transport = protocols to tag=20 the TMF responses with the requests:

"Each SCSI transport protocol shall = allow a=20 Received Task Management Function Executed confirming completion of the requested task to = be=20 associated with the corresponding Send Task Management = Request."

Although iSCSI was based on = SAM-2, it=20 complies with that rule. The Fence concept is asking for more than that = - it=20 wants the target to be able to ensure that all previous commands/TMFs = are=20 complete before delivering a particular TMF response (e.g., for a = LOGICAL UNIT=20 RESET).  Since iSCSI doesn't have ACKs, the target must wait for = the next=20 PDU from the initiator with an updated=20 ExpStatSN.

06-341r0 discussed an = alternative - add a=20 Delivery Result=20 output to the Send Command Complete and Task Management Function = Executed=20 confirmations (as previously proposed in 04-072r0 for a different = purpose). This=20 would let the device server/task manager wait for all the = previous=20 commands/TMF responses to complete (be ACKed) before proceeding to make=20 additional calls (e.g., Task Management Function Executed for a LOGICAL = UNIT=20 RESET).

However, iSCSI allows the = target port to=20 send a NOP-IN to force delivery of a NOP-OUT with ExpStatSN, rather = than=20 passively wait for a PDU to show up.  The device server/task = manager must=20 instruct the target port when to do this, and the Request Fence = argument=20 serves that purpose.  Target ports using protocols without such a = force=20 mechanism are still OK - they will just wait for protocol-specific = delivery=20 confirmations (e.g.=20 ACKs).

-- =
Rob Elliott, = elliott@hp.com=20
Hewlett-Packard = Industry Standard=20 Server Storage Advanced Technology
https://ecardfile.com/id/Rob= Elliott=20


 

From: Robert Snively=20 [mailto:rsnively@Brocade.COM]
Sent: Wednesday, January 03, = 2007=20 4:46 PM
To: Elliott, Robert (Server Storage);=20 ips@ietf.org
Subject: RE: [Ips] Response Fence=20 Flag

I need a little tutorial here.  Note = that this is an=20 architectural hack that
is very "un-SCSI" and is not required if the = response is=20 qualified with identification
information associated with the original = request.  I=20 know that such qualification
exists for commands, but does it exist for = task=20 management requests in
iSCSI? 
 
I know that it does exist for parallel SCSI = (which is=20 strictly interlocked)
and for SAS and Fibre Channel SCSI, making = such "fences"=20 unrequired by
those technologies.
 
Note that Rob's previous revision of 06-341 = is available=20 on www.t10.org.
 
I would hate to see such a hack creep into = the SCSI=20 architecture.
 
Bob
 

From: Elliott, Robert (Server = Storage)=20 [mailto:Elliott@hp.com]
Sent: Wednesday, January 03, 2007 = 1:56=20 PM
To: ips@ietf.org
Subject: RE: [Ips] Response = Fence=20 Flag

If T10 agrees, T10 proposal 06-341 will add = it to=20 SAM-4.
 

-- =
Rob Elliott, = elliott@hp.com=20
Hewlett-Packard = Industry Standard=20 Server Storage Advanced Technology
https://ecardfile.com/id/Rob= Elliott=20



From: Eddy Quicksall=20 [mailto:Quicksall_iSCSI@Bellsouth.net]
Sent: Wednesday, = January=20 03, 2007 2:00 PM
To: ips@ietf.org
Subject: [Ips] = Response Fence Flag

Section 3.3.1 talks about a Response Fence=20 Flag:
 
SCSI protocol layer instructs the SCSI transport layer of a=20
"Response Fence" associated with the response in question when =
the=20 "Send Command Complete" protocol data service (SAM-2, clause =
5.4.2)=20 ...
 
But I don't see any reference to that in=20 SAM-2.
 
Is this strictly an iSCSI flag? Where is the = flag=20 specified?
 
Eddy
------=_NextPart_001_0285_01C72F5D.7238FD70-- ------=_NextPart_000_0284_01C72F5D.7238FD70 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIN9TCCAwMw ggJsAhEAuS9gzIifoXpGCbhbcGyKrzANBgkqhkiG9w0BAQUFADCBwTELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMTwwOgYDVQQLEzNDbGFzcyAyIFB1YmxpYyBQcmltYXJ5IENl cnRpZmljYXRpb24gQXV0aG9yaXR5IC0gRzIxOjA4BgNVBAsTMShjKSAxOTk4IFZlcmlTaWduLCBJ bmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmswHhcNOTgwNTE4MDAwMDAwWhcNMjgwODAxMjM1OTU5WjCBwTELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMTwwOgYDVQQLEzNDbGFzcyAyIFB1YmxpYyBQcmltYXJ5IENl cnRpZmljYXRpb24gQXV0aG9yaXR5IC0gRzIxOjA4BgNVBAsTMShjKSAxOTk4IFZlcmlTaWduLCBJ bmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmswgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAKeIASF0LOcaA/CY4Zc8DyEI8Zzbl+ma /MIEBhO+X1LIzB4sElYsuAFpLMyZH62wlq55BPITOcF7mLoILOjChBMsqmnpCfTHqQKkQsIjT0rY 8A6i+zFsyeZvmScH9eb0THiebetGhvq5hslU8rLEr9RGHFrJFTD/DWz1LQ5tzn93AgMBAAEwDQYJ KoZIhvcNAQEFBQADgYEAci75f9HxcfvEnvbFXlGKQJi4aPibHIPY4p29/+2h5mbqLwn0ytfqpSuV 9iRghk1ELoOlxC2g0654aW9y2myuCPBjkjfmu8QwF613zEk1qs/Yj9G+txiWR3NqVCI0ZC22FptZ W7RRWTqzCxT0Et9noPStMmResUZyJ4wSe8VEtK4wggQlMIIDjqADAgECAhBWO27ntnEulADNe55i te6UMA0GCSqGSIb3DQEBBQUAMIHBMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIElu Yy4xPDA6BgNVBAsTM0NsYXNzIDIgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3Jp dHkgLSBHMjE6MDgGA1UECxMxKGMpIDE5OTggVmVyaVNpZ24sIEluYy4gLSBGb3IgYXV0aG9yaXpl ZCB1c2Ugb25seTEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazAeFw0wMTA0MjQwMDAw MDBaFw0wOTA0MjMyMzU5NTlaMIHiMSAwHgYDVQQKExdIZXdsZXR0LVBhY2thcmQgQ29tcGFueTEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0 IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDExMDAuBgNVBAsTJ0NsYXNzIDIgT25T aXRlIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQTEuMCwGA1UEAxMlQ29sbGFib3JhdGlvbiBDZXJ0 aWZpY2F0aW9uIEF1dGhvcml0eTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAwHBTCwUTa0hb aHog6TMn4eE7398EjzwgM69HP+K7kNyVfFWph26qBIDYAZLebCYtGIb7k9yTmPRVIWAdYDgw28tQ +Q8belgqEWmwzmv9ISTlEgFvOFLKc+cgI9/FKCiRN2QW12uHsugJhKBwNJ21zB7MDoEdBjGY1MyY 5T1+5TsCAwEAAaOB+jCB9zAPBgNVHRMECDAGAQH/AgEAMEQGA1UdIAQ9MDswOQYLYIZIAYb4RQEH AQEwKjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYTALBgNVHQ8EBAMC AQYwEQYJYIZIAYb4QgEBBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFi ZWwxLTM4MjA0BgNVHR8ELTArMCmgJ6AlhiNodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9wY2EyLWcy LmNybDAdBgNVHQ4EFgQU7+0gzUNFH4NHYBWWQ3JK5MbM5z0wDQYJKoZIhvcNAQEFBQADgYEAQZJR XIBAaNmQVGuF68nKEMhda/Wl56rvk9AuHYkKV0sP/9ktuyn7KMuHKiFj4uAKwCZLiq36wjYqiK3j gk9MZ5TPkAuf1TyWJ1MqnoFn6+7WcQk/leJwbVDTtKV7T0bfTP8fGF57cV8qJ6SSWifpDseYdKh+ CnjP1kI3jkLTJ28wggbBMIIGKqADAgECAhAKdHan+h3w0DJ5y2g6sZ4+MA0GCSqGSIb3DQEBBQUA MIHiMSAwHgYDVQQKExdIZXdsZXR0LVBhY2thcmQgQ29tcGFueTEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlz aWduLmNvbS9ycGEgKGMpMDExMDAuBgNVBAsTJ0NsYXNzIDIgT25TaXRlIEluZGl2aWR1YWwgU3Vi c2NyaWJlciBDQTEuMCwGA1UEAxMlQ29sbGFib3JhdGlvbiBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0 eTAeFw0wNTA2MTkwMDAwMDBaFw0wNzA2MTkyMzU5NTlaMIGTMSAwHgYDVQQKFBdIZXdsZXR0LVBh Y2thcmQgQ29tcGFueTEmMCQGA1UECxQdRW1wbG95bWVudCBTdGF0dXMgLSBFbXBsb3llZXMxDzAN BgNVBAsUBlMvTUlNRTEXMBUGA1UEAxMOUm9iZXJ0IEVsbGlvdHQxHTAbBgkqhkiG9w0BCQEWDmVs bGlvdHRAaHAuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC/MZfCi58Dp+1cot3dstzT F6CfjU4trSwBW89oZZ4j1zB1kHMbZz/fVOandm3r2kg4n2GsVEAyAWWGLXwCIGHoRzx5yQ/Mdo99 yLnoXKPRRNe+ish2MTHHbuBdNWHZ2gAliEenkEacaMlKsTvzJ1lxCPL1XyM9SAhsU2g3ug2KBQID AQABo4IDwzCCA78wKQYDVR0RBCIwIIEOZWxsaW90dEBocC5jb22BDkVsbGlvdHRAaHAuY29tMAwG A1UdEwEB/wQCMAAwDgYDVR0PAQH/BAQDAgWgMB8GA1UdIwQYMBaAFO/tIM1DRR+DR2AVlkNySuTG zOc9MB0GA1UdDgQWBBSH3KjM077e0B3Y+Ur0isKkVCX1rzBXBgNVHR8EUDBOMEygSqBIhkZodHRw Oi8vb25zaXRlY3JsLnZlcmlzaWduLmNvbS9IZXdsZXR0UGFja2FyZENvbXBhbnlTTUlNRS9MYXRl c3RDUkwuY3JsMBYGA1UdJQEB/wQMMAoGCCsGAQUFBwMEMIIBPQYDVR0gBIIBNDCCATAwggEsBgtg hkgBhvhFAQcXAjCCARswKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9DUFMw ge4GCCsGAQUFBwICMIHhMB4WF0hld2xldHQtUGFja2FyZCBDb21wYW55MAMCAQIagb5BdXRob3Jp dHkgdG8gYmluZCBIUCBkb2VzIG5vdCBjb3JyZXNwb25kIHdpdGggdXNlIG9yIHBvc3Nlc3Npb24g b2YgdGhpcyBjZXJ0aWZpY2F0ZS4gSXNzdWVkIHRvIGZhY2lsaXRhdGUgY29tbXVuaWNhdGlvbiB3 aXRoIEhQLiBWZXJpU2lnbidzIENQUyBpbmNvcnAuIEJ5IHJlZmVyZW5jZSBsaWFiLiBsdGQuIChj KTk3IFZlcmlTaWduMIIBMwYIKwYBBQUHAQEEggElMIIBITArBggrBgEFBQcwAYYfaHR0cDovL29u c2l0ZS1vY3NwLnZlcmlzaWduLmNvbTCB8QYIKwYBBQUHMAKkgeQwgeExLjAsBgNVBAMTJUNvbGxh Ym9yYXRpb24gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxMDAuBgNVBAsTJ0NsYXNzIDIgT25TaXRl IEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQTE6MDgGA1UECxMxVGVybXMgb2YgdXNlIGF0IGh0dHBz Oi8vd3d3LnZlcmlzaWduLmNvbS9ycGEoYykwMTEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0 d29yazEgMB4GA1UEChMXSGV3bGV0dC1QYWNrYXJkIENvbXBhbnkwSwYJKoZIhvcNAQkPBD4wPDAO BggqhkiG9w0DAgICAIAwDgYIKoZIhvcNAwICAgBAMA4GCCqGSIb3DQMEAgIAgDAKBggqhkiG9w0D BzANBgkqhkiG9w0BAQUFAAOBgQBLOiJhtw+czXKryTgRylHQ2rKaKxWhiRYdN2fk4zuu1ez9QHIF 8jSnaYG/3TeyjeRCHzH1AanRRVijHPkq/BUtvEEet40rrjckg1DzCQUldlTNjNNmqF7iCXEzxsry T9on3gWRBf3HkiEFCuzYsGDfOlPG6J0wdaaZT+CJOaB+/zGCBIIwggR+AgEBMIH3MIHiMSAwHgYD VQQKExdIZXdsZXR0LVBhY2thcmQgQ29tcGFueTEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0 d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9y cGEgKGMpMDExMDAuBgNVBAsTJ0NsYXNzIDIgT25TaXRlIEluZGl2aWR1YWwgU3Vic2NyaWJlciBD QTEuMCwGA1UEAxMlQ29sbGFib3JhdGlvbiBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eQIQCnR2p/od 8NAyectoOrGePjAJBgUrDgMCGgUAoIIC4DAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0wNzAxMDMyMzM0MzlaMCMGCSqGSIb3DQEJBDEWBBQ8nU08LJhm/MHCq53x1JD+ c3ECNDBnBgkqhkiG9w0BCQ8xWjBYMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG 9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjAKBggqhkiG9w0CBTCCAQgG CSsGAQQBgjcQBDGB+jCB9zCB4jEgMB4GA1UEChMXSGV3bGV0dC1QYWNrYXJkIENvbXBhbnkxHzAd BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBo dHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTAxMTAwLgYDVQQLEydDbGFzcyAyIE9uU2l0 ZSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0ExLjAsBgNVBAMTJUNvbGxhYm9yYXRpb24gQ2VydGlm aWNhdGlvbiBBdXRob3JpdHkCEAp0dqf6HfDQMnnLaDqxnj4wggEKBgsqhkiG9w0BCRACCzGB+qCB 9zCB4jEgMB4GA1UEChMXSGV3bGV0dC1QYWNrYXJkIENvbXBhbnkxHzAdBgNVBAsTFlZlcmlTaWdu IFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJp c2lnbi5jb20vcnBhIChjKTAxMTAwLgYDVQQLEydDbGFzcyAyIE9uU2l0ZSBJbmRpdmlkdWFsIFN1 YnNjcmliZXIgQ0ExLjAsBgNVBAMTJUNvbGxhYm9yYXRpb24gQ2VydGlmaWNhdGlvbiBBdXRob3Jp dHkCEAp0dqf6HfDQMnnLaDqxnj4wDQYJKoZIhvcNAQEBBQAEgYA8QegulTZLjw84q3J3M8BE8R3u 4FcCf35uXuMYUKvmIHW6cRwMt1hxJbBdWYdPX03T0EypuEBJ3yejhlbi6XeJwbO8fBK+I0TznVb6 /MGg0i8SlQxRinMR5vyCwdqoqPYiB/JTB93XYsVGprXR32FD72MqA7zWInPHgI6X4UrRLQAAAAAA AA== ------=_NextPart_000_0284_01C72F5D.7238FD70-- --===============0221917181== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============0221917181==-- From hengfengscc@126.com Thu Jan 04 11:35:30 2007 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2VYv-0004Ue-UZ for ips-archive@lists.ietf.org; Thu, 04 Jan 2007 11:35:30 -0500 Received: from [212.95.252.147] (helo=dex-252-147.dxi.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2VYt-0005zJ-QR for ips-archive@lists.ietf.org; Thu, 04 Jan 2007 11:35:29 -0500 Received: from 202.108.5.164 (HELO mx.126.split.netease.com) by lists.ietf.org with esmtp ()Y7()/884 2*3(W) id =T>5(@-+*)+1F-0B for ips-archive@lists.ietf.org; Thu, 4 Jan 2007 16:35:06 +0000 Date: Thu, 4 Jan 2007 16:35:06 +0000 From: Quotes.com Alert! X-Mailer: The Bat! (v3.62.03) Professional X-Priority: 3 (Normal) Message-ID: <534628171.11874052785385@thebat.net> To: ips-archive@lists.ietf.org Subject: WDSC(WORLDSOURCE INC.) this special for you MIME-Version: 1.0 Content-Type: text/html; charset=iso-8859-2 Content-Transfer-Encoding: quoted-printable X-Spam: Not detected X-Spam-Score: 4.4 (++++) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 WDSC(WORLDSOURCE INC.) this special for you Chad in anti-Sudan alliance President Omar al-Bashir told state TV: "The g= overnment of Sudan welcomes all financial, material, logistic or technical = assistance from the UN in order to strengthen the AU mission in Darfur." Su= dan has always rejected plans to replace the AU force with a larger, strong= er UN mission.
Untitled Document
WORLDSOURCE INC.
BUY WDSC (WORLDSOURCE INC)
VALUABLE = THING AFTER NEW YEAR. THIS IS GOING TO EXPLODE!
JUST VIEW= FOR HOT NEWS ABOUT THIS COMPANY. THE ALARM IS STARTED!!!
YOUR BROK= ERAGE SITE ASSISTS YOU TO READ THE FULL NEWS ON WDSC.
IT=92S GE= TTING GROWTH ALMOST EVERY HOUR! MORE THAN 80%= DAILY FROM BEGINNING PRICE.
HARDLY YO= U HAD A OPPORTUNITY TO TRIPLE YOUR INVESTMENTS JUST PER 1 WEEK.
CALL YOU = BROKERS IMMEDIATELY AND MAKE THEM TO BUY IT. DO NOT MISS YOUR POSSIBILITY!!= !
GO WDSC!

On Thursday, UN chief Kofi Annan had said a compromise had been reached for= a hybrid UN-AU force, to break the deadlock over the Darfur mission. More = than 200,000 people have died in three years of conflict in the region. His= Foreign Minister Lam Akol specified that "there should be no talk about a = mixed force". President Omar al-Bashir told state TV: "The government of Su= dan welcomes all financial, material, logistic or technical assistance from= the UN in order to strengthen the AU mission in Darfur."
From ips-bounces@ietf.org Thu Jan 04 13:01:42 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2Wts-0000lk-9c; Thu, 04 Jan 2007 13:01:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2Wtq-0000he-NH for ips@ietf.org; Thu, 04 Jan 2007 13:01:10 -0500 Received: from [208.185.105.18] (helo=mx10.brocade.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2Wtm-0003qT-Mn for ips@ietf.org; Thu, 04 Jan 2007 13:01:10 -0500 Received: from scooby.brocade.com ([192.168.39.118]) by mx10.brocade.com with ESMTP; 04 Jan 2007 10:01:05 -0800 X-IronPort-AV: i="4.12,239,1165219200"; d="scan'208,217"; a="286040:sNHT44580291" Received: from hq-exch-1.corp.brocade.com (brono-list.brocade.com [10.3.8.21]) by scooby.brocade.com (Postfix) with ESMTP id D755C25801B; Thu, 4 Jan 2007 09:59:07 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ips] Response Fence Flag Date: Thu, 4 Jan 2007 10:01:36 -0800 Message-ID: <6002A63FDB393D4F9ADB36DE70C4847501C2FB3A@hq-exch-1.corp.brocade.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ips] Response Fence Flag thread-index: AccvclHDNhdyvEmuS1aoDWtomSCtTAAD24WgAAE/FJAAAOleEAAlMfSw From: "Robert Snively" To: "Elliott, Robert (Server Storage)" , X-Spam-Score: 0.1 (/) X-Scan-Signature: 6852087d2a39b5d20c975154ae1cd415 Cc: X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2110807743==" Errors-To: ips-bounces@ietf.org This is a multi-part message in MIME format. --===============2110807743== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7302A.60F381FA" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7302A.60F381FA Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The problem is that the definition of "previous" in this context is most likely flawed. =20 The "Response Fence" is merely an internal and untestable state machine input that attempts to order the transmission of responses in the target port's queue. It does nothing to improve the overall ordering of the responses at the application client. =20 Drivers for generic SCSI transports must always be aware that requested operations report completion with a more or less arbitrary time relationship to each other and must be designed to tolerate that. =20 =20 Using LOGICAL UNIT RESET as an example, the operation does not act only on the device server. As it passes down through the initiator stack, it may clean out previously offered commands that have not yet been transported. Then as it passes up through the target stack, it may clean out previously offered commands that have not yet been operated on. As it passes through the device server execution path, it may clean out previously offered commands that have begun execution and some that have completed execution without yet responding. As its=20 response passes back down the target stack, it may clean up commands that have completed for which the response has not yet been transmitted, and as it passes back up the initiator stack, it may clean up commands for which the response has been transmitted, but not yet been made available to the driver or application. SAM-4 attempts to define the passage through the target port, through the device server, and back to the target port. However, beyond the initiator port is outside the SAM-4 scope, and even where it is defined, the "shall ensure"s are unlikely to be testable and in some cases not implementable.=20 =20 Will I sometimes get command complete indications for commands after a LOGICAL UNIT RESET response is received? You bet. Response Fence doesn't change that. =20 Will I sometimes get command aborted indications for commands after a=20 LOGICAL UNIT RESET is response is received? You bet. Response Fence doesn't change that. =20 Is this a problem? It never has been in the past, why is it now? =20 Can you test the corner conditions for a fence operation? I doubt it. The existence of the "Response Fence" argument is internal to the target implementation and invisible to testing. =20 Bob =20 ________________________________ From: Elliott, Robert (Server Storage) [mailto:Elliott@hp.com]=20 Sent: Wednesday, January 03, 2007 3:35 PM To: ips@ietf.org Subject: RE: [Ips] Response Fence Flag SAM-3 and SAM-4 require all transport protocols to tag the TMF responses with the requests: "Each SCSI transport protocol shall allow a Received Task Management Function Executed confirming completion of the requested task to be associated with the corresponding Send Task Management Request." Although iSCSI was based on SAM-2, it complies with that rule. The Fence concept is asking for more than that - it wants the target to be able to ensure that all previous commands/TMFs are complete before delivering a particular TMF response (e.g., for a LOGICAL UNIT RESET). Since iSCSI doesn't have ACKs, the target must wait for the next PDU from the initiator with an updated ExpStatSN. 06-341r0 discussed an alternative - add a Delivery Result output to the Send Command Complete and Task Management Function Executed confirmations (as previously proposed in 04-072r0 for a different purpose). This would let the device server/task manager wait for all the previous commands/TMF responses to complete (be ACKed) before proceeding to make additional calls (e.g., Task Management Function Executed for a LOGICAL UNIT RESET). However, iSCSI allows the target port to send a NOP-IN to force delivery of a NOP-OUT with ExpStatSN, rather than passively wait for a PDU to show up. The device server/task manager must instruct the target port when to do this, and the Request Fence argument serves that purpose. Target ports using protocols without such a force mechanism are still OK - they will just wait for protocol-specific delivery confirmations (e.g. ACKs). --=20 Rob Elliott, elliott@hp.com=20 Hewlett-Packard Industry Standard Server Storage Advanced Technology=20 https://ecardfile.com/id/RobElliott=20 =20 ________________________________ From: Robert Snively [mailto:rsnively@Brocade.COM]=20 Sent: Wednesday, January 03, 2007 4:46 PM To: Elliott, Robert (Server Storage); ips@ietf.org Subject: RE: [Ips] Response Fence Flag =09 =09 I need a little tutorial here. Note that this is an architectural hack that is very "un-SCSI" and is not required if the response is qualified with identification information associated with the original request. I know that such qualification exists for commands, but does it exist for task management requests in iSCSI? =20 =20 I know that it does exist for parallel SCSI (which is strictly interlocked) and for SAS and Fibre Channel SCSI, making such "fences" unrequired by those technologies. =20 Note that Rob's previous revision of 06-341 is available on www.t10.org. =20 I would hate to see such a hack creep into the SCSI architecture. =20 Bob =20 ________________________________ From: Elliott, Robert (Server Storage) [mailto:Elliott@hp.com]=20 Sent: Wednesday, January 03, 2007 1:56 PM To: ips@ietf.org Subject: RE: [Ips] Response Fence Flag =09 =09 If T10 agrees, T10 proposal 06-341 will add it to SAM-4. =20 --=20 Rob Elliott, elliott@hp.com=20 Hewlett-Packard Industry Standard Server Storage Advanced Technology=20 https://ecardfile.com/id/RobElliott=20 ________________________________ From: Eddy Quicksall [mailto:Quicksall_iSCSI@Bellsouth.net]=20 Sent: Wednesday, January 03, 2007 2:00 PM To: ips@ietf.org Subject: [Ips] Response Fence Flag =09 =09 Section 3.3.1 talks about a Response Fence Flag: =20 SCSI protocol layer instructs the SCSI transport layer of a=20 "Response Fence" associated with the response in question when=20 the "Send Command Complete" protocol data service (SAM-2, clause=20 5.4.2) ... =20 But I don't see any reference to that in SAM-2. =20 Is this strictly an iSCSI flag? Where is the flag specified? =20 Eddy ------_=_NextPart_001_01C7302A.60F381FA Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
The problem is that the definition of = "previous" in this=20 context is most likely flawed.
 
The "Response Fence" is merely an internal = and=20 untestable state machine input that
attempts to order the transmission of = responses in the=20 target port's queue.
It  does=20 nothing to improve the overall ordering of the responses at the=20 application
client.
 
Drivers for generic SCSI transports must always = be aware=20 that requested operations
report completion with a more or less arbitrary = time=20 relationship to each other and must be
designed to tolerate that.  =
 
Using LOGICAL UNIT RESET as an example, the = operation does=20 not act only on
the device server.  As it passes down = through the=20 initiator stack, it may clean out
previously offered commands that have not yet = been=20 transported.  Then as it
passes up through the target stack, it may = clean out=20 previously offered commands
that have not yet been operated on.  As it = passes=20 through the device server
execution path, it may clean out previously = offered=20 commands that have begun
execution and some that have completed = execution=20 without yet responding.  As its
response passes back down the target stack, it = may clean up=20 commands
that have completed for which the response has = not yet been=20 transmitted, and as
it passes back up the initiator stack, it may = clean up=20 commands for which the
response has been transmitted, but not yet been = made=20 available to the driver or
application.  SAM-4 attempts to define the = passage=20 through the target port,
through the device server, and back to the = target=20 port.  However, beyond the
initiator port is outside the SAM-4 scope, = and even=20 where it is defined,
the "shall ensure"s are unlikely to be = testable and in=20 some cases not implementable. 
 
Will I sometimes get command complete = indications for=20 commands after
a LOGICAL UNIT RESET response is = received?  You bet.  Response=20 Fence doesn't
change that.
 
Will I sometimes get command=20 aborted indications for commands after=20 a
LOGICAL UNIT RESET is response is = received?  You=20 bet.  Response Fence
doesn't change that.
 
Is this a problem?  It never = has been in the=20 past, why is it now?
 
Can you test the corner conditions for a fence=20 operation?  I doubt it.  The
existence of the "Response Fence" argument is = internal to=20 the target
implementation and invisible to=20 testing.
 
Bob
 

From: Elliott, Robert (Server = Storage)=20 [mailto:Elliott@hp.com]
Sent: Wednesday, January 03, 2007 = 3:35=20 PM
To: ips@ietf.org
Subject: RE: [Ips] Response = Fence=20 Flag

SAM-3 and SAM-4 require all transport = protocols to tag=20 the TMF responses with the requests:

"Each SCSI transport = protocol shall=20 allow a Received Task Management Function Executed = confirming completion of the requested task to = be=20 associated with the corresponding Send Task Management = Request."

Although = iSCSI was=20 based on SAM-2, it complies with that rule. The Fence concept is asking = for more=20 than that - it wants the target to be able to ensure that all previous=20 commands/TMFs are complete before delivering a particular TMF response = (e.g.,=20 for a LOGICAL UNIT RESET).  Since iSCSI doesn't have ACKs, the = target must=20 wait for the next PDU from the initiator with an updated=20 ExpStatSN.

06-341r0 = discussed an=20 alternative - add a Delivery = Result output to the Send Command Complete and = Task=20 Management Function Executed confirmations (as previously proposed in = 04-072r0=20 for a different purpose). This would let the device server/task=20 manager wait for all the previous commands/TMF responses to = complete=20 (be ACKed) before proceeding to make additional calls (e.g., Task = Management=20 Function Executed for a LOGICAL UNIT=20 RESET).

However, = iSCSI allows=20 the target port to send a NOP-IN to force delivery of a NOP-OUT=20 with ExpStatSN, rather than passively wait for a PDU to show = up.  The=20 device server/task manager must instruct the target port when to do = this,=20 and the Request Fence argument serves that purpose.  Target = ports=20 using protocols without such a force mechanism are still OK - they will = just=20 wait for protocol-specific delivery confirmations (e.g.=20 ACKs).

-- =
Rob Elliott, = elliott@hp.com=20
Hewlett-Packard = Industry Standard=20 Server Storage Advanced Technology
https://ecardfile.com/id/Rob= Elliott=20


 

From: Robert Snively=20 [mailto:rsnively@Brocade.COM]
Sent: Wednesday, January 03, = 2007=20 4:46 PM
To: Elliott, Robert (Server Storage);=20 ips@ietf.org
Subject: RE: [Ips] Response Fence=20 Flag

I need a little tutorial here.  Note = that this is an=20 architectural hack that
is very "un-SCSI" and is not required if the = response is=20 qualified with identification
information associated with the original = request.  I=20 know that such qualification
exists for commands, but does it exist for = task=20 management requests in
iSCSI? 
 
I know that it does exist for parallel SCSI = (which is=20 strictly interlocked)
and for SAS and Fibre Channel SCSI, making = such "fences"=20 unrequired by
those technologies.
 
Note that Rob's previous revision of 06-341 = is available=20 on www.t10.org.
 
I would hate to see such a hack creep into = the SCSI=20 architecture.
 
Bob
 

From: Elliott, Robert (Server = Storage)=20 [mailto:Elliott@hp.com]
Sent: Wednesday, January 03, 2007 = 1:56=20 PM
To: ips@ietf.org
Subject: RE: [Ips] Response = Fence=20 Flag

If T10 agrees, T10 proposal 06-341 will add = it to=20 SAM-4.
 

-- =
Rob Elliott, = elliott@hp.com=20
Hewlett-Packard = Industry Standard=20 Server Storage Advanced Technology
https://ecardfile.com/id/Rob= Elliott=20



From: Eddy Quicksall=20 [mailto:Quicksall_iSCSI@Bellsouth.net]
Sent: Wednesday, = January=20 03, 2007 2:00 PM
To: ips@ietf.org
Subject: [Ips] = Response Fence Flag

Section 3.3.1 talks about a Response Fence=20 Flag:
 
SCSI protocol layer instructs the SCSI transport layer of a=20
"Response Fence" associated with the response in question when =
the=20 "Send Command Complete" protocol data service (SAM-2, clause =
5.4.2)=20 ...
 
But I don't see any reference to that in=20 SAM-2.
 
Is this strictly an iSCSI flag? Where is the = flag=20 specified?
 
Eddy
------_=_NextPart_001_01C7302A.60F381FA-- --===============2110807743== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============2110807743==-- From ips-bounces@ietf.org Thu Jan 04 14:17:15 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2Y5I-0006sr-EV; Thu, 04 Jan 2007 14:17:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2Y5H-0006sK-2w for ips@ietf.org; Thu, 04 Jan 2007 14:17:03 -0500 Received: from web51901.mail.yahoo.com ([206.190.48.64]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H2Y5D-00005G-2V for ips@ietf.org; Thu, 04 Jan 2007 14:17:03 -0500 Received: (qmail 99548 invoked by uid 60001); 4 Jan 2007 19:10:19 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:Cc:MIME-Version:Content-Type; b=JdQPrvYIy+TIBVniolgXSUA383h++p8VaAiDqlvk0vO35EbusSgLUfug/MNzNjrENDu6n5rVzkjPeWABGUGox789kfNNu1qLDUNOs4mZ4D3M/2BkQkLMr1Pna2ZLYoLNq2CqQGhE4B0ynmb8iM8Ki16W4C27GC17QUyqE1fAR+Y= ; Message-ID: <20070104191019.99546.qmail@web51901.mail.yahoo.com> Received: from [15.227.217.75] by web51901.mail.yahoo.com via HTTP; Thu, 04 Jan 2007 11:10:19 PST Date: Thu, 4 Jan 2007 11:10:19 -0800 (PST) From: "Mallikarjun C." Subject: Re: [Ips] Response Fence Flag To: ips@ietf.org MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 69aba9e925a1047819f53b40fa4fc4e6 Cc: gop@us.ibm.com X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2124812723==" Errors-To: ips-bounces@ietf.org --===============2124812723== Content-Type: multipart/alternative; boundary="0-681642646-1167937819=:98283" --0-681642646-1167937819=:98283 Content-Type: text/plain; charset=ascii Content-Transfer-Encoding: quoted-printable Bob,=0A=0AResponse Fence prompts an end-to-end acknowledgement, it is not "= merely an internal" artifact with no consequence. This e2e ack can happen = in a SCSI transport protocol specific way.=0A=0AResponse ordering is an iss= ue for a very small % of task/TMF responses on a multi-connection iSCSI ses= sion, due to the network skew between the different connections participati= ng in one I_T nexus. IPS WG discussed this during the Dallas IETF and subs= equently on the mailing list, there is already consensus that it is an issu= e. I also understand that iSCSI is not alone here.=0A=0APlease see the con= ference proceedings slides from the Dallas IETF for additional information:= =0Ahttp://www3.ietf.org/proceedings/06mar/slides/ips-0.pdf=0A=0ASection 3.3= of http://www.ietf.org/internet-drafts/draft-ietf-ips-iscsi-impl-guide-03.= txt discusses the semantics and section 3.3.3 lists specific cases that we = know of today that require such a response ordering. Section 3.3.2 defines= what the "transport protocol specific" way to realize e2e ack for iSCSI is= .=0A=0AIf you would like to chat offline, feel free to give Rob or myself a= call.=0A=0AThanks.=0A=0AMallikarjun=0A=0A=0A----- Original Message ----=0A= From: Robert Snively =0ATo: "Elliott, Robert (Server = Storage)" ; ips@ietf.org=0ASent: Thursday, January 4, 2007 = 10:01:36 AM=0ASubject: RE: [Ips] Response Fence Flag=0A=0A=0AThe problem is= that the definition of "previous" in this context is most likely flawed.= =0A =0AThe "Response Fence" is merely an internal and untestable state mach= ine input that=0Aattempts to order the transmission of responses in the tar= get port's queue.=0AIt does nothing to improve the overall ordering of the= responses at the application=0Aclient.=0A =0ADrivers for generic SCSI tran= sports must always be aware that requested operations=0Areport completion w= ith a more or less arbitrary time relationship to each other and must be=0A= designed to tolerate that. =0A =0AUsing LOGICAL UNIT RESET as an example, = the operation does not act only on=0Athe device server. As it passes down = through the initiator stack, it may clean out=0Apreviously offered commands= that have not yet been transported. Then as it=0Apasses up through the ta= rget stack, it may clean out previously offered commands=0Athat have not ye= t been operated on. As it passes through the device server=0Aexecution pat= h, it may clean out previously offered commands that have begun=0Aexecution= and some that have completed execution without yet responding. As its =0A= response passes back down the target stack, it may clean up commands=0Athat= have completed for which the response has not yet been transmitted, and as= =0Ait passes back up the initiator stack, it may clean up commands for whic= h the=0Aresponse has been transmitted, but not yet been made available to t= he driver or=0Aapplication. SAM-4 attempts to define the passage through t= he target port,=0Athrough the device server, and back to the target port. = However, beyond the=0Ainitiator port is outside the SAM-4 scope, and even w= here it is defined,=0Athe "shall ensure"s are unlikely to be testable and i= n some cases not implementable. =0A =0AWill I sometimes get command complet= e indications for commands after=0Aa LOGICAL UNIT RESET response is receive= d? You bet. Response Fence doesn't=0Achange that.=0A =0AWill I sometimes = get command aborted indications for commands after a =0ALOGICAL UNIT RESET = is response is received? You bet. Response Fence=0Adoesn't change that.= =0A =0AIs this a problem? It never has been in the past, why is it now?=0A= =0ACan you test the corner conditions for a fence operation? I doubt it. = The=0Aexistence of the "Response Fence" argument is internal to the target= =0Aimplementation and invisible to testing.=0A =0ABob=0A =0A=0A=0A=0A=0AFro= m: Elliott, Robert (Server Storage) [mailto:Elliott@hp.com] =0ASent: Wednes= day, January 03, 2007 3:35 PM=0ATo: ips@ietf.org=0ASubject: RE: [Ips] Respo= nse Fence Flag=0A=0A=0ASAM-3 and SAM-4 require all transport protocols to t= ag the TMF responses with the requests:=0A"Each SCSI transport protocol sha= ll allow a Received Task Management Function Executed confirming completion= of the requested task to be associated with the corresponding Send Task Ma= nagement Request."=0AAlthough iSCSI was based on SAM-2, it complies with th= at rule. The Fence concept is asking for more than that - it wants the targ= et to be able to ensure that all previous commands/TMFs are complete before= delivering a particular TMF response (e.g., for a LOGICAL UNIT RESET). Si= nce iSCSI doesn't have ACKs, the target must wait for the next PDU from the= initiator with an updated ExpStatSN.=0A06-341r0 discussed an alternative -= add a Delivery Result output to the Send Command Complete and Task Managem= ent Function Executed confirmations (as previously proposed in 04-072r0 for= a different purpose). This would let the device server/task manager wait f= or all the previous commands/TMF responses to complete (be ACKed) before pr= oceeding to make additional calls (e.g., Task Management Function Executed = for a LOGICAL UNIT RESET).=0AHowever, iSCSI allows the target port to send = a NOP-IN to force delivery of a NOP-OUT with ExpStatSN, rather than passive= ly wait for a PDU to show up. The device server/task manager must instruct= the target port when to do this, and the Request Fence argument serves tha= t purpose. Target ports using protocols without such a force mechanism are= still OK - they will just wait for protocol-specific delivery confirmation= s (e.g. ACKs).=0A-- =0ARob Elliott, elliott@hp.com =0AHewlett-Packard Indus= try Standard Server Storage Advanced Technology =0Ahttps://ecardfile.com/id= /RobElliott =0A=0A =0A=0A=0AFrom: Robert Snively [mailto:rsnively@Brocade.C= OM] =0ASent: Wednesday, January 03, 2007 4:46 PM=0ATo: Elliott, Robert (Ser= ver Storage); ips@ietf.org=0ASubject: RE: [Ips] Response Fence Flag=0A=0A= =0AI need a little tutorial here. Note that this is an architectural hack = that=0Ais very "un-SCSI" and is not required if the response is qualified w= ith identification=0Ainformation associated with the original request. I k= now that such qualification=0Aexists for commands, but does it exist for ta= sk management requests in=0AiSCSI? =0A =0AI know that it does exist for pa= rallel SCSI (which is strictly interlocked)=0Aand for SAS and Fibre Channel= SCSI, making such "fences" unrequired by=0Athose technologies.=0A =0ANote = that Rob's previous revision of 06-341 is available on www.t10.org.=0A =0AI= would hate to see such a hack creep into the SCSI architecture.=0A =0ABob= =0A =0A=0A=0A=0A=0AFrom: Elliott, Robert (Server Storage) [mailto:Elliott@h= p.com] =0ASent: Wednesday, January 03, 2007 1:56 PM=0ATo: ips@ietf.org=0ASu= bject: RE: [Ips] Response Fence Flag=0A=0A=0AIf T10 agrees, T10 proposal 06= -341 will add it to SAM-4.=0A =0A-- =0ARob Elliott, elliott@hp.com =0AHewle= tt-Packard Industry Standard Server Storage Advanced Technology =0Ahttps://= ecardfile.com/id/RobElliott =0A=0A=0A=0A=0A=0A=0AFrom: Eddy Quicksall [mail= to:Quicksall_iSCSI@Bellsouth.net] =0ASent: Wednesday, January 03, 2007 2:00= PM=0ATo: ips@ietf.org=0ASubject: [Ips] Response Fence Flag=0A=0A=0ASection= 3.3.1 talks about a Response Fence Flag:=0A =0ASCSI protocol layer instruc= ts the SCSI transport layer of a =0A"Response Fence" associated with the re= sponse in question when =0Athe "Send Command Complete" protocol data servic= e (SAM-2, clause =0A5.4.2) ...=0A =0ABut I don't see any reference to that = in SAM-2.=0A =0AIs this strictly an iSCSI flag? Where is the flag specified= ?=0A =0AEddy=0A_______________________________________________=0AIps mailin= g list=0AIps@ietf.org=0Ahttps://www1.ietf.org/mailman/listinfo/ips=0A=0A___= _______________________________________________=0ADo You Yahoo!?=0ATired of= spam? Yahoo! Mail has the best spam protection around =0Ahttp://mail.yaho= o.com --0-681642646-1167937819=:98283 Content-Type: text/html; charset=ascii Content-Transfer-Encoding: quoted-printable
Bob,
=0A
 
=0A
= Response Fence prompts an end-to-end acknowledgement, it is not "merely an = internal" artifact with no consequence.  This e2e ack can happen in a = SCSI transport protocol specific way.
=0A
 
=0AResponse ordering is an issue for a very small % of task/TMF response= s on a multi-connection iSCSI session, due to the network skew between= the different connections participating in one I_T nexus.  IPS W= G discussed this during the Dallas IETF and subsequently on the mailing lis= t, there is already consensus that it is an issue.  I also understand = that iSCSI is not alone here.
=0A
 
=0A
= Please see the conference proceedings slides from the Dallas IETF for addit= ional information:
=0A=0A
 
=0A
Section 3.3 of http://www.ietf.org/internet-drafts/draft-ietf-ips-iscsi-impl-gui= de-03.txt discusses the semantics and section 3.3.3 lists spe= cific cases that we know of today that require such a response ordering.&nb= sp; Section 3.3.2 defines what the "transport protocol specific" way to rea= lize e2e ack for iSCSI is.
=0A
 
=0A
If yo= u would like to chat offline, feel free to give Rob or myself a call.
= =0A
 
=0A
Thanks.
=0A
 =0A
Mallikarjun

=0A
----- Original Message = ----
From: Robert Snively <rsnively@Brocade.COM>
To: "Elliott, = Robert (Server Storage)" <Elliott@hp.com>; ips@ietf.org
Sent: Thur= sday, January 4, 2007 10:01:36 AM
Subject: RE: [Ips] Response Fence Flag=

=0A=0A=0A
The problem i= s that the definition of "previous" in this context is most likely flawed.<= /FONT>
=0A
 =0A
The "Response Fence" is merely an = internal and untestable state machine input that
=0Aattempts to order the transmission of responses&n= bsp;in the target port's queue.
=0A
It  does nothing to improve the overall= ordering of the responses at the application
=0A
client.
=0A
 
=0A
Driver= s for generic SCSI transports must always be aware that requested operation= s
=0A
report completion wit= h a more or less arbitrary time relationship to each other and must be
=0A
designed to tolerate that.&= nbsp;
=0A
&n= bsp;
=0A
<= FONT face=3DArial color=3D#0000ff size=3D2>Using LOGICAL UNIT RESET as an e= xample, the operation does not act only on
=0A
the device server.  As it passes down through th= e initiator stack, it may clean out
=0A
previously offered commands that have not yet been transported= .  Then as it
=0A
pass= es up through the target stack, it may clean out previously offered command= s
=0A
that have not yet bee= n operated on.  As it passes through the device server=0A
execution path, it may clean out previ= ously offered commands that have begun
=0A
execution and some that have completed execution witho= ut yet responding.  As its
=0A
response passes back down the target stack, it may clean up comma= nds
=0A
that have completed= for which the response has not yet been transmitted, and as<= /DIV>=0A
it passes back up the initiator stack= , it may clean up commands for which the
=0A
response has been transmitted, but not yet been made av= ailable to the driver or
=0A
= application.  SAM-4 attempts to define the passage through the targe= t port,
=0A
through the dev= ice server, and back to the target port.  However, beyond the
=0A
initiator port is o= utside the SAM-4 scope, and even where it is defined,<= /FONT>
=0A
the "shall ensure"= s are unlikely to be testable and in some cases not implementable. 
=0A<= DIV dir=3Dltr align=3Dleft> 
=0A
Will I sometimes get command complete indications for commands= after
=0A
a LO= GICAL UNIT RESET response is received?  You bet.  Response Fence doesn't
=0A
change that.=
=0A
 
=0A
Will I sometimes get command aborted= indications for commands after a =
=0A
LOGICAL UNIT RESET is re= sponse is received?  You bet.  Response Fence
= =0A
doesn't change that.
= =0A
 
=0A
Is this a problem?  It never has b= een in the past, why is it now?
=0A
 
=0A
Can yo= u test the corner conditions for a fence operation?  I doubt it. = The
=0A
existence of the "= Response Fence" argument is internal to the target
=0Aimplementation and invisible to testing.=
=0A
 
=0A=
Bob
=0A
 

=0A
=0A
=0AFrom: Elliott, Robert (Server Storage) [mailto:El= liott@hp.com]
Sent: Wednesday, January 03, 2007 3:35 PM
To= : ips@ietf.org
Subject: RE: [Ips] Response Fence Flag

=0A
=0A
=0A

SAM-3 and SAM-4 require all transport protocols to tag the = TMF responses with the requests:

=0A

"Each SCSI transport protocol shall allow a Re= ceived Task Management Function Executed confirming completion of the requested task to be associated with= the corresponding Send Task Management Request."

=0A

Although iSCSI was based = on SAM-2, it complies with that rule. The Fence concept is asking for more = than that - it wants the target to be able to ensure that all previous comm= ands/TMFs are complete before delivering a particular TMF response (e.g., f= or a LOGICAL UNIT RESET).  Since iSCSI doesn't have ACKs, the target m= ust wait for the next PDU from the initiator with an updated ExpStatSN.

=0A

<= SPAN class=3D381195622-03012007>06-341r0 discussed an alternative - add a D= elivery Result output to the Send Command Complete and Task Ma= nagement Function Executed confirmations (as previously proposed in 04-072r= 0 for a different purpose). This would let the device server/task manager&n= bsp;wait for all the previous commands/TMF responses to complete (be A= CKed) before proceeding to make additional calls (e.g., Task Management Fun= ction Executed for a LOGICAL UNIT RESET).

=0A

However, iSCSI allows the target port to send a NOP-IN to force deliver= y of a NOP-OUT with ExpStatSN, rather than passively wait for a PDU to= show up.  The device server/task manager must instruct the target por= t when to do this, and the Request Fence argument serves that purpose.=   Target ports using protocols without such a force mechanism are stil= l OK - they will just wait for protocol-specific delivery confirmations (e.= g. ACKs).

=0A

--
Ro= b Elliott, elliott@hp.com
Hewlett-Packard Industry Standard Server Storage Advanced= Technology
https://ecardfile.com/id/RobElliott

=0A


 

=0A=0A
=0A
=0AFrom: Robert Snively [mailto:rsnively@Brocade.COM= ]
Sent: Wednesday, January 03, 2007 4:46 PM
To: Elliot= t, Robert (Server Storage); ips@ietf.org
Subject: RE: [Ips] Respo= nse Fence Flag

=0A
=0A
I need a little tutorial here.  Note that this is an architectu= ral hack that
=0A
is very "= un-SCSI" and is not required if the response is qualified with identificati= on
=0A
information associat= ed with the original request.  I know that such qualification
=0A
= exists for commands, but does i= t exist for task management requests in
=0A
iSCSI? 
=0A
 
=0A
I know= that it does exist for parallel SCSI (which is strictly interlocked)
=0A
and for SAS and Fibre Channe= l SCSI, making such "fences" unrequired by
=0A
those technologies.
=0A
 
=0A
Note that Rob's previous revision of 06-341 is available on www.t10.org.
=0A
 
= =0A
I would hate to see such a hack creep int= o the SCSI architecture.
=0A
=  
=0A
Bob
=0A
 

=0A=
=0A=0AFrom: Elliott, Rober= t (Server Storage) [mailto:Elliott@hp.com]
Sent: Wednesday, Janu= ary 03, 2007 1:56 PM
To: ips@ietf.org
Subject: RE: [Ips= ] Response Fence Flag

=0A
=0A
If T10 agrees, T10 proposal 06-341 will add it to SAM-4.
=0A
 
= =0A
= =0A

--
Rob Elliott, elliott@hp.com
Hewlett-Packard Industry Standard Server Storage Adv= anced Technology
https://ecardfile.com/id/RobElliott


<= /SPAN>

=0A
=0A=0A
=0AFrom: Eddy Quicksall [= mailto:Quicksall_iSCSI@Bellsouth.net]
Sent: Wednesday, January 0= 3, 2007 2:00 PM
To: ips@ietf.org
Subject: [Ips] Respons= e Fence Flag

=0A
=0A
Secti= on 3.3.1 talks about a Response Fence Flag:
=0A
 
=0A
SCSI protocol layer instructs the SCSI tran= sport layer of a
"Response Fence" associated with the response in quest= ion when
the "Send Command Complete" protocol data service (SAM-2, clau= se
5.4.2) ...
=0A
 
=0A
But I don= 't see any reference to that in SAM-2.
=0A
<= /FONT> 
=0A
Is this strictly an iSCSI flag? Wh= ere is the flag specified?
=0A
 =
=0A
Eddy
=0A=
_______________________________________________
Ips mailing listIps@ietf.org
https://www1.ietf.org/mailman/listinfo/ips
=0A<= DIV style=3D"FONT-SIZE: 12pt; FONT-FAMILY: times new roman, new york, times= , serif">

______________________________________________= ____
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam pro= tection around
http://mail.yahoo.com --0-681642646-1167937819=:98283-- --===============2124812723== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============2124812723==-- From ips-bounces@ietf.org Thu Jan 04 15:27:43 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2ZBM-0007Ns-Jz; Thu, 04 Jan 2007 15:27:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2ZBL-0007Nn-Gq for ips@ietf.org; Thu, 04 Jan 2007 15:27:23 -0500 Received: from web51912.mail.yahoo.com ([206.190.48.75]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H2ZBC-0003rL-Fc for ips@ietf.org; Thu, 04 Jan 2007 15:27:23 -0500 Received: (qmail 55074 invoked by uid 60001); 4 Jan 2007 20:27:14 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=yCojocY+R3MoN8zfw4XzEN2qwlxU9mwuZgU8doqY4KuBYFCzm4s/N1GhzpMbJecxkHcmksTNgQCZ69kV9LxmBCrSnB9FxigaUhN41v8YUyU9fG1mcq8gp0sDottILBcuAK4SnrEAaI4k6SlSiAlqduCb/Hr7w3OvJKwCoJDA99o= ; Message-ID: <20070104202714.55072.qmail@web51912.mail.yahoo.com> Received: from [15.227.217.75] by web51912.mail.yahoo.com via HTTP; Thu, 04 Jan 2007 12:27:14 PST Date: Thu, 4 Jan 2007 12:27:14 -0800 (PST) From: "Mallikarjun C." Subject: Re: [Ips] iSCSI Implementer's Guide - WG Last Call status To: ips@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ascii Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ips-bounces@ietf.org Ken,=0A=0AI think the concern here is that whatever text we put in could ea= sily be misinterpreted as granting the target implementation the freedom to= "properly understand" the initiator's intent, when the problem is that the= initiator's intent is either fuzzy or plain confusing from the PDU content= s and the target does not really know what the "proper intent" is.=0A=0AMal= likarjun=0A=0A=0A=0A----- Original Message ----=0AFrom: "Sandars, Ken" =0ATo: Eddy Quicksall ;= Black_David@emc.com; ips@ietf.org=0ASent: Monday, January 1, 2007 5:05:30 = PM=0ASubject: RE: [Ips] iSCSI Implementer's Guide - WG Last Call status=0A= =0A=0AHappy New Gregorian Year,=0A=0AI support Eddy's request for some word= s to suggest that target=0Aimplementations should be allowed to handle init= iator errors in a manner=0Awhich does not damage the target behaviour.=0A= =0ATarget behaviour should be evaluated by its transmissions on the wire=0A= and via data integrity tests. Test suites and protocol analysers should=0An= ot assume what the target's actions will be as a result of illegal=0Ainitia= tor behaviour unless explicitly defined in RFC3720.=0A=0AFor example, say a= n initiator issues a Logout Request PDU with reason=0Acode 0 (close the ses= sion), but sets the CID field to the current=0Aconnection. The target MAY p= rocess this command as though there is no=0Aerror on the part of the initia= tor. A test suite or protocol analyser=0AMUST NOT penalise the target if it= does so.=0A=0AAnother example is an initiator which sets either the W or/a= nd R bits in=0Aa SCSI Command Request PDU which has an Expected Data Transf= er Length of=0A0.=0A=0AFinally, a test-suite which sets a non-zero value in= reserved fields for=0Ainitiator PDUs should not expect the target to check= these values.=0A=0AClearly a target which performs additional checking of = the initiator's=0APDUs is likely to be more robust when faced with receptio= n errors when=0Anot using digests.=0A=0A=0ACheers=0AKen=0A=0A-----Original = Message-----=0AFrom: Eddy Quicksall [mailto:Quicksall_iSCSI@Bellsouth.net] = =0ASent: Tuesday, 2 January 2007 00:54=0ATo: Black_David@emc.com; ips@ietf.= org=0ASubject: Re: [Ips] iSCSI Implementer's Guide - WG Last Call status=0A= =0AActually I didn't want to discourage targets from checking but to point= =0Aout that checking is not required unless the RFC specifically requires= =0Ait. The note could in fact encourage checking where performance is not= =0Aaffected.=0A=0AEddy=0A=0A----- Original Message -----=0AFrom: =0ATo: =0ASent: Thursday, December 28, 2006 3:27 P= M=0ASubject: [Ips] iSCSI Implementer's Guide - WG Last Call status=0A=0A=0A= The Working Group Last Call on this draft nominally ended on=0ADecember 18t= h, but there was no reason to treat that as a hard=0Acutoff. I am now endi= ng the WG Last Call on this draft, although=0Alist discussion of issues sho= uld be continued.=0A=0AThere have been two issues raised during this WGLC:= =0A(1) Task Management - how to deal with uncooperative third-=0Aparty init= iators. This issue has been resolved=0Aon the list.=0A(2) Target checks - = whether to discourage targets from=0Achecking for initiator mistakes that t= he target can=0Atolerate. At the moment, I think the "rough consensus"=0Ao= f the WG is not to do this - if anyone other than=0AEddy thinks this is imp= ortant to clarify, they need=0Ato speak up promptly after the holidays.=0A= =0AThe process from here is that Mallikarjun will submit a=0Arevised versio= n of the draft in the near future (there are=0Astill some details to be wor= ked out on the list). I will=0Abe completely out of action (no email) the = first two weeks=0Aof January, so there will be time for people to check for= =0Aproblems/issues/etc. I will check the revised draft and=0Asend it to La= rs with a request for RFC publication sometime=0Ain the second half of Janu= ary (probably during the week of=0AJanuary 22nd).=0A=0AThanks,=0A--David=0A= =0A----------------------------------------------------=0ADavid L. Black, S= enior Technologist=0AEMC Corporation, 176 South St., Hopkinton, MA 01748= =0A+1 (508) 293-7953 FAX: +1 (508) 293-7786=0Ablack_david@emc.c= om Mobile: +1 (978) 394-7754=0A-------------------------------------= ---------------=0A=0A=0A_______________________________________________=0AI= ps mailing list=0AIps@ietf.org=0Ahttps://www1.ietf.org/mailman/listinfo/ips= =0A=0A=0A_______________________________________________=0AIps mailing lis= t=0AIps@ietf.org=0Ahttps://www1.ietf.org/mailman/listinfo/ips=0A=0A________= _______________________________________=0AIps mailing list=0AIps@ietf.org= =0Ahttps://www1.ietf.org/mailman/listinfo/ips=0A=0A________________________= __________________________=0ADo You Yahoo!?=0ATired of spam? Yahoo! Mail h= as the best spam protection around =0Ahttp://mail.yahoo.com _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Thu Jan 04 16:12:49 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2Zt6-0000sI-IB; Thu, 04 Jan 2007 16:12:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2Zt5-0000pg-8Q for ips@ietf.org; Thu, 04 Jan 2007 16:12:35 -0500 Received: from exprod8og54.obsmtp.com ([64.18.3.90]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H2Zt2-0003Yz-Qp for ips@ietf.org; Thu, 04 Jan 2007 16:12:35 -0500 Received: from source ([12.110.134.31]) by exprod8ob54.obsmtp.com ([64.18.7.12]) with SMTP; Thu, 04 Jan 2007 13:11:03 PST Received: from pkoning.equallogic.com ([172.16.1.128]) by M31.equallogic.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 4 Jan 2007 16:11:52 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17821.28055.200384.34143@gargle.gargle.HOWL> Date: Thu, 4 Jan 2007 16:11:51 -0500 From: Paul Koning To: cb_mallikarjun@yahoo.com Subject: Re: [Ips] iSCSI Implementer's Guide - WG Last Call status References: <20070104202714.55072.qmail@web51912.mail.yahoo.com> X-Mailer: VM 7.17 under 21.4 (patch 19) "Constant Variable" XEmacs Lucid X-OriginalArrivalTime: 04 Jan 2007 21:11:52.0438 (UTC) FILETIME=[F4AF3160:01C73044] X-Spam-Score: 0.6 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: ips@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ips-bounces@ietf.org >>>>> "Mallikarjun" == Mallikarjun C writes: Mallikarjun> Ken, I think the concern here is that whatever text we Mallikarjun> put in could easily be misinterpreted as granting the Mallikarjun> target implementation the freedom to "properly Mallikarjun> understand" the initiator's intent, when the problem is Mallikarjun> that the initiator's intent is either fuzzy or plain Mallikarjun> confusing from the PDU contents and the target does not Mallikarjun> really know what the "proper intent" is. I think we've been here before. To me the answer is very simple. If an initiator obeys the protocol rules, it is entitled to see behavior specified by the RFC. If it violates the rules, it is not entitled to anything. A target MAY check for protocol violations, but (unless the RFC specifically requires it, which it should only do for strong reasons) it is under no obligation to check. If it checks, then the initiator will probably see a fairly clean reaction to a protocol error (for example a disconnect, or a reject of some sort). If the target doesn't check, a faulty initiator may see undefined behavior. Ditto in the other direction (swap "initiator" and "target" in the above). Requiring "sane" reactions (however one might define those) to non-sane inputs is not a good thing to ask for. It imposes substantial overhead on good implementations, and it only benefits bad implementations. paul _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Thu Jan 04 17:44:48 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2bKB-0003oL-36; Thu, 04 Jan 2007 17:44:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2bK9-0003nV-RQ for ips@ietf.org; Thu, 04 Jan 2007 17:44:37 -0500 Received: from web51915.mail.yahoo.com ([206.190.48.78]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H2bK7-0005lN-3k for ips@ietf.org; Thu, 04 Jan 2007 17:44:37 -0500 Received: (qmail 40520 invoked by uid 60001); 4 Jan 2007 22:44:34 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=1zzeQnyq9G5K2VCdcnHxcIsY4lI9O/4nv3b5g+HCL5ex1pmaDFNxsNe3nCjqaEKt4gDkU/vqInAiYXNZg4DuxrUdutcCExWDxHeRgTjjzjR2Q6mirf0Uc8LJ0Mu5T/SjDxS+sCj4TQGIvOwj8q/bvVpbMhzlL1sDXrDW//m1oyc= ; Message-ID: <20070104224434.40518.qmail@web51915.mail.yahoo.com> Received: from [15.227.217.75] by web51915.mail.yahoo.com via HTTP; Thu, 04 Jan 2007 14:44:34 PST Date: Thu, 4 Jan 2007 14:44:34 -0800 (PST) From: "Mallikarjun C." Subject: Re: [Ips] iSCSI Implementer's Guide - WG Last Call status To: ips@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ascii Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.6 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ips-bounces@ietf.org Paul,=0A=0AAgree with everything you wrote.=0A=0ARFC 3720 does not require = sane reactions to non-sane inputs. This draft should not say anything that= suggests target/initiator may draw sane interpretations to non-sane inputs= either.=0A=0ASounds like an agreement to not add any new text to me.=0A=0A= Mallikarjun=0A=0A=0A----- Original Message ----=0AFrom: Paul Koning =0ATo: cb_mallikarjun@yahoo.com=0ACc: ips@ietf.org=0ASent:= Thursday, January 4, 2007 1:11:51 PM=0ASubject: Re: [Ips] iSCSI Implemente= r's Guide - WG Last Call status=0A=0A=0A>>>>> "Mallikarjun" =3D=3D Mallikar= jun C writes:=0A=0AMallikarjun> Ken, I think the= concern here is that whatever text we=0AMallikarjun> put in could easily b= e misinterpreted as granting the=0AMallikarjun> target implementation the f= reedom to "properly=0AMallikarjun> understand" the initiator's intent, when= the problem is=0AMallikarjun> that the initiator's intent is either fuzzy = or plain=0AMallikarjun> confusing from the PDU contents and the target does= not=0AMallikarjun> really know what the "proper intent" is.=0A=0AI think w= e've been here before.=0A=0ATo me the answer is very simple. If an initiat= or obeys the protocol=0Arules, it is entitled to see behavior specified by = the RFC. If it=0Aviolates the rules, it is not entitled to anything.=0A=0A= A target MAY check for protocol violations, but (unless the RFC=0Aspecifica= lly requires it, which it should only do for strong reasons)=0Ait is under = no obligation to check. If it checks, then the initiator=0Awill probably s= ee a fairly clean reaction to a protocol error (for=0Aexample a disconnect,= or a reject of some sort). If the target=0Adoesn't check, a faulty initia= tor may see undefined behavior.=0A=0ADitto in the other direction (swap "in= itiator" and "target" in the=0Aabove). =0A=0ARequiring "sane" reactions (ho= wever one might define those) to=0Anon-sane inputs is not a good thing to a= sk for. It imposes=0Asubstantial overhead on good implementations, and it = only benefits bad=0Aimplementations.=0A=0A paul=0A=0A___________________= _______________________________=0ADo You Yahoo!?=0ATired of spam? Yahoo! M= ail has the best spam protection around =0Ahttp://mail.yahoo.com _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Thu Jan 04 18:05:47 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2beL-00008y-Rl; Thu, 04 Jan 2007 18:05:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2beJ-000076-FB for ips@ietf.org; Thu, 04 Jan 2007 18:05:27 -0500 Received: from exprod8og51.obsmtp.com ([64.18.3.84]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H2beI-0000FL-3V for ips@ietf.org; Thu, 04 Jan 2007 18:05:27 -0500 Received: from source ([12.110.134.31]) by exprod8ob51.obsmtp.com ([64.18.7.12]) with SMTP; Thu, 04 Jan 2007 15:05:19 PST Received: from pkoning.equallogic.com ([172.16.1.128]) by M31.equallogic.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 4 Jan 2007 18:00:45 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17821.34588.829394.359949@gargle.gargle.HOWL> Date: Thu, 4 Jan 2007 18:00:44 -0500 From: Paul Koning To: cb_mallikarjun@yahoo.com Subject: Re: [Ips] iSCSI Implementer's Guide - WG Last Call status References: <20070104224434.40518.qmail@web51915.mail.yahoo.com> X-Mailer: VM 7.17 under 21.4 (patch 19) "Constant Variable" XEmacs Lucid X-OriginalArrivalTime: 04 Jan 2007 23:00:46.0037 (UTC) FILETIME=[2B034850:01C73054] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: ips@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ips-bounces@ietf.org >>>>> "Mallikarjun" == Mallikarjun C writes: Mallikarjun> Paul, Agree with everything you wrote. Mallikarjun> RFC 3720 does not require sane reactions to non-sane Mallikarjun> inputs. This draft should not say anything that Mallikarjun> suggests target/initiator may draw sane interpretations Mallikarjun> to non-sane inputs either. Great summary. Mallikarjun> Sounds like an agreement to not add any new text to me. Well, Eddy raised the issue a while back that some people writing conformance tests were interpreting "initiator must do X" as "target must check that initiator does X". That's clearly an incorrect conclusion. But given that people make this mistake, I wonder if a note in the guide saying "unless RFC 3720 specifically requires it, an implementation is not required to do protocol conformance checking on incoming message", or something like that, would be helpful. paul _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From laqueta@asiamail.com Thu Jan 04 21:58:29 2007 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2fHp-0006aE-2b for ips-archive@lists.ietf.org; Thu, 04 Jan 2007 21:58:29 -0500 Received: from [122.4.21.217] (helo=asiamail.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H2fHj-0001EZ-0P for ips-archive@lists.ietf.org; Thu, 04 Jan 2007 21:58:29 -0500 Message-ID: <44cd01c73085$f95947f0$90576eac@laqueta> From: "Sharon" To: "Olivia" Subject: Insure the Best possible Income Date: Fri, 05 Jan 2007 04:57:17 +1000 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1158 X-Spam-Score: 3.8 (+++) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Good day Sharon, My wife and I would like to say thank you for training us into this exciting industry. We were involved in the fashion industry for 16 years and owned a very successful chain industry of boutiques. After losing the lot in the recession I began looking for good chance to somehow create wealth once again with less investment. Then you introduced me to this business. My wife and I started your course and were extremely excited when we acquired life-changing results. We personally used the unbelievable advanced reporting services and made our job easy and quickly. Finally, we found the perfect business 0pportunity to control our own business. We used your fill in the blank forms you provided and mailed them to the appropriate firms then just waited for the money to arrive. We really had a marvelous time and made substantial income in this business. My wife and I work from our home. We work our own hours. We are our own bosses. We have the luxury of working with whom we want, when we want, where we want. Looks like my wife and I can retire wealthy in 4-5 years. Thanks, Adrian L. Colorado City This could be you! Dial the number below where we provide you more in-depth points about our system at 0 outlay or responsibility. You have nothing to lose and lots to gain. 3 0 3-395-3900 Above line to study more or to bring to a hault receiving additional information and then to see location I have often thought my existence uncalled for, since you Earth people are so stupid and ignorant that you seem unlikely ever to master the secret of electrical power Oh, we have some great masters among us! cried Rob, rather nettled at this statementj13m15 From 888momo444@docomo.ne.jp Thu Jan 04 22:37:36 2007 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2ftg-0003rh-ED for ips-archive@lists.ietf.org; Thu, 04 Jan 2007 22:37:36 -0500 Received: from [220.194.46.198] (helo=kimu01.alpha.co.jp) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2ftd-0007Kc-JB for ips-archive@lists.ietf.org; Thu, 04 Jan 2007 22:37:36 -0500 Subject: =?ISO-2022-JP?B?grGC8YLJgr+CzYFBU05TgWmXoIFqiV6JY46WlrGLx4LFgreBQg==?= From: SNSij^c To: ips-archive@lists.ietf.org Message-ID: 20070105121623 Content-Type: text/plain; charset="SHIFT_JIS" Content-Transfer-Encoding: 7bit MIME-Version: 1.0 Date: Fri, 5 Jan 2007 12:16:24 +0900 (JST) X-Spam-Score: 1.6 (+) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 AJl@񂪂Ȃ ZbNXthlbg[LOTCg SNSij֏҂Ă܂B bZ[WF wȐlƋCyɃZbNXƂāASNSɓ܂B ƋCɂȂ̂ł悩FBljĂ炦Ɗł ZbNX̎FXmĂȂ̂ŁAFXĂقł! PUǂłHHx LURLAJl̓o^ʂ܂B 炩珵Ҏ҂snsijgbvy[W邱Ƃł܂B http://imp.fem.jp/89498849.htm @R~jeBEG^[eCg@@@@@@@@@@@@ @ZbNXthlbg[LOTCg@SNSijĉH@ SNSij́Ao[菵҂ꂽ݂̂ō\ĂA {̃ZbNXthlbg[LOTCgłB SNSijȂ炱܂ňȏɃZt֌Wł Mł鋌m̗FlAm荇Ƃ̃ZbNXCt̊}邳܂܂ c[pӂĂ܂B uFl̗Flvƌ𗬂ł SNSijgΗFlm̃lbg[NǂāuFl̗FlvƂ̌𗬂 ȒPɂł܂Bɂ͂Ȃ̗FlqMłlbg[N `Ă܂BSNSij͂ǂŌqĂlmW܂R~jeB łAꂪ\[Vlbg[LO̓łB SNSijȂL̓ǂݏA܂łp̓ĽJł ݂Ȃ͓LJ邱ƂɂėFlSNSijɓo^ĂlXɑ 𔭐M邱Ƃ”\łBɂ܂ŎgpĂ̓LEuO gASNSij̓LgI邱Ƃł܂B SNSij֎Q http://imp.fem.jp/89498849.htm ł́AQS肨҂Ă܂B \ SNSij \\\\\\\\\\\\\\\\\\\ R~jeBEG^[eCg SNSij URL Fhttp://imp.fem.jp/ ^c F SNS \\\\\\\\\\\\\\\\\\\\\\\\\ From ips-bounces@ietf.org Fri Jan 05 11:25:39 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2rsm-0003SD-G3; Fri, 05 Jan 2007 11:25:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2rsk-0003S3-NS for ips@ietf.org; Fri, 05 Jan 2007 11:25:26 -0500 Received: from imf21aec.mail.bellsouth.net ([205.152.59.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2rsd-0007Mr-6W for ips@ietf.org; Fri, 05 Jan 2007 11:25:26 -0500 Received: from ibm63aec.bellsouth.net ([74.245.52.54]) by imf21aec.mail.bellsouth.net with ESMTP id <20070105162512.DUVA16300.imf21aec.mail.bellsouth.net@ibm63aec.bellsouth.net> for ; Fri, 5 Jan 2007 11:25:12 -0500 Received: from IVVTDKV0981 ([74.245.52.54]) by ibm63aec.bellsouth.net with SMTP id <20070105162512.OUCH3802.ibm63aec.bellsouth.net@IVVTDKV0981>; Fri, 5 Jan 2007 11:25:12 -0500 Message-ID: <002801c730e6$11fd6920$01faa8c0@ivivity.com> From: "Eddy Quicksall" To: "Paul Koning" , References: <20070104224434.40518.qmail@web51915.mail.yahoo.com> <17821.34588.829394.359949@gargle.gargle.HOWL> Subject: Re: [Ips] iSCSI Implementer's Guide - WG Last Call status Date: Fri, 5 Jan 2007 11:25:10 -0500 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: ips@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ips-bounces@ietf.org I remember long ago talking about this when we were developing the RFC. I remember some people clearly saying that if the RFC said "must do X" then it meant that the peer "must check X". I didn't pursue the issue because it seemed to be of little importance. But as time went on and the draft got finalized, I ran into cases where that view was still taken to hart. Of course "the customer is always right" so I added checks. More recently I thought that since this guide was being written that maybe a simple statement could be made to clarify the issue. I'm not debating the issue of the importance of making a check or even the criteria for making the check. Eddy ----- Original Message ----- From: "Paul Koning" To: Cc: Sent: Thursday, January 04, 2007 6:00 PM Subject: Re: [Ips] iSCSI Implementer's Guide - WG Last Call status >>>>>> "Mallikarjun" == Mallikarjun C writes: > > Mallikarjun> Paul, Agree with everything you wrote. > > Mallikarjun> RFC 3720 does not require sane reactions to non-sane > Mallikarjun> inputs. This draft should not say anything that > Mallikarjun> suggests target/initiator may draw sane interpretations > Mallikarjun> to non-sane inputs either. > > Great summary. > > Mallikarjun> Sounds like an agreement to not add any new text to me. > > Well, Eddy raised the issue a while back that some people writing > conformance tests were interpreting "initiator must do X" as "target > must check that initiator does X". That's clearly an incorrect > conclusion. But given that people make this mistake, I wonder if a > note in the guide saying "unless RFC 3720 specifically requires it, an > implementation is not required to do protocol conformance checking on > incoming message", or something like that, would be helpful. > > paul > > > _______________________________________________ > Ips mailing list > Ips@ietf.org > https://www1.ietf.org/mailman/listinfo/ips > _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Fri Jan 05 11:59:08 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2sPG-00005K-0K; Fri, 05 Jan 2007 11:59:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2sPE-00005E-QE for ips@ietf.org; Fri, 05 Jan 2007 11:59:00 -0500 Received: from imf21aec.mail.bellsouth.net ([205.152.59.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2sPA-0002zi-UV for ips@ietf.org; Fri, 05 Jan 2007 11:59:00 -0500 Received: from ibm63aec.bellsouth.net ([74.245.52.54]) by imf21aec.mail.bellsouth.net with ESMTP id <20070105165852.IDUB16300.imf21aec.mail.bellsouth.net@ibm63aec.bellsouth.net> for ; Fri, 5 Jan 2007 11:58:52 -0500 Received: from IVVTDKV0981 ([74.245.52.54]) by ibm63aec.bellsouth.net with SMTP id <20070105165851.PXRZ3802.ibm63aec.bellsouth.net@IVVTDKV0981>; Fri, 5 Jan 2007 11:58:51 -0500 Message-ID: <004201c730ea$c45f9f30$01faa8c0@ivivity.com> From: "Eddy Quicksall" To: "Robert Snively" , "Elliott, Robert \(Server Storage\)" , References: <6002A63FDB393D4F9ADB36DE70C4847501C2FB3A@hq-exch-1.corp.brocade.com> Subject: Re: [Ips] Response Fence Flag Date: Fri, 5 Jan 2007 11:58:47 -0500 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ba883ba659fcd62a05a0ed0aea6f612 Cc: X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1824556791==" Errors-To: ips-bounces@ietf.org This is a multi-part message in MIME format. --===============1824556791== Content-Type: multipart/alternative; boundary="----=_NextPart_000_003F_01C730C0.DB505EC0" This is a multi-part message in MIME format. ------=_NextPart_000_003F_01C730C0.DB505EC0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable >From an earlier email I think that Response Fence is only a proposal in = T10 (http://www.t10.org:80/doc06.htm). If so shouldn't iSCSI wait a bit = until this has been ratified? Eddy ----- Original Message -----=20 From: Robert Snively=20 To: Elliott, Robert (Server Storage) ; ips@ietf.org=20 Sent: Thursday, January 04, 2007 1:01 PM Subject: RE: [Ips] Response Fence Flag The problem is that the definition of "previous" in this context is = most likely flawed. The "Response Fence" is merely an internal and untestable state = machine input that attempts to order the transmission of responses in the target port's = queue. It does nothing to improve the overall ordering of the responses at = the application client. Drivers for generic SCSI transports must always be aware that = requested operations report completion with a more or less arbitrary time relationship to = each other and must be designed to tolerate that. =20 Using LOGICAL UNIT RESET as an example, the operation does not act = only on the device server. As it passes down through the initiator stack, it = may clean out previously offered commands that have not yet been transported. Then = as it passes up through the target stack, it may clean out previously = offered commands that have not yet been operated on. As it passes through the device = server execution path, it may clean out previously offered commands that have = begun execution and some that have completed execution without yet = responding. As its=20 response passes back down the target stack, it may clean up commands that have completed for which the response has not yet been = transmitted, and as it passes back up the initiator stack, it may clean up commands for = which the response has been transmitted, but not yet been made available to the = driver or application. SAM-4 attempts to define the passage through the target = port, through the device server, and back to the target port. However, = beyond the initiator port is outside the SAM-4 scope, and even where it is = defined, the "shall ensure"s are unlikely to be testable and in some cases not = implementable.=20 Will I sometimes get command complete indications for commands after a LOGICAL UNIT RESET response is received? You bet. Response Fence = doesn't change that. Will I sometimes get command aborted indications for commands after a=20 LOGICAL UNIT RESET is response is received? You bet. Response Fence doesn't change that. Is this a problem? It never has been in the past, why is it now? Can you test the corner conditions for a fence operation? I doubt it. = The existence of the "Response Fence" argument is internal to the target implementation and invisible to testing. Bob -------------------------------------------------------------------------= ----- From: Elliott, Robert (Server Storage) [mailto:Elliott@hp.com]=20 Sent: Wednesday, January 03, 2007 3:35 PM To: ips@ietf.org Subject: RE: [Ips] Response Fence Flag SAM-3 and SAM-4 require all transport protocols to tag the TMF = responses with the requests: "Each SCSI transport protocol shall allow a Received Task Management = Function Executed confirming completion of the requested task to be = associated with the corresponding Send Task Management Request." Although iSCSI was based on SAM-2, it complies with that rule. The = Fence concept is asking for more than that - it wants the target to be = able to ensure that all previous commands/TMFs are complete before = delivering a particular TMF response (e.g., for a LOGICAL UNIT RESET). = Since iSCSI doesn't have ACKs, the target must wait for the next PDU = from the initiator with an updated ExpStatSN. 06-341r0 discussed an alternative - add a Delivery Result output to = the Send Command Complete and Task Management Function Executed = confirmations (as previously proposed in 04-072r0 for a different = purpose). This would let the device server/task manager wait for all the = previous commands/TMF responses to complete (be ACKed) before proceeding = to make additional calls (e.g., Task Management Function Executed for a = LOGICAL UNIT RESET). However, iSCSI allows the target port to send a NOP-IN to force = delivery of a NOP-OUT with ExpStatSN, rather than passively wait for a = PDU to show up. The device server/task manager must instruct the target = port when to do this, and the Request Fence argument serves that = purpose. Target ports using protocols without such a force mechanism = are still OK - they will just wait for protocol-specific delivery = confirmations (e.g. ACKs). --=20 Rob Elliott, elliott@hp.com=20 Hewlett-Packard Industry Standard Server Storage Advanced Technology=20 https://ecardfile.com/id/RobElliott=20 =20 -------------------------------------------------------------------------= --- From: Robert Snively [mailto:rsnively@Brocade.COM]=20 Sent: Wednesday, January 03, 2007 4:46 PM To: Elliott, Robert (Server Storage); ips@ietf.org Subject: RE: [Ips] Response Fence Flag I need a little tutorial here. Note that this is an architectural = hack that is very "un-SCSI" and is not required if the response is qualified = with identification information associated with the original request. I know that such = qualification exists for commands, but does it exist for task management requests = in iSCSI? =20 I know that it does exist for parallel SCSI (which is strictly = interlocked) and for SAS and Fibre Channel SCSI, making such "fences" unrequired = by those technologies. Note that Rob's previous revision of 06-341 is available on = www.t10.org. I would hate to see such a hack creep into the SCSI architecture. Bob -------------------------------------------------------------------------= --- From: Elliott, Robert (Server Storage) [mailto:Elliott@hp.com]=20 Sent: Wednesday, January 03, 2007 1:56 PM To: ips@ietf.org Subject: RE: [Ips] Response Fence Flag If T10 agrees, T10 proposal 06-341 will add it to SAM-4. --=20 Rob Elliott, elliott@hp.com=20 Hewlett-Packard Industry Standard Server Storage Advanced Technology = https://ecardfile.com/id/RobElliott=20 -------------------------------------------------------------------------= - From: Eddy Quicksall [mailto:Quicksall_iSCSI@Bellsouth.net]=20 Sent: Wednesday, January 03, 2007 2:00 PM To: ips@ietf.org Subject: [Ips] Response Fence Flag Section 3.3.1 talks about a Response Fence Flag: SCSI protocol layer instructs the SCSI transport layer of a=20 "Response Fence" associated with the response in question when=20 the "Send Command Complete" protocol data service (SAM-2, clause=20 5.4.2) ... But I don't see any reference to that in SAM-2. Is this strictly an iSCSI flag? Where is the flag specified? Eddy -------------------------------------------------------------------------= ----- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips ------=_NextPart_000_003F_01C730C0.DB505EC0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
From an earlier email I = think that Response Fence is=20 only a proposal in T10 (http://www.t10.org:80/doc06.htm<= /A>). If=20 so shouldn't iSCSI wait a bit until this has been ratified?
 
Eddy
----- Original Message -----
From:=20 Robert=20 Snively
To: Elliott, Robert (Server Storage) ; = ips@ietf.org =
Sent: Thursday, January 04, = 2007 1:01=20 PM
Subject: RE: [Ips] Response = Fence=20 Flag

The problem is that the definition of = "previous" in this=20 context is most likely flawed.
 
The "Response Fence" is merely an = internal and=20 untestable state machine input that
attempts to order the transmission of = responses in=20 the target port's queue.
It  does=20 nothing to improve the overall ordering of the responses at the=20 application
client.
 
Drivers for generic SCSI transports must = always be aware=20 that requested operations
report completion with a more or less = arbitrary time=20 relationship to each other and must be
designed to tolerate that.  =
 
Using LOGICAL UNIT RESET as an example, the = operation=20 does not act only on
the device server.  As it passes down = through the=20 initiator stack, it may clean out
previously offered commands that have not yet = been=20 transported.  Then as it
passes up through the target stack, it may = clean out=20 previously offered commands
that have not yet been operated on.  As = it passes=20 through the device server
execution path, it may clean out previously = offered=20 commands that have begun
execution and some that have completed = execution=20 without yet responding.  As its
response passes back down the target stack, = it may clean=20 up commands
that have completed for which the response = has not yet=20 been transmitted, and as
it passes back up the initiator stack, it may = clean up=20 commands for which the
response has been transmitted, but not yet = been made=20 available to the driver or
application.  SAM-4 attempts to define = the passage=20 through the target port,
through the device server, and back to the = target=20 port.  However, beyond the
initiator port is = outside the=20 SAM-4 scope, and even where it is = defined,
the "shall ensure"s = are unlikely=20 to be testable and in some cases not implementable. 
 
Will I sometimes get command complete = indications for=20 commands after
a LOGICAL UNIT RESET = response is=20 received?  You=20 bet.  Response = Fence doesn't
change that.
 
Will I sometimes get command=20 aborted indications for commands after=20 a
LOGICAL UNIT RESET is response is = received? =20 You bet.  Response Fence
doesn't change that.
 
Is this a problem?  It never = has been in the=20 past, why is it now?
 
Can you test the corner conditions for a = fence=20 operation?  I doubt it.  The
existence of the "Response Fence" argument is = internal to=20 the target
implementation and invisible to=20 testing.
 
Bob
 

From: Elliott, Robert (Server = Storage)=20 [mailto:Elliott@hp.com]
Sent: Wednesday, January 03, 2007 = 3:35=20 PM
To: ips@ietf.org
Subject: RE: [Ips] Response = Fence=20 Flag

SAM-3 and SAM-4 require all transport = protocols to=20 tag the TMF responses with the = requests:

"Each SCSI transport = protocol=20 shall allow a Received Task Management Function Executed=20 confirming completion of = the=20 requested task to be associated with the corresponding Send Task = Management=20 Request."

Although iSCSI was=20 based on SAM-2, it complies with that rule. The Fence concept is = asking for=20 more than that - it wants the target to be able to ensure that all = previous=20 commands/TMFs are complete before delivering a particular TMF response = (e.g.,=20 for a LOGICAL UNIT RESET).  Since iSCSI doesn't have ACKs, the = target=20 must wait for the next PDU from the initiator with an updated=20 ExpStatSN.

06-341r0 discussed=20 an alternative - add a Delivery=20 Result output to the Send Command Complete and = Task=20 Management Function Executed confirmations (as previously proposed in = 04-072r0=20 for a different purpose). This would let the device server/task=20 manager wait for all the previous commands/TMF responses to = complete=20 (be ACKed) before proceeding to make additional calls (e.g., Task = Management=20 Function Executed for a LOGICAL UNIT=20 RESET).

However, iSCSI=20 allows the target port to send a NOP-IN to force delivery of a NOP-OUT = with ExpStatSN, rather than passively wait for a PDU to show = up. =20 The device server/task manager must instruct the target port when to = do this,=20 and the Request Fence argument serves that purpose.  Target = ports=20 using protocols without such a force mechanism are still OK - they = will just=20 wait for protocol-specific delivery confirmations (e.g.=20 ACKs).

-- =
Rob Elliott, = elliott@hp.com=20
Hewlett-Packard = Industry Standard=20 Server Storage Advanced Technology
https://ecardfile.com/id/Rob= Elliott=20


 

From: Robert Snively=20 [mailto:rsnively@Brocade.COM]
Sent: Wednesday, January = 03, 2007=20 4:46 PM
To: Elliott, Robert (Server Storage);=20 ips@ietf.org
Subject: RE: [Ips] Response Fence=20 Flag

I need a little tutorial here.  Note = that this is=20 an architectural hack that
is very "un-SCSI" and is not required if = the response=20 is qualified with identification
information associated with the original = request. =20 I know that such qualification
exists for commands, but does it exist for = task=20 management requests in
iSCSI? 
 
I know that it does exist for parallel SCSI = (which is=20 strictly interlocked)
and for SAS and Fibre Channel SCSI, making = such=20 "fences" unrequired by
those technologies.
 
Note that Rob's previous revision of 06-341 = is=20 available on www.t10.org.
 
I would hate to see such a hack creep into = the SCSI=20 architecture.
 
Bob
 

From: Elliott, Robert (Server = Storage)=20 [mailto:Elliott@hp.com]
Sent: Wednesday, January 03, 2007 = 1:56=20 PM
To: ips@ietf.org
Subject: RE: [Ips] Response = Fence=20 Flag

If T10 agrees, T10 proposal 06-341 will = add it to=20 SAM-4.
 

-- =
Rob Elliott, = elliott@hp.com=20
Hewlett-Packard = Industry=20 Standard Server Storage Advanced Technology
https://ecardfile.com/id/Rob= Elliott=20



From: Eddy Quicksall=20 [mailto:Quicksall_iSCSI@Bellsouth.net]
Sent: Wednesday, = January=20 03, 2007 2:00 PM
To: ips@ietf.org
Subject: = [Ips]=20 Response Fence Flag

Section 3.3.1 talks about a Response Fence=20 Flag:
 
SCSI protocol layer instructs the SCSI transport layer of a=20
"Response Fence" associated with the response in question when =
the=20 "Send Command Complete" protocol data service (SAM-2, clause =
5.4.2)=20 ...
 
But I don't see any reference to that in=20 SAM-2.
 
Is this strictly an iSCSI flag? Where is the = flag=20 specified?
 
Eddy

_______________________________________________
Ips mailing=20 = list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips
------=_NextPart_000_003F_01C730C0.DB505EC0-- --===============1824556791== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============1824556791==-- From ips-bounces@ietf.org Fri Jan 05 13:08:30 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2tUF-0003Mm-1E; Fri, 05 Jan 2007 13:08:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2tUE-0003Mb-2F for ips@ietf.org; Fri, 05 Jan 2007 13:08:14 -0500 Received: from web51902.mail.yahoo.com ([206.190.48.65]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H2tUA-0006JC-14 for ips@ietf.org; Fri, 05 Jan 2007 13:08:14 -0500 Received: (qmail 18467 invoked by uid 60001); 5 Jan 2007 18:08:09 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type; b=dmQSWDNOfDkJuQI4FwN2kRKDMHVj5JlErCZxz8/5offaPxn4y38m8Z4ros80N+mIqHEnZQw5y+AXbzgfB5RDdSNuNp/tWdI3vY5asinfyCumiYcfGW3WoiKZX4ZGeHTaN4Wsmua78/URmErqKsv/WVCVBV93cWWWzq/BiZxy33A= ; Message-ID: <20070105180809.18465.qmail@web51902.mail.yahoo.com> Received: from [15.227.217.75] by web51902.mail.yahoo.com via HTTP; Fri, 05 Jan 2007 10:08:09 PST Date: Fri, 5 Jan 2007 10:08:09 -0800 (PST) From: "Mallikarjun C." Subject: Re: [Ips] Response Fence Flag To: ips@ietf.org MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 4c463dcf97e2b913ab242796279c24d2 X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1717271347==" Errors-To: ips-bounces@ietf.org --===============1717271347== Content-Type: multipart/alternative; boundary="0-329000160-1168020489=:17178" --0-329000160-1168020489=:17178 Content-Type: text/plain; charset=ascii Content-Transfer-Encoding: quoted-printable Not really. Current draft text is intentionally written to not have any de= pendencies on T10 dynamics. The point is that iSCSI needs such a notion fo= r succinctly describing the proper iSCSI protocol actions in a few places -= ACA, TMF, Persistent reserve/Abort to name a few. We certainly hope it wi= ll be approved by T10 and be a part of SAM-4 soon, but that isn't required = per se for describing what iSCSI needs for its correct behavior.=0A=0AIPS W= G has adopted what it needs in the past - staying ahead of T10 review/appro= val cycle if necessary. I_T nexus loss notification, iSCSI target/port nam= ing, clearing effects are a few I recall.=0A=0AMallikarjun=0A=0A=0A=0A-----= Original Message ----=0AFrom: Eddy Quicksall =0ATo: Robert Snively ; "Elliott, Robert (Server St= orage)" ; ips@ietf.org=0ASent: Friday, January 5, 2007 8:58= :47 AM=0ASubject: Re: [Ips] Response Fence Flag=0A=0A=0AFrom an earlier ema= il I think that Response Fence is only a proposal in T10 (http://www.t10.or= g:80/doc06.htm). If so shouldn't iSCSI wait a bit until this has been ratif= ied?=0A =0AEddy=0A----- Original Message ----- =0AFrom: Robert Snively =0AT= o: Elliott, Robert (Server Storage) ; ips@ietf.org =0ASent: Thursday, Janua= ry 04, 2007 1:01 PM=0ASubject: RE: [Ips] Response Fence Flag=0A=0A=0AThe pr= oblem is that the definition of "previous" in this context is most likely f= lawed.=0A =0AThe "Response Fence" is merely an internal and untestable stat= e machine input that=0Aattempts to order the transmission of responses in t= he target port's queue.=0AIt does nothing to improve the overall ordering = of the responses at the application=0Aclient.=0A =0ADrivers for generic SCS= I transports must always be aware that requested operations=0Areport comple= tion with a more or less arbitrary time relationship to each other and must= be=0Adesigned to tolerate that. =0A =0AUsing LOGICAL UNIT RESET as an exa= mple, the operation does not act only on=0Athe device server. As it passes= down through the initiator stack, it may clean out=0Apreviously offered co= mmands that have not yet been transported. Then as it=0Apasses up through = the target stack, it may clean out previously offered commands=0Athat have = not yet been operated on. As it passes through the device server=0Aexecuti= on path, it may clean out previously offered commands that have begun=0Aexe= cution and some that have completed execution without yet responding. As i= ts =0Aresponse passes back down the target stack, it may clean up commands= =0Athat have completed for which the response has not yet been transmitted,= and as=0Ait passes back up the initiator stack, it may clean up commands f= or which the=0Aresponse has been transmitted, but not yet been made availab= le to the driver or=0Aapplication. SAM-4 attempts to define the passage th= rough the target port,=0Athrough the device server, and back to the target = port. However, beyond the=0Ainitiator port is outside the SAM-4 scope, and= even where it is defined,=0Athe "shall ensure"s are unlikely to be testabl= e and in some cases not implementable. =0A =0AWill I sometimes get command = complete indications for commands after=0Aa LOGICAL UNIT RESET response is = received? You bet. Response Fence doesn't=0Achange that.=0A =0AWill I som= etimes get command aborted indications for commands after a =0ALOGICAL UNIT= RESET is response is received? You bet. Response Fence=0Adoesn't change = that.=0A =0AIs this a problem? It never has been in the past, why is it no= w?=0A =0ACan you test the corner conditions for a fence operation? I doubt= it. The=0Aexistence of the "Response Fence" argument is internal to the t= arget=0Aimplementation and invisible to testing.=0A =0ABob=0A =0A=0A=0A=0A= =0AFrom: Elliott, Robert (Server Storage) [mailto:Elliott@hp.com] =0ASent: = Wednesday, January 03, 2007 3:35 PM=0ATo: ips@ietf.org=0ASubject: RE: [Ips]= Response Fence Flag=0A=0A=0ASAM-3 and SAM-4 require all transport protocol= s to tag the TMF responses with the requests:=0A"Each SCSI transport protoc= ol shall allow a Received Task Management Function Executed confirming comp= letion of the requested task to be associated with the corresponding Send T= ask Management Request."=0AAlthough iSCSI was based on SAM-2, it complies w= ith that rule. The Fence concept is asking for more than that - it wants th= e target to be able to ensure that all previous commands/TMFs are complete = before delivering a particular TMF response (e.g., for a LOGICAL UNIT RESET= ). Since iSCSI doesn't have ACKs, the target must wait for the next PDU fr= om the initiator with an updated ExpStatSN.=0A06-341r0 discussed an alterna= tive - add a Delivery Result output to the Send Command Complete and Task M= anagement Function Executed confirmations (as previously proposed in 04-072= r0 for a different purpose). This would let the device server/task manager = wait for all the previous commands/TMF responses to complete (be ACKed) bef= ore proceeding to make additional calls (e.g., Task Management Function Exe= cuted for a LOGICAL UNIT RESET).=0AHowever, iSCSI allows the target port to= send a NOP-IN to force delivery of a NOP-OUT with ExpStatSN, rather than p= assively wait for a PDU to show up. The device server/task manager must in= struct the target port when to do this, and the Request Fence argument serv= es that purpose. Target ports using protocols without such a force mechani= sm are still OK - they will just wait for protocol-specific delivery confir= mations (e.g. ACKs).=0A-- =0ARob Elliott, elliott@hp.com =0AHewlett-Packard= Industry Standard Server Storage Advanced Technology =0Ahttps://ecardfile.= com/id/RobElliott =0A=0A =0A=0A=0AFrom: Robert Snively [mailto:rsnively@Bro= cade.COM] =0ASent: Wednesday, January 03, 2007 4:46 PM=0ATo: Elliott, Rober= t (Server Storage); ips@ietf.org=0ASubject: RE: [Ips] Response Fence Flag= =0A=0A=0AI need a little tutorial here. Note that this is an architectural= hack that=0Ais very "un-SCSI" and is not required if the response is quali= fied with identification=0Ainformation associated with the original request= . I know that such qualification=0Aexists for commands, but does it exist = for task management requests in=0AiSCSI? =0A =0AI know that it does exist = for parallel SCSI (which is strictly interlocked)=0Aand for SAS and Fibre C= hannel SCSI, making such "fences" unrequired by=0Athose technologies.=0A = =0ANote that Rob's previous revision of 06-341 is available on www.t10.org.= =0A =0AI would hate to see such a hack creep into the SCSI architecture.=0A= =0ABob=0A =0A=0A=0A=0A=0AFrom: Elliott, Robert (Server Storage) [mailto:El= liott@hp.com] =0ASent: Wednesday, January 03, 2007 1:56 PM=0ATo: ips@ietf.o= rg=0ASubject: RE: [Ips] Response Fence Flag=0A=0A=0AIf T10 agrees, T10 prop= osal 06-341 will add it to SAM-4.=0A =0A-- =0ARob Elliott, elliott@hp.com = =0AHewlett-Packard Industry Standard Server Storage Advanced Technology =0A= https://ecardfile.com/id/RobElliott =0A=0A=0A=0A=0A=0A=0AFrom: Eddy Quicksa= ll [mailto:Quicksall_iSCSI@Bellsouth.net] =0ASent: Wednesday, January 03, 2= 007 2:00 PM=0ATo: ips@ietf.org=0ASubject: [Ips] Response Fence Flag=0A=0A= =0ASection 3.3.1 talks about a Response Fence Flag:=0A =0ASCSI protocol lay= er instructs the SCSI transport layer of a =0A"Response Fence" associated w= ith the response in question when =0Athe "Send Command Complete" protocol d= ata service (SAM-2, clause =0A5.4.2) ...=0A =0ABut I don't see any referenc= e to that in SAM-2.=0A =0AIs this strictly an iSCSI flag? Where is the flag= specified?=0A =0AEddy=0A=0A=0A=0A_________________________________________= ______=0AIps mailing list=0AIps@ietf.org=0Ahttps://www1.ietf.org/mailman/li= stinfo/ips=0A=0A_______________________________________________=0AIps maili= ng list=0AIps@ietf.org=0Ahttps://www1.ietf.org/mailman/listinfo/ips=0A=0A__= ________________________________________________=0ADo You Yahoo!?=0ATired o= f spam? Yahoo! Mail has the best spam protection around =0Ahttp://mail.yah= oo.com --0-329000160-1168020489=:17178 Content-Type: text/html; charset=ascii Content-Transfer-Encoding: quoted-printable
Not really.  Current draft text is intention= ally written to not have any dependencies on T10 dynamics.  The point = is that iSCSI needs such a notion for succinctly describing the proper=  iSCSI protocol actions in a few places - ACA, TMF, Persistent reserve= /Abort to name a few.  We certainly hope it will be approved by T10 an= d be a part of SAM-4 soon, but that isn't required per se for describi= ng what iSCSI needs for its correct behavior.
=0A
 =0A
IPS WG has adopted what it needs in the past - stay= ing ahead of T10 review/approval cycle if necessary.  I_T nexus loss n= otification, iSCSI target/port naming, clearing effects are a few I recall.=
=0A
 
=0A
Mallikarjun
=0A
=

 
=0A
----- Original Message ----
From: Eddy = Quicksall <Quicksall_iSCSI@Bellsouth.net>
To: Robert Snively <r= snively@Brocade.COM>; "Elliott, Robert (Server Storage)" <Elliott@hp.= com>; ips@ietf.org
Sent: Friday, January 5, 2007 8:58:47 AM
Subjec= t: Re: [Ips] Response Fence Flag

=0A=0A=0A
From an earlier email I think that Response Fence is onl= y a proposal in T10 (http://www.t10.org:80/doc06.htm). If so shouldn't iSC= SI wait a bit until this has been ratified?
=0A
 
=0A
Eddy
=0A=0A
----- Original Message -----
=0A=0A=0A
Sent: Thursday, January 04, 2007 1:01 PM=0A
Subject: RE: [Ips] Response Fe= nce Flag
=0A

=0A
The probl= em is that the definition of "previous" in this context is most likely flaw= ed.
=0A
 = ;
=0A
The "Response Fence" is merely= an internal and untestable state machine input that
=0A=
attempts to order the transmission of respons= es in the target port's queue.
=0A
It  <= FONT face=3DArial color=3D#0000ff size=3D2>does nothing to improve the over= all ordering of the responses at the application
=0Aclient.
=0A
 
=0A
Drive= rs for generic SCSI transports must always be aware that requested operatio= ns
=0A
report completion wi= th a more or less arbitrary time relationship to each other and must be
=0A
designed to tolerate that.=  
=0A
&= nbsp;
=0A
= Using LOGICAL UNIT RESET as an = example, the operation does not act only on
=0A
the device server.  As it passes down through th= e initiator stack, it may clean out
=0A
previously offered commands that have not yet been transported= .  Then as it
=0A
pass= es up through the target stack, it may clean out previously offered command= s
=0A
that have not yet bee= n operated on.  As it passes through the device server=0A
execution path, it may clean out previ= ously offered commands that have begun
=0A
execution and some that have completed execution witho= ut yet responding.  As its
=0A
response passes back down the target stack, it may clean up comma= nds
=0A
that have completed= for which the response has not yet been transmitted, and as<= /DIV>=0A
it passes back up the initiator stack= , it may clean up commands for which the
=0A
response has been transmitted, but not yet been made av= ailable to the driver or
=0A
= application.  SAM-4 attempts to define the passage through the targe= t port,
=0A
through the dev= ice server, and back to the target port.  However, beyond the
=0A
initiator port is o= utside the SAM-4 scope, and even where it is defined,<= /FONT>
=0A
the "shall ensure"= s are unlikely to be testable and in some cases not implementable. 
=0A<= DIV dir=3Dltr align=3Dleft> 
=0A
Will I sometimes get command complete indications for commands= after
=0A
a LO= GICAL UNIT RESET response is received?  You bet.  Response Fence doesn't
=0A
change that.=
=0A
 
=0A
Will I sometimes get command aborted= indications for commands after a =
=0A
LOGICAL UNIT RESET is re= sponse is received?  You bet.  Response Fence
= =0A
doesn't change that.
= =0A
 
=0A
Is this a problem?  It never has b= een in the past, why is it now?
=0A
 
=0A
Can yo= u test the corner conditions for a fence operation?  I doubt it. = The
=0A
existence of the "= Response Fence" argument is internal to the target
=0Aimplementation and invisible to testing.=
=0A
 
=0A=
Bob
=0A
 

=0A
=0A
=0AFrom: Elliott, Robert (Server Storage) [mailto:El= liott@hp.com]
Sent: Wednesday, January 03, 2007 3:35 PM
To= : ips@ietf.org
Subject: RE: [Ips] Response Fence Flag

=0A
=0A
=0A

SAM-3 and SAM-4 require all transport protocols to tag the = TMF responses with the requests:

=0A

"Each SCSI transport protocol shall allow a Re= ceived Task Management Function Executed confirming completion of the requested task to be associated with= the corresponding Send Task Management Request."

=0A

Although iSCSI was based = on SAM-2, it complies with that rule. The Fence concept is asking for more = than that - it wants the target to be able to ensure that all previous comm= ands/TMFs are complete before delivering a particular TMF response (e.g., f= or a LOGICAL UNIT RESET).  Since iSCSI doesn't have ACKs, the target m= ust wait for the next PDU from the initiator with an updated ExpStatSN.

=0A

<= SPAN class=3D381195622-03012007>06-341r0 discussed an alternative - add a D= elivery Result output to the Send Command Complete and Task Ma= nagement Function Executed confirmations (as previously proposed in 04-072r= 0 for a different purpose). This would let the device server/task manager&n= bsp;wait for all the previous commands/TMF responses to complete (be A= CKed) before proceeding to make additional calls (e.g., Task Management Fun= ction Executed for a LOGICAL UNIT RESET).

=0A

However, iSCSI allows the target port to send a NOP-IN to force deliver= y of a NOP-OUT with ExpStatSN, rather than passively wait for a PDU to= show up.  The device server/task manager must instruct the target por= t when to do this, and the Request Fence argument serves that purpose.=   Target ports using protocols without such a force mechanism are stil= l OK - they will just wait for protocol-specific delivery confirmations (e.= g. ACKs).

=0A

--
Ro= b Elliott, elliott@hp.com
Hewlett-Packard Industry Standard Server Storage Advanced= Technology
https://ecardfile.com/id/RobElliott

=0A


 

=0A=0A
=0A
=0AFrom: Robert Snively [mailto:rsnively@Brocade.COM= ]
Sent: Wednesday, January 03, 2007 4:46 PM
To: Elliot= t, Robert (Server Storage); ips@ietf.org
Subject: RE: [Ips] Respo= nse Fence Flag

=0A
=0A
I need a little tutorial here.  Note that this is an architectu= ral hack that
=0A
is very "= un-SCSI" and is not required if the response is qualified with identificati= on
=0A
information associat= ed with the original request.  I know that such qualification
=0A
= exists for commands, but does i= t exist for task management requests in
=0A
iSCSI? 
=0A
 
=0A
I know= that it does exist for parallel SCSI (which is strictly interlocked)
=0A
and for SAS and Fibre Channe= l SCSI, making such "fences" unrequired by
=0A
those technologies.
=0A
 
=0A
Note that Rob's previous revision of 06-341 is available on www.t10.org.
=0A
 
= =0A
I would hate to see such a hack creep int= o the SCSI architecture.
=0A
=  
=0A
Bob
=0A
 

=0A=
=0A=0AFrom: Elliott, Rober= t (Server Storage) [mailto:Elliott@hp.com]
Sent: Wednesday, Janu= ary 03, 2007 1:56 PM
To: ips@ietf.org
Subject: RE: [Ips= ] Response Fence Flag

=0A
=0A
If T10 agrees, T10 proposal 06-341 will add it to SAM-4.
=0A
 
= =0A
= =0A

--
Rob Elliott, elliott@hp.com
Hewlett-Packard Industry Standard Server Storage Adv= anced Technology
https://ecardfile.com/id/RobElliott


<= /SPAN>

=0A
=0A=0A
=0AFrom: Eddy Quicksall [= mailto:Quicksall_iSCSI@Bellsouth.net]
Sent: Wednesday, January 0= 3, 2007 2:00 PM
To: ips@ietf.org
Subject: [Ips] Respons= e Fence Flag

=0A
=0A
Secti= on 3.3.1 talks about a Response Fence Flag:
=0A
 
=0A
SCSI protocol layer instructs the SCSI tran= sport layer of a
"Response Fence" associated with the response in quest= ion when
the "Send Command Complete" protocol data service (SAM-2, clau= se
5.4.2) ...
=0A
 
=0A
But I don= 't see any reference to that in SAM-2.
=0A
<= /FONT> 
=0A
Is this strictly an iSCSI flag? Wh= ere is the flag specified?
=0A
 =
=0A
Eddy
=0A=

=0A=0A=0A

_________________________= ______________________
Ips mailing list
Ips@ietf.org
https://www1.= ietf.org/mailman/listinfo/ips
=0A
_____________________= __________________________
Ips mailing list
Ips@ietf.org
https://www= 1.ietf.org/mailman/listinfo/ips
=0A


__________________________________________________
Do You Yahoo!?Tired of spam? Yahoo! Mail has the best spam protection around
http:= //mail.yahoo.com --0-329000160-1168020489=:17178-- --===============1717271347== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============1717271347==-- From ips-bounces@ietf.org Fri Jan 05 15:28:06 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2vfP-0004Fg-O8; Fri, 05 Jan 2007 15:27:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2vfO-0004FZ-EN for ips@ietf.org; Fri, 05 Jan 2007 15:27:54 -0500 Received: from mtagate4.de.ibm.com ([195.212.29.153]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2vfL-0003EW-LE for ips@ietf.org; Fri, 05 Jan 2007 15:27:54 -0500 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate4.de.ibm.com (8.13.8/8.13.8) with ESMTP id l05KRoJI072894 for ; Fri, 5 Jan 2007 20:27:50 GMT Received: from d12av02.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1607.megacenter.de.ibm.com (8.13.6/8.13.6/NCO v8.1.1) with ESMTP id l05KRoxA2547836 for ; Fri, 5 Jan 2007 21:27:50 +0100 Received: from d12av02.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l05KRovI016206 for ; Fri, 5 Jan 2007 21:27:50 +0100 Received: from d12mc102.megacenter.de.ibm.com (d12mc102.megacenter.de.ibm.com [9.149.167.114]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l05KRoZi016203; Fri, 5 Jan 2007 21:27:50 +0100 In-Reply-To: <002801c730e6$11fd6920$01faa8c0@ivivity.com> To: "Eddy Quicksall" MIME-Version: 1.0 Subject: Re: [Ips] iSCSI Implementer's Guide - WG Last Call status X-Mailer: Lotus Notes Release 7.0.2 September 26, 2006 From: Julian Satran Message-ID: Date: Fri, 5 Jan 2007 15:27:47 -0500 X-MIMETrack: Serialize by Router on D12MC102/12/M/IBM(Release 7.0.2HF71 | November 3, 2006) at 05/01/2007 22:27:49, Serialize complete at 05/01/2007 22:27:49 X-Spam-Score: 0.1 (/) X-Scan-Signature: ce732c7d36989a1bd55104ba259c40a1 Cc: ips@ietf.org, Paul Koning X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0805791357==" Errors-To: ips-bounces@ietf.org This is a multipart message in MIME format. --===============0805791357== Content-Type: multipart/alternative; boundary="=_alternative 007067918525725A_=" This is a multipart message in MIME format. --=_alternative 007067918525725A_= Content-Type: text/plain; charset="US-ASCII" Eddy, It was stated here several times already that the general rule in RFCs is that sender has to be strict and the receiver lenient. It is however really difficult to say what exactly lenient means (as it is very much dependent on implementations). The rules are stated in terms of what a sender must do. It is also obvious that draft authors would be reluctant to make a blanket statement of the receiver not being manadated to check (as in some case that might be blatantly incorrect). Just to give you an example - would it be acceptable to say that a sender has to put a correct CRC in the frame but the receiver is free not to check it ? A blanket statement like the one you requested would cover such a behaviour too (that would be obviously incorect). Perhaps a statement along the lines of what Paul suggest ed with the caveat -"as long as it does not violate an explicit rule" should be enough. Regards, Julo "Eddy Quicksall" 05/01/07 11:25 To "Paul Koning" , cc ips@ietf.org Subject Re: [Ips] iSCSI Implementer's Guide - WG Last Call status I remember long ago talking about this when we were developing the RFC. I remember some people clearly saying that if the RFC said "must do X" then it meant that the peer "must check X". I didn't pursue the issue because it seemed to be of little importance. But as time went on and the draft got finalized, I ran into cases where that view was still taken to hart. Of course "the customer is always right" so I added checks. More recently I thought that since this guide was being written that maybe a simple statement could be made to clarify the issue. I'm not debating the issue of the importance of making a check or even the criteria for making the check. Eddy ----- Original Message ----- From: "Paul Koning" To: Cc: Sent: Thursday, January 04, 2007 6:00 PM Subject: Re: [Ips] iSCSI Implementer's Guide - WG Last Call status >>>>>> "Mallikarjun" == Mallikarjun C writes: > > Mallikarjun> Paul, Agree with everything you wrote. > > Mallikarjun> RFC 3720 does not require sane reactions to non-sane > Mallikarjun> inputs. This draft should not say anything that > Mallikarjun> suggests target/initiator may draw sane interpretations > Mallikarjun> to non-sane inputs either. > > Great summary. > > Mallikarjun> Sounds like an agreement to not add any new text to me. > > Well, Eddy raised the issue a while back that some people writing > conformance tests were interpreting "initiator must do X" as "target > must check that initiator does X". That's clearly an incorrect > conclusion. But given that people make this mistake, I wonder if a > note in the guide saying "unless RFC 3720 specifically requires it, an > implementation is not required to do protocol conformance checking on > incoming message", or something like that, would be helpful. > > paul > > > _______________________________________________ > Ips mailing list > Ips@ietf.org > https://www1.ietf.org/mailman/listinfo/ips > _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --=_alternative 007067918525725A_= Content-Type: text/html; charset="US-ASCII"
Eddy,

It was stated here several times already that the general rule in RFCs is that sender has to be strict and the receiver lenient.
It is however really difficult to say what exactly lenient means (as it is very much dependent on implementations). The rules are stated in terms of what a sender must do.
It is also obvious that draft authors would be reluctant to make a blanket statement of the receiver not being manadated to check (as in some case that might be blatantly incorrect). Just to give you an example - would it be acceptable to say that a sender has to put a correct CRC in the frame but the receiver is free not to check it ?
A blanket statement like the one you requested would cover such a behaviour too (that would be obviously incorect). Perhaps a statement along the lines of what Paul suggest ed with  the caveat -"as long as it does not violate an explicit rule" should be enough.

Regards,
Julo


"Eddy Quicksall" <Quicksall_iSCSI@Bellsouth.net>

05/01/07 11:25

To
"Paul Koning" <pkoning@equallogic.com>, <cb_mallikarjun@yahoo.com>
cc
ips@ietf.org
Subject
Re: [Ips] iSCSI Implementer's Guide - WG Last Call status





I remember long ago talking about this when we were developing the RFC. I
remember some people clearly saying that if the RFC said "must do X" then it
meant that the peer "must check X". I didn't pursue the issue because it
seemed to be of little importance.

But as time went on and the draft got finalized, I ran into cases where that
view was still taken to hart. Of course "the customer is always right" so I
added checks.

More recently I thought that since this guide was being written that maybe a
simple statement could be made to clarify the issue.

I'm not debating the issue of the importance of making a check or even the
criteria for making the check.

Eddy

----- Original Message -----
From: "Paul Koning" <pkoning@equallogic.com>
To: <cb_mallikarjun@yahoo.com>
Cc: <ips@ietf.org>
Sent: Thursday, January 04, 2007 6:00 PM
Subject: Re: [Ips] iSCSI Implementer's Guide - WG Last Call status


>>>>>> "Mallikarjun" == Mallikarjun C <cb_mallikarjun@yahoo.com> writes:
>
> Mallikarjun> Paul, Agree with everything you wrote.
>
> Mallikarjun> RFC 3720 does not require sane reactions to non-sane
> Mallikarjun> inputs.  This draft should not say anything that
> Mallikarjun> suggests target/initiator may draw sane interpretations
> Mallikarjun> to non-sane inputs either.
>
> Great summary.
>
> Mallikarjun> Sounds like an agreement to not add any new text to me.
>
> Well, Eddy raised the issue a while back that some people writing
> conformance tests were interpreting "initiator must do X" as "target
> must check that initiator does X".  That's clearly an incorrect
> conclusion.  But given that people make this mistake, I wonder if a
> note in the guide saying "unless RFC 3720 specifically requires it, an
> implementation is not required to do protocol conformance checking on
> incoming message", or something like that, would be helpful.
>
>      paul
>
>
> _______________________________________________
> Ips mailing list
> Ips@ietf.org
> https://www1.ietf.org/mailman/listinfo/ips
>


_______________________________________________
Ips mailing list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips
--=_alternative 007067918525725A_=-- --===============0805791357== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============0805791357==-- From ips-bounces@ietf.org Fri Jan 05 16:01:22 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2wBk-0000ZL-5b; Fri, 05 Jan 2007 16:01:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2wBi-0000ZF-D2 for ips@ietf.org; Fri, 05 Jan 2007 16:01:18 -0500 Received: from [66.243.153.19] (helo=mx20.brocade.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2wBd-0003V6-PI for ips@ietf.org; Fri, 05 Jan 2007 16:01:18 -0500 Received: from mailhost.brocade.com (HELO discus.brocade.com) ([192.168.126.240]) by mx20.brocade.com with ESMTP; 05 Jan 2007 13:01:08 -0800 X-IronPort-AV: i="4.13,154,1167638400"; d="scan'208,217"; a="4781773:sNHT48440329" Received: from hq-exch-1.corp.brocade.com (brono-list.brocade.com [10.3.8.21]) by discus.brocade.com (Postfix) with ESMTP id 70AEF238370; Fri, 5 Jan 2007 12:59:48 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ips] Response Fence Flag Date: Fri, 5 Jan 2007 13:01:06 -0800 Message-ID: <39BA3BC178B4394DB184389E88A97F8C0155978F@hq-exch-1.corp.brocade.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ips] Response Fence Flag thread-index: Accw9PYaidr8ZaNITTmf6OuqhvBoBAAFFwew From: "John Hufferd" To: "Mallikarjun C." , X-Spam-Score: 0.1 (/) X-Scan-Signature: 6c03b24ff9075158b14f74498a5ea0c7 Cc: X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0140366480==" Errors-To: ips-bounces@ietf.org This is a multi-part message in MIME format. --===============0140366480== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7310C.B314607A" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7310C.B314607A Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Mallikarjun, I must admit, that I have been a bit confused with the direction of the conversation here. =20 Therefore, I went back and reviewed the charts from Dallas. And as I remembered, the initial focus was to address the issue of Multiple Connections per Session (MC/S) (as stated on chart 4 - "Non-issue for single-connection iSCSI sessions"). So I think I have missed the step where we have morphed the discussion into one dealing with multiple sessions. (I am not sure how that happened, or if I miss-read the charts from Dallas, or have not followed the discussion adequately.) =20 If we are attempting to define two different issues, one with MC/S and one with Multiple Session from different Initiators, I think it would be useful to break down the conversation into Topic A - MC/S and Topic B Multiple Sessions. It is possible that one solution will addresses both, but I for one think I am hearing arguments that might be appropriate for Topic B, while I am thinking about its applicability to Topic A. =20 Perhaps, you could address the issue as either being all about MC/S or explicitly state that it is intended to affect Multiple Sessions also, and then address the issues and solution for each separately. For example, I believe Robert was addressing the issue from a view of Multiple Sessions and if we only intended to address MC/S then I expect the response might be somewhat different. =20 Anyway, if you could clear-up some of this, I think it would be useful (at least to me). =20 . . . John L Hufferd Sr. Executive Director of Technology Brocade Communications Systems, Inc jhufferd@brocade.com Office Phone: (408) 333-5244; eFAX: (408) 904-4688 Alt Office Phone: (408) 997-6136; Cell: (408) 627-9606 =20 ________________________________ From: Mallikarjun C. [mailto:cb_mallikarjun@yahoo.com]=20 Sent: Friday, January 05, 2007 10:08 AM To: ips@ietf.org Subject: Re: [Ips] Response Fence Flag =20 Not really. Current draft text is intentionally written to not have any dependencies on T10 dynamics. The point is that iSCSI needs such a notion for succinctly describing the proper iSCSI protocol actions in a few places - ACA, TMF, Persistent reserve/Abort to name a few. We certainly hope it will be approved by T10 and be a part of SAM-4 soon, but that isn't required per se for describing what iSCSI needs for its correct behavior. =20 IPS WG has adopted what it needs in the past - staying ahead of T10 review/approval cycle if necessary. I_T nexus loss notification, iSCSI target/port naming, clearing effects are a few I recall. =20 Mallikarjun =20 ----- Original Message ---- From: Eddy Quicksall To: Robert Snively ; "Elliott, Robert (Server Storage)" ; ips@ietf.org Sent: Friday, January 5, 2007 8:58:47 AM Subject: Re: [Ips] Response Fence Flag >From an earlier email I think that Response Fence is only a proposal in T10 (http://www.t10.org:80/doc06.htm ). If so shouldn't iSCSI wait a bit until this has been ratified? =20 Eddy ----- Original Message -----=20 From: Robert Snively =20 To: Elliott, Robert (Server Storage) ; ips@ietf.org=20 Sent: Thursday, January 04, 2007 1:01 PM Subject: RE: [Ips] Response Fence Flag =20 The problem is that the definition of "previous" in this context is most likely flawed. =20 The "Response Fence" is merely an internal and untestable state machine input that attempts to order the transmission of responses in the target port's queue. It does nothing to improve the overall ordering of the responses at the application client. =20 Drivers for generic SCSI transports must always be aware that requested operations report completion with a more or less arbitrary time relationship to each other and must be designed to tolerate that. =20 =20 Using LOGICAL UNIT RESET as an example, the operation does not act only on the device server. As it passes down through the initiator stack, it may clean out previously offered commands that have not yet been transported. Then as it passes up through the target stack, it may clean out previously offered commands that have not yet been operated on. As it passes through the device server execution path, it may clean out previously offered commands that have begun execution and some that have completed execution without yet responding. As its=20 response passes back down the target stack, it may clean up commands that have completed for which the response has not yet been transmitted, and as it passes back up the initiator stack, it may clean up commands for which the response has been transmitted, but not yet been made available to the driver or application. SAM-4 attempts to define the passage through the target port, through the device server, and back to the target port. However, beyond the initiator port is outside the SAM-4 scope, and even where it is defined, the "shall ensure"s are unlikely to be testable and in some cases not implementable.=20 =20 Will I sometimes get command complete indications for commands after a LOGICAL UNIT RESET response is received? You bet. Response Fence doesn't change that. =20 Will I sometimes get command aborted indications for commands after a=20 LOGICAL UNIT RESET is response is received? You bet. Response Fence doesn't change that. =20 Is this a problem? It never has been in the past, why is it now? =20 Can you test the corner conditions for a fence operation? I doubt it. The existence of the "Response Fence" argument is internal to the target implementation and invisible to testing. =20 Bob =20 =20 =09 ________________________________ From: Elliott, Robert (Server Storage) [mailto:Elliott@hp.com]=20 Sent: Wednesday, January 03, 2007 3:35 PM To: ips@ietf.org Subject: RE: [Ips] Response Fence Flag SAM-3 and SAM-4 require all transport protocols to tag the TMF responses with the requests: "Each SCSI transport protocol shall allow a Received Task Management Function Executed confirming completion of the requested task to be associated with the corresponding Send Task Management Request." Although iSCSI was based on SAM-2, it complies with that rule. The Fence concept is asking for more than that - it wants the target to be able to ensure that all previous commands/TMFs are complete before delivering a particular TMF response (e.g., for a LOGICAL UNIT RESET). Since iSCSI doesn't have ACKs, the target must wait for the next PDU from the initiator with an updated ExpStatSN. 06-341r0 discussed an alternative - add a Delivery Result output to the Send Command Complete and Task Management Function Executed confirmations (as previously proposed in 04-072r0 for a different purpose). This would let the device server/task manager wait for all the previous commands/TMF responses to complete (be ACKed) before proceeding to make additional calls (e.g., Task Management Function Executed for a LOGICAL UNIT RESET). However, iSCSI allows the target port to send a NOP-IN to force delivery of a NOP-OUT with ExpStatSN, rather than passively wait for a PDU to show up. The device server/task manager must instruct the target port when to do this, and the Request Fence argument serves that purpose. Target ports using protocols without such a force mechanism are still OK - they will just wait for protocol-specific delivery confirmations (e.g. ACKs). --=20 Rob Elliott, elliott@hp.com=20 Hewlett-Packard Industry Standard Server Storage Advanced Technology=20 https://ecardfile.com/id/RobElliott=20 =09 =20 =09 ________________________________ From: Robert Snively [mailto:rsnively@Brocade.COM]=20 Sent: Wednesday, January 03, 2007 4:46 PM To: Elliott, Robert (Server Storage); ips@ietf.org Subject: RE: [Ips] Response Fence Flag I need a little tutorial here. Note that this is an architectural hack that is very "un-SCSI" and is not required if the response is qualified with identification information associated with the original request. I know that such qualification exists for commands, but does it exist for task management requests in iSCSI? =20 =20 I know that it does exist for parallel SCSI (which is strictly interlocked) and for SAS and Fibre Channel SCSI, making such "fences" unrequired by those technologies. =20 Note that Rob's previous revision of 06-341 is available on www.t10.org . =20 I would hate to see such a hack creep into the SCSI architecture. =20 Bob =20 =20 =09 ________________________________ From: Elliott, Robert (Server Storage) [mailto:Elliott@hp.com]=20 Sent: Wednesday, January 03, 2007 1:56 PM To: ips@ietf.org Subject: RE: [Ips] Response Fence Flag If T10 agrees, T10 proposal 06-341 will add it to SAM-4. =20 --=20 Rob Elliott, elliott@hp.com=20 Hewlett-Packard Industry Standard Server Storage Advanced Technology=20 https://ecardfile.com/id/RobElliott=20 =20 =20 =09 ________________________________ From: Eddy Quicksall [mailto:Quicksall_iSCSI@Bellsouth.net]=20 Sent: Wednesday, January 03, 2007 2:00 PM To: ips@ietf.org Subject: [Ips] Response Fence Flag Section 3.3.1 talks about a Response Fence Flag: =20 SCSI protocol layer instructs the SCSI transport layer of a=20 "Response Fence" associated with the response in question when=20 the "Send Command Complete" protocol data service (SAM-2, clause=20 5.4.2) ... =20 But I don't see any reference to that in SAM-2. =20 Is this strictly an iSCSI flag? Where is the flag specified? =20 Eddy _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips =20 __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around=20 http://mail.yahoo.com=20 ------_=_NextPart_001_01C7310C.B314607A Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Mallikarjun,

I must admit, that I have been a = bit confused with the direction of the conversation = here.

 

Therefore, I went back and reviewed = the charts from Dallas.  And as I remembered, the initial focus was to address the issue of Multiple Connections per Session (MC/S) (as stated on chart 4 – = “Non-issue for single-connection iSCSI sessions”).  So I think I have = missed the step where we have morphed the discussion into one dealing with = multiple sessions.  (I am not sure how that happened, or if I miss-read the = charts from Dallas, or have not followed the discussion = adequately.)

 

If we are attempting to define two different issues, one with MC/S and one with Multiple Session from = different Initiators, I think it would be useful to break down the conversation into Topic A = – MC/S and Topic B Multiple Sessions.  It is possible that one = solution will addresses both, but I for one think I am hearing arguments that might be = appropriate for Topic B, while I am thinking about its applicability to Topic = A.

 

Perhaps, you could address the = issue as either being all about MC/S or explicitly state that it is intended to = affect Multiple Sessions also, and then address the issues and solution for = each separately.  For example, I believe Robert was addressing the issue from a view of = Multiple Sessions and if we only intended to address MC/S then I expect the = response might be somewhat different.

 

Anyway, if you could clear-up some = of this, I think it would be useful (at least to = me).

 

.

.

.

John L Hufferd

Sr. Executive Director of = Technology

Brocade Communications Systems, = Inc

jhufferd@brocade.com

Office Phone: (408) 333-5244; = eFAX: (408) 904-4688

Alt Office Phone: (408) 997-6136; = Cell: (408) 627-9606

 

From: = Mallikarjun C. [mailto:cb_mallikarjun@yahoo.com]
Sent: Friday, January 05, = 2007 10:08 AM
To: ips@ietf.org
Subject: Re: [Ips] = Response Fence Flag

 

Not really.  Current draft text is intentionally written to = not have any dependencies on T10 dynamics.  The point is that iSCSI = needs such a notion for succinctly describing the proper iSCSI protocol = actions in a few places - ACA, TMF, Persistent reserve/Abort to name a = few.  We certainly hope it will be approved by T10 and be a part of SAM-4 soon, but that isn't required per se for describing what iSCSI needs for = its correct behavior.

 

IPS WG has adopted what it needs in the past - staying = ahead of T10 review/approval cycle if necessary.  I_T nexus loss = notification, iSCSI target/port naming, clearing effects are a few I = recall.

 

Mallikarjun



 

----- Original = Message ----
From: Eddy Quicksall <Quicksall_iSCSI@Bellsouth.net>
To: Robert Snively <rsnively@Brocade.COM>; "Elliott, Robert (Server = Storage)" <Elliott@hp.com>; ips@ietf.org
Sent: Friday, January 5, 2007 8:58:47 AM
Subject: Re: [Ips] Response Fence Flag

From an earlier email I think that Response Fence is = only a proposal in T10 (http://www.t10.org:80/doc06.htm). If so shouldn't iSCSI wait a bit until this has been = ratified?

 

Eddy

----- Original Message ----- =

Sent: = Thursday, January 04, 2007 1:01 PM

Subject: RE: = [Ips] Response Fence Flag

 

The problem is that the definition = of "previous" in this context is most likely = flawed.

 

The "Response Fence" = is merely an internal and untestable state machine input = that

attempts to order the transmission = of responses in the target port's queue.

It  does nothing to improve the overall ordering of the = responses at the application

client.

=

 

Drivers for generic SCSI transports = must always be aware that requested operations

report completion with a more or = less arbitrary time relationship to each other and must = be

designed to tolerate that.  =

 

Using LOGICAL UNIT RESET as an = example, the operation does not act only on

the device server.  As it = passes down through the initiator stack, it may clean = out

previously offered commands that = have not yet been transported.  Then as it

passes up through the target stack, = it may clean out previously offered commands

that have not yet been operated = on.  As it passes through the device server

execution path, it may clean out previously offered commands that have begun

execution and some that have completed execution without yet responding.  As its =

response passes back down the = target stack, it may clean up commands

that have completed for which the = response has not yet been transmitted, and as

it passes back up the initiator = stack, it may clean up commands for which the

response has been transmitted, but = not yet been made available to the driver or

application.  SAM-4 attempts = to define the passage through the target port,

through the device server, and back = to the target port.  However, beyond the

initiator port is outside the SAM-4 = scope, and even where it is defined,

the "shall ensure"s are = unlikely to be testable and in some cases not = implementable. 

 

Will I sometimes get command = complete indications for commands after

a LOGICAL UNIT RESET response is received?  You bet.  Response = Fence doesn't

change = that.

 

Will I sometimes get command = aborted indications for commands after a

LOGICAL UNIT RESET is response = is received?  You bet.  Response Fence

doesn't change = that.

 

Is this a problem?  It never = has been in the past, why is it now?

 

Can you test the corner conditions = for a fence operation?  I doubt it.  = The

existence of the "Response Fence" argument is internal to the = target

implementation and invisible to = testing.

 

Bob

 

 

From: Elliott, Robert (Server Storage) [mailto:Elliott@hp.com]
Sent: Wednesday, January = 03, 2007 3:35 PM
To: ips@ietf.org
Subject: RE: [Ips] = Response Fence Flag

SAM-3 and SAM-4 require all transport protocols to tag = the TMF responses with the requests:

"Each SCSI transport protocol shall allow a = Received Task Management Function Executed = confirming completion of the requested task to be associated with the corresponding = Send Task Management = Request."

Although iSCSI was based on SAM-2, it complies with = that rule. The Fence concept is asking for more than that - it wants the = target to be able to ensure that all previous commands/TMFs are complete before delivering a particular TMF response (e.g., for a LOGICAL UNIT = RESET).  Since iSCSI doesn't have ACKs, the target must wait for the next PDU = from the initiator with an updated ExpStatSN.

06-341r0 discussed an alternative - add a Delivery = Result output to the Send Command Complete and Task Management Function = Executed confirmations (as previously proposed in 04-072r0 for a different = purpose). This would let the device server/task manager wait for all the previous commands/TMF responses to complete (be ACKed) before proceeding = to make additional calls (e.g., Task Management Function Executed for a = LOGICAL UNIT RESET).

However, iSCSI allows the target port to send a NOP-IN = to force delivery of a NOP-OUT with ExpStatSN, rather than passively = wait for a PDU to show up.  The device server/task manager must instruct the = target port when to do this, and the Request Fence argument serves that purpose.  Target ports using protocols without such a force = mechanism are still OK - they will just wait for protocol-specific delivery = confirmations (e.g. ACKs).

--
Rob Elliott, elliott@hp.com
Hewlett-Packard Industry Standard Server Storage Advanced Technology =
https://ecardfile.com/id/RobElliott


 

From: Robert Snively = [mailto:rsnively@Brocade.COM]
Sent: Wednesday, January = 03, 2007 4:46 PM
To: Elliott, Robert = (Server Storage); ips@ietf.org
Subject: RE: [Ips] = Response Fence Flag

I need a little tutorial = here.  Note that this is an architectural hack that

is very "un-SCSI" and is = not required if the response is qualified with = identification

information associated with the = original request.  I know that such = qualification

exists for commands, but does it = exist for task management requests in

iSCSI?  =

 

I know that it does exist for = parallel SCSI (which is strictly interlocked)

and for SAS and Fibre Channel SCSI, = making such "fences" unrequired by

those = technologies.

 

Note that Rob's previous revision = of 06-341 is available on www.t10.org.

 

I would hate to see such a hack = creep into the SCSI architecture.

 

Bob

 

 

From: Elliott, Robert (Server Storage) [mailto:Elliott@hp.com]
Sent: Wednesday, January = 03, 2007 1:56 PM
To: ips@ietf.org
Subject: RE: [Ips] = Response Fence Flag

If T10 agrees, T10 proposal 06-341 = will add it to SAM-4.

 

--
Rob Elliott, elliott@hp.com
Hewlett-Packard Industry Standard Server Storage Advanced Technology =
https://ecardfile.com/id/RobElliott

 

 

From: Eddy Quicksall [mailto:Quicksall_iSCSI@Bellsouth.net]
Sent: Wednesday, January = 03, 2007 2:00 PM
To: ips@ietf.org
Subject: [Ips] Response = Fence Flag

Section 3.3.1 talks about a Response Fence = Flag:

 

SCSI protocol layer instructs the SCSI transport layer of a
"Response Fence" associated with the response in question when =
the "Send Command Complete" protocol data service (SAM-2, = clause
5.4.2) ...

 

But I don't see any reference to that in = SAM-2.

 

Is this strictly an iSCSI flag? Where is the flag = specified?

 

Eddy

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

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

 


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

------_=_NextPart_001_01C7310C.B314607A-- --===============0140366480== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============0140366480==-- From ips-bounces@ietf.org Fri Jan 05 17:45:35 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2xoM-00049a-Ah; Fri, 05 Jan 2007 17:45:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2xoK-00049J-HW for ips@ietf.org; Fri, 05 Jan 2007 17:45:16 -0500 Received: from web51906.mail.yahoo.com ([206.190.48.69]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H2xoH-0006Kj-RC for ips@ietf.org; Fri, 05 Jan 2007 17:45:16 -0500 Received: (qmail 76686 invoked by uid 60001); 5 Jan 2007 22:45:12 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type; b=O+BLE4IldbhrLxrsULvHS0HnGaBWgwRBYrrVz0653YHHO00P3U1dQ0tXKKDn9C6ioEos/YNk+txdzAc4Yg8Afnqto1z9p3P0ldU+qBd8ULA0jbmNNmRuSnec2CCsjL1TnqPoik6ANSjxcWH8KInr9aOA/eO9B3vqoIya+nAOaaQ= ; Message-ID: <20070105224512.76684.qmail@web51906.mail.yahoo.com> Received: from [15.227.217.75] by web51906.mail.yahoo.com via HTTP; Fri, 05 Jan 2007 14:45:12 PST Date: Fri, 5 Jan 2007 14:45:12 -0800 (PST) From: "Mallikarjun C." Subject: Fw: [Ips] Response Fence Flag To: IPS MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 453b1bfcf0292bffe4cab90ba115f503 X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1853556680==" Errors-To: ips-bounces@ietf.org --===============1853556680== Content-Type: multipart/alternative; boundary="0-867321842-1168037112=:74014" --0-867321842-1168037112=:74014 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Trying again after bouncing (>50KB), tail is now clipped....=0A=0A=0A----- = Forwarded Message ----=0AFrom: Mallikarjun C. =0A= To: ips@ietf.org=0ASent: Friday, January 5, 2007 2:40:56 PM=0ASubject: Re: = [Ips] Response Fence Flag=0A=0A=0AHi John,=0A =0AAs you correctly point out= , there are two distinct but related topics here.=0A =0A(1) proper response= ordering across participating connections in a multi-connection session, f= or a handful of task/TMF responses=0A(2) proper way to terminate and signal= tasks when actions on one session can impact multiple initiators=0A =0A(1)= is all about response fence, it is covered separately in section 3.3 of IG= draft. That's what this email thread started off with.=0A =0A(2) covers c= ases that IG had called as as "multi-task abort" cases that typically have = a shared task set across sessions, or are the result of a Logical Unit Rese= t TMF. Section 4.1 of IG adresses (2).=0A =0ASo how are (1) and (2) relate= d?=0A =0A- Some cases covered under (2) overlap with (1), but some cases in= (2) are for single connection sessions. E.g. LU Reset on a single connect= ion session impacting several 3rd party sessions=0A =0A- Some cases under (= 1) overlap with (2), but some cases in (1) have nothing to do with other se= ssions. E.g. establishment of ACA on a non-shared task set=0A =0A- Section= 4.1 (i.e. text for (2)) uses response fence (i.e. text for (1)) whenever m= ulti-connection sessions are involved in multi-task abort situations.=0A = =0AI hope that clarifies it. Feel free to ask if that is not clear. The n= et is that the response fence is the underpinning notion to describe the co= rrect iSCSI behavior in a few cases and some of those cases are about task = terminations across third-party sessions.=0A =0AMallikarjun=0A =0A=0A=0A = =0A----- Original Message ----=0AFrom: John Hufferd = =0ATo: Mallikarjun C. ; ips@ietf.org=0ASent: Frid= ay, January 5, 2007 1:01:06 PM=0ASubject: RE: [Ips] Response Fence Flag=0A= =0A=0AMallikarjun,=0AI must admit, that I have been a bit confused with the= direction of the conversation here.=0A =0ATherefore, I went back and revie= wed the charts from Dallas . And as I remembered, the initial focus was to= address the issue of Multiple Connections per Session (MC/S) (as stated on= chart 4 =96 =93Non-issue for single-connection iSCSI sessions=94). So I t= hink I have missed the step where we have morphed the discussion into one d= ealing with multiple sessions. (I am not sure how that happened, or if I m= iss-read the charts from Dallas , or have not followed the discussion adequ= ately.)=0A =0AIf we are attempting to define two different issues, one with= MC/S and one with Multiple Session from different Initiators, I think it w= ould be useful to break down the conversation into Topic A =96 MC/S and Top= ic B Multiple Sessions. It is possible that one solution will addresses bo= th, but I for one think I am hearing arguments that might be appropriate fo= r Topic B, while I am thinking about its applicability to Topic A.=0A =0APe= rhaps, you could address the issue as either being all about MC/S or explic= itly state that it is intended to affect Multiple Sessions also, and then a= ddress the issues and solution for each separately. For example, I believe= Robert was addressing the issue from a view of Multiple Sessions and if we= only intended to address MC/S then I expect the response might be somewhat= different.=0A =0AAnyway, if you could clear-up some of this, I think it wo= uld be useful (at least to me).=0A =0A.=0A.=0A.=0AJohn L Hufferd=0ASr. Exec= utive Director of Technology=0ABrocade Communications Systems, Inc=0Ajhuffe= rd@brocade.com=0AOffice Phone: (408) 333-5244; eFAX: (408) 904-4688=0AAlt O= ffice Phone: (408) 997-6136; Cell: (408) 627-9606=0A =0A=0A=0A=0AFrom: Mall= ikarjun C. [mailto:cb_mallikarjun@yahoo.com] =0ASent: Friday, January 05, 2= 007 10:08 AM=0ATo: ips@ietf.org=0ASubject: Re: [Ips] Response Fence Flag=0A= =0ANot really. Current draft text is intentionally written to not have an= y dependencies on T10 dynamics. The point is that iSCSI needs such a notio= n for succinctly describing the proper iSCSI protocol actions in a few plac= es - ACA, TMF, Persistent reserve/Abort to name a few. We certainly hope i= t will be approved by T10 and be a part of SAM-4 soon, but that isn't requi= red per se for describing what iSCSI needs for its correct behavior.=0A =0A= IPS WG has adopted what it needs in the past - staying ahead of T10 review/= approval cycle if necessary. I_T nexus loss notification, iSCSI target/por= t naming, clearing effects are a few I recall.=0A =0AMallikarjun=0A=0A=0A = =0A----- Original Message ----=0AFrom: Eddy Quicksall =0ATo: Robert Snively ; "Elliott, Robert (S= erver Storage)" ; ips@ietf.org=0ASent: Friday, January 5, 2= 007 8:58:47 AM=0ASubject: Re: [Ips] Response Fence Flag=0AFrom an earlier e= mail I think that Response Fence is only a proposal in T10 (http://www.t10.= org:80/doc06.htm). If so shouldn't iSCSI wait a bit until this has been rat= ified?=0A =0AEddy=0A=0A__________________________________________________= =0ADo You Yahoo!?=0ATired of spam? Yahoo! Mail has the best spam protectio= n around =0Ahttp://mail.yahoo.com --0-867321842-1168037112=:74014 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Trying again after bouncing (>50KB), tail is n= ow clipped....

=0A
----- Forwarded Message ----
From: Ma= llikarjun C. <cb_mallikarjun@yahoo.com>
To: ips@ietf.org
Sent: = Friday, January 5, 2007 2:40:56 PM
Subject: Re: [Ips] Response Fence Fla= g

=0A
=0A
Hi John,
=0A
 
= =0A
As you correctly point out, there are two distinct but related= topics here.
=0A
 
=0A
(1) proper re= sponse ordering across participating connections in a multi-connection sess= ion, for a handful of task/TMF responses
=0A
(2) proper way t= o terminate and signal tasks when actions on one session can impact mu= ltiple initiators
=0A
 
=0A
(1) is all abo= ut response fence, it is covered separately in section 3.3 of IG draft.&nbs= p; That's what this email thread started off with.
=0A
 =
=0A
(2) covers cases that IG had called as as "mul= ti-task abort" cases that typically have a shared task set across sessions,= or are the result of a Logical Unit Reset TMF.  Section 4.1 of IG adr= esses (2).
=0A
 
=0A
So how are (1) and (2= ) related?
=0A
 
=0A
- Some cases covered = under (2) overlap with (1), but some cases in (2) are for single conne= ction sessions.  E.g. LU Reset on a single connection session impactin= g several 3rd party sessions
=0A
 
=0A
- S= ome cases under (1) overlap with (2), but some cases in (1) have nothing to= do with other sessions.  E.g. establishment of ACA on a non-shared ta= sk set
=0A
 
=0A
- Section 4.1 (i.e. = text for (2)) uses response fence (i.e. text for (1)) whenever multi-c= onnection sessions are involved in multi-task abort situations.
=0A 
=0A
I hope that clarifies it.  Feel free t= o ask if that is not clear.  The net is that the response fence i= s the underpinning notion to describe the correct iSCSI behavior in a few c= ases and some of those cases are about task terminations across third-= party sessions.
=0A
 
=0A
Mallikarjun=0A
 
=0A


 
=0A
---= -- Original Message ----
From: John Hufferd <jhufferd@Brocade.COM>=
To: Mallikarjun C. <cb_mallikarjun@yahoo.com>; ips@ietf.org
Se= nt: Friday, January 5, 2007 1:01:06 PM
Subject: RE: [Ips] Response Fence= Flag

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

Mallikarjun,

=0A

I must admit, that I have been a bit co= nfused with the direction of the conversation here.

=0A

 

= =0A

Therefore, I went ba= ck and reviewed the charts from Dallas .  And as I remembered, the ini= tial focus was to address the issue of Multiple Connections per Session (MC= /S) (as stated on chart 4 =96 =93Non-issue for single-connection iSCSI sess= ions=94).  So I think I have missed the step where we have morphed the= discussion into one dealing with multiple sessions.  (I am not sure h= ow that happened, or if I miss-read the charts from Dallas , or have not fo= llowed the discussion adequately.)

=0A

 

=0A

If we are attempting to define two diff= erent issues, one with MC/S and one with Multiple Session from different In= itiators, I think it would be useful to break down the conversation into To= pic A =96 MC/S and Topic B Multiple Sessions.  It is possible that one= solution will addresses both, but I for one think I am hearing arguments t= hat might be appropriate for Topic B, while I am thinking about its applica= bility to Topic A.

=0A

 

=0A

Perhaps, you could address the issue as either being a= ll about MC/S or explicitly state that it is intended to affect Multiple Se= ssions also, and then address the issues and solution for each separately.&= nbsp; For example, I believe Robert was addressing the issue from a view of= Multiple Sessions and if we only intended to address MC/S then I expect th= e response might be somewhat different.

=0A

 

=0A

Anyway, if you could clear-up some= of this, I think it would be useful (at least to me).

=0A=

 <= /P>=0A

=0A

.

=0A

.

=0A

.=

=0A

John L Huf= ferd

=0A

Sr. Executive Direct= or of TechnologyBrocade = Communications Systems, Inc

=0A

jhufferd@brocade.com

=0A

Office Phone: (408) 333-5244; eFAX: (40= 8) 904-4688

=0A

Alt Office Ph= one: (408) 997-6136; Cell: (408) 627-9606<= SPAN style=3D"COLOR: navy">

=0A

=  

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

From: Ma= llikarjun C. [mailto:cb_mallikarjun@yahoo.com]
Sent: Friday, January 05, 2007 10:08 AM
To: ips@ietf.org
Subject: Re: [Ips] Response Fence Flag

=0A

 

=0A
= =0A
=0A

Not really.  Current draft text is intent= ionally written to not have any dependencies on T10 dynamics.  The poi= nt is that iSCSI needs such a notion for succinctly describing the pro= per iSCSI protocol actions in a few places - ACA, TMF, Persistent rese= rve/Abort to name a few.  We certainly hope it will be approved by T10= and be a part of SAM-4 soon, but that isn't required per se for descr= ibing what iSCSI needs for its correct behavior.

=0A=
=0A

 

=0A
=0A

IPS WG has adopted what it needs in the past - staying = ahead of T10 review/approval cycle if necessary.  I_T nexus loss notif= ication, iSCSI target/port naming, clearing effects are a few I recall.

=0A
=0A

 

=0A
=0A

Mallikarjun

=0A=0A



 

=0A
=0A

----- Original Message ----
= From: Eddy Quicksall <Quicksall_iSCSI@Bellsouth.net>
To: Robert Sn= ively <rsnively@Brocade.COM>; "Elliott, Robert (Server Storage)" <= Elliott@hp.com>; ips@ietf.org
Sent: Friday, January 5, 2007 8:58:47 A= M
Subject: Re: [Ips] Response Fence Flag

=0A
=0A

From an earlier email I think that Response Fence = is only a proposal in T10 (http://www.t10.org:80/doc06.htm). If so should= n't iSCSI wait a bit until this has been ratified?

= =0A
=0A

 

=0A
=0A

Eddy


__________________________________________________
Do = You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection aro= und
http://mail.yahoo.com --0-867321842-1168037112=:74014-- --===============1853556680== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============1853556680==-- From ips-bounces@ietf.org Fri Jan 05 18:48:19 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2yn0-0004fJ-Ju; Fri, 05 Jan 2007 18:47:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2ymy-0004fB-LS for ips@ietf.org; Fri, 05 Jan 2007 18:47:56 -0500 Received: from imf22aec.mail.bellsouth.net ([205.152.59.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2ymv-0001ZP-3J for ips@ietf.org; Fri, 05 Jan 2007 18:47:56 -0500 Received: from ibm67aec.bellsouth.net ([74.245.52.54]) by imf22aec.mail.bellsouth.net with ESMTP id <20070105234743.IFAJ28979.imf22aec.mail.bellsouth.net@ibm67aec.bellsouth.net> for ; Fri, 5 Jan 2007 18:47:43 -0500 Received: from IVVTDKV0981 ([74.245.52.54]) by ibm67aec.bellsouth.net with SMTP id <20070105234742.LLL5296.ibm67aec.bellsouth.net@IVVTDKV0981>; Fri, 5 Jan 2007 18:47:42 -0500 Message-ID: <00f401c73123$e3b53af0$01faa8c0@ivivity.com> From: "Eddy Quicksall" To: "Julian Satran" References: Subject: Re: [Ips] iSCSI Implementer's Guide - WG Last Call status Date: Fri, 5 Jan 2007 18:47:25 -0500 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.3 (/) X-Scan-Signature: b360bd6cb019c35178e5cf9eeb747a5c Cc: ips@ietf.org, Paul Koning X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1713617448==" Errors-To: ips-bounces@ietf.org This is a multi-part message in MIME format. --===============1713617448== Content-Type: multipart/alternative; boundary="----=_NextPart_000_00E6_01C730F9.F110ABA0" This is a multi-part message in MIME format. ------=_NextPart_000_00E6_01C730F9.F110ABA0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Yea, what Paul suggested is also what I suggested in the beginning. If = that is ok then do you still think it would help clear things up? I also go along with what Mallikarjun said and David seemed to back up = ... that we should probably go over the MUST's and see which are = actually needed (I think that is what he meant). Eddy ----- Original Message -----=20 From: Julian Satran=20 To: Eddy Quicksall=20 Cc: cb_mallikarjun@yahoo.com ; ips@ietf.org ; Paul Koning=20 Sent: Friday, January 05, 2007 3:27 PM Subject: Re: [Ips] iSCSI Implementer's Guide - WG Last Call status Eddy,=20 It was stated here several times already that the general rule in RFCs = is that sender has to be strict and the receiver lenient.=20 It is however really difficult to say what exactly lenient means (as = it is very much dependent on implementations). The rules are stated in = terms of what a sender must do.=20 It is also obvious that draft authors would be reluctant to make a = blanket statement of the receiver not being manadated to check (as in = some case that might be blatantly incorrect). Just to give you an = example - would it be acceptable to say that a sender has to put a = correct CRC in the frame but the receiver is free not to check it ?=20 A blanket statement like the one you requested would cover such a = behaviour too (that would be obviously incorect). Perhaps a statement = along the lines of what Paul suggest ed with the caveat -"as long as it = does not violate an explicit rule" should be enough.=20 Regards,=20 Julo=20 "Eddy Quicksall" =20 05/01/07 11:25=20 To "Paul Koning" , = =20 cc ips@ietf.org =20 Subject Re: [Ips] iSCSI Implementer's Guide - WG Last Call = status=20 =20 =20 I remember long ago talking about this when we were developing the = RFC. I=20 remember some people clearly saying that if the RFC said "must do X" = then it=20 meant that the peer "must check X". I didn't pursue the issue because = it=20 seemed to be of little importance. But as time went on and the draft got finalized, I ran into cases = where that=20 view was still taken to hart. Of course "the customer is always right" = so I=20 added checks. More recently I thought that since this guide was being written that = maybe a=20 simple statement could be made to clarify the issue. I'm not debating the issue of the importance of making a check or even = the=20 criteria for making the check. Eddy ----- Original Message -----=20 From: "Paul Koning" To: Cc: Sent: Thursday, January 04, 2007 6:00 PM Subject: Re: [Ips] iSCSI Implementer's Guide - WG Last Call status >>>>>> "Mallikarjun" =3D=3D Mallikarjun C = writes: > > Mallikarjun> Paul, Agree with everything you wrote. > > Mallikarjun> RFC 3720 does not require sane reactions to non-sane > Mallikarjun> inputs. This draft should not say anything that > Mallikarjun> suggests target/initiator may draw sane interpretations > Mallikarjun> to non-sane inputs either. > > Great summary. > > Mallikarjun> Sounds like an agreement to not add any new text to me. > > Well, Eddy raised the issue a while back that some people writing > conformance tests were interpreting "initiator must do X" as "target > must check that initiator does X". That's clearly an incorrect > conclusion. But given that people make this mistake, I wonder if a > note in the guide saying "unless RFC 3720 specifically requires it, = an > implementation is not required to do protocol conformance checking = on > incoming message", or something like that, would be helpful. > > paul > > > _______________________________________________ > Ips mailing list > Ips@ietf.org > https://www1.ietf.org/mailman/listinfo/ips >=20 _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips ------=_NextPart_000_00E6_01C730F9.F110ABA0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Yea, what Paul suggested is also what I suggested in = the=20 beginning. If that is ok then do you still think it would help clear = things=20 up?
 
I also go along with what Mallikarjun said and David = seemed to=20 back up ... that we should probably go over the MUST's and see which are = actually needed (I think that is what he meant).
 
Eddy
----- Original Message -----
From:=20 Julian Satran
To: Eddy Quicksall =
Cc: cb_mallikarjun@yahoo.com = ; ips@ietf.org ; = Paul=20 Koning
Sent: Friday, January 05, 2007 = 3:27=20 PM
Subject: Re: [Ips] iSCSI = Implementer's=20 Guide - WG Last Call status


Eddy, =

It was stated here several times already = that the=20 general rule in RFCs is that sender has to be strict and the receiver=20 lenient.
It is however = really=20 difficult to say what exactly lenient means (as it is very much = dependent on=20 implementations). The rules are stated in terms of what a sender must=20 do.
It is also obvious = that draft=20 authors would be reluctant to make a blanket statement of the receiver = not=20 being manadated to check (as in some case that might be blatantly = incorrect).=20 Just to give you an example - would it be acceptable to say that a = sender has=20 to put a correct CRC in the frame but the receiver is free not to = check it=20 ?
A blanket statement like = the one you=20 requested would cover such a behaviour too (that would be obviously = incorect).=20 Perhaps a statement along the lines of what Paul suggest ed with =  the=20 caveat -"as long as it does not violate an explicit rule" should be=20 enough.

Regards,
Julo


"Eddy = Quicksall"=20 <Quicksall_iSCSI@Bellsouth.net>

05/01/07 11:25

To
"Paul Koning"=20 <pkoning@equallogic.com>,=20 <cb_mallikarjun@yahoo.com>=20
cc
ips@ietf.org=20
Subject
Re: [Ips] iSCSI = Implementer's=20 Guide - WG Last Call = status

=




I remember long ago talking about this when we were = developing the RFC.=20 I
remember some people clearly saying that if the RFC said "must = do X"=20 then it
meant that the peer "must check X". I didn't pursue the = issue=20 because it
seemed to be of little importance.

But as time = went on=20 and the draft got finalized, I ran into cases where that
view was = still=20 taken to hart. Of course "the customer is always right" so I
added = checks.

More recently I thought that since this guide was being = written=20 that maybe a
simple statement could be made to clarify the=20 issue.

I'm not debating the issue of the importance of making a = check=20 or even the
criteria for making the = check.

Eddy

-----=20 Original Message -----
From: "Paul Koning"=20 <pkoning@equallogic.com>
To: = <cb_mallikarjun@yahoo.com>
Cc:=20 <ips@ietf.org>
Sent: Thursday, January 04, 2007 6:00 = PM
Subject:=20 Re: [Ips] iSCSI Implementer's Guide - WG Last Call=20 status


>>>>>> "Mallikarjun" =3D=3D = Mallikarjun C=20 <cb_mallikarjun@yahoo.com> writes:
>
> = Mallikarjun> Paul,=20 Agree with everything you wrote.
>
> Mallikarjun> RFC = 3720 does=20 not require sane reactions to non-sane
> Mallikarjun> inputs. =  This draft should not say anything that
> Mallikarjun> = suggests=20 target/initiator may draw sane interpretations
> Mallikarjun> = to=20 non-sane inputs either.
>
> Great summary.
>
> = Mallikarjun> Sounds like an agreement to not add any new text to=20 me.
>
> Well, Eddy raised the issue a while back that some = people=20 writing
> conformance tests were interpreting "initiator must do = X" as=20 "target
> must check that initiator does X".  That's = clearly an=20 incorrect
> conclusion.  But given that people make this = mistake, I=20 wonder if a
> note in the guide saying "unless RFC 3720 = specifically=20 requires it, an
> implementation is not required to do protocol=20 conformance checking on
> incoming message", or something like = that,=20 would be helpful.
>
>    =20  paul
>
>
>=20 _______________________________________________
> Ips mailing=20 list
> Ips@ietf.org
>=20 https://www1.ietf.org/mailman/listinfo/ips
>=20


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

------=_NextPart_000_00E6_01C730F9.F110ABA0-- --===============1713617448== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============1713617448==-- From ips-bounces@ietf.org Fri Jan 05 18:49:13 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2yoD-0005IP-HR; Fri, 05 Jan 2007 18:49:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2yoD-0005IK-5M for ips@ietf.org; Fri, 05 Jan 2007 18:49:13 -0500 Received: from imf22aec.mail.bellsouth.net ([205.152.59.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2yoC-0002Rs-LA for ips@ietf.org; Fri, 05 Jan 2007 18:49:13 -0500 Received: from ibm67aec.bellsouth.net ([74.245.52.54]) by imf22aec.mail.bellsouth.net with ESMTP id <20070105234912.IJUY28979.imf22aec.mail.bellsouth.net@ibm67aec.bellsouth.net> for ; Fri, 5 Jan 2007 18:49:12 -0500 Received: from IVVTDKV0981 ([74.245.52.54]) by ibm67aec.bellsouth.net with SMTP id <20070105234911.LYP5296.ibm67aec.bellsouth.net@IVVTDKV0981>; Fri, 5 Jan 2007 18:49:11 -0500 Message-ID: <00fd01c73124$1908f6b0$01faa8c0@ivivity.com> From: "Eddy Quicksall" To: "Julian Satran" References: Subject: Re: [Ips] iSCSI Implementer's Guide - WG Last Call status Date: Fri, 5 Jan 2007 18:49:05 -0500 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.3 (/) X-Scan-Signature: 9cc83ac38bbbabacbf00f656311dd8d8 Cc: ips@ietf.org, Paul Koning X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0453378355==" Errors-To: ips-bounces@ietf.org This is a multi-part message in MIME format. --===============0453378355== Content-Type: multipart/alternative; boundary="----=_NextPart_000_00F5_01C730FA.2CB00980" This is a multi-part message in MIME format. ------=_NextPart_000_00F5_01C730FA.2CB00980 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Just another note on what you said below "it was stated here several = times...". I know it has been in emails for a long time but I found that = testers' don't use what is said in emails as a criteria. That is why I = thought it would be good to add a statement. Eddy ----- Original Message -----=20 From: Julian Satran=20 To: Eddy Quicksall=20 Cc: cb_mallikarjun@yahoo.com ; ips@ietf.org ; Paul Koning=20 Sent: Friday, January 05, 2007 3:27 PM Subject: Re: [Ips] iSCSI Implementer's Guide - WG Last Call status Eddy,=20 It was stated here several times already that the general rule in RFCs = is that sender has to be strict and the receiver lenient.=20 It is however really difficult to say what exactly lenient means (as = it is very much dependent on implementations). The rules are stated in = terms of what a sender must do.=20 It is also obvious that draft authors would be reluctant to make a = blanket statement of the receiver not being manadated to check (as in = some case that might be blatantly incorrect). Just to give you an = example - would it be acceptable to say that a sender has to put a = correct CRC in the frame but the receiver is free not to check it ?=20 A blanket statement like the one you requested would cover such a = behaviour too (that would be obviously incorect). Perhaps a statement = along the lines of what Paul suggest ed with the caveat -"as long as it = does not violate an explicit rule" should be enough.=20 Regards,=20 Julo=20 "Eddy Quicksall" =20 05/01/07 11:25=20 To "Paul Koning" , = =20 cc ips@ietf.org =20 Subject Re: [Ips] iSCSI Implementer's Guide - WG Last Call = status=20 =20 =20 I remember long ago talking about this when we were developing the = RFC. I=20 remember some people clearly saying that if the RFC said "must do X" = then it=20 meant that the peer "must check X". I didn't pursue the issue because = it=20 seemed to be of little importance. But as time went on and the draft got finalized, I ran into cases = where that=20 view was still taken to hart. Of course "the customer is always right" = so I=20 added checks. More recently I thought that since this guide was being written that = maybe a=20 simple statement could be made to clarify the issue. I'm not debating the issue of the importance of making a check or even = the=20 criteria for making the check. Eddy ----- Original Message -----=20 From: "Paul Koning" To: Cc: Sent: Thursday, January 04, 2007 6:00 PM Subject: Re: [Ips] iSCSI Implementer's Guide - WG Last Call status >>>>>> "Mallikarjun" =3D=3D Mallikarjun C = writes: > > Mallikarjun> Paul, Agree with everything you wrote. > > Mallikarjun> RFC 3720 does not require sane reactions to non-sane > Mallikarjun> inputs. This draft should not say anything that > Mallikarjun> suggests target/initiator may draw sane interpretations > Mallikarjun> to non-sane inputs either. > > Great summary. > > Mallikarjun> Sounds like an agreement to not add any new text to me. > > Well, Eddy raised the issue a while back that some people writing > conformance tests were interpreting "initiator must do X" as "target > must check that initiator does X". That's clearly an incorrect > conclusion. But given that people make this mistake, I wonder if a > note in the guide saying "unless RFC 3720 specifically requires it, = an > implementation is not required to do protocol conformance checking = on > incoming message", or something like that, would be helpful. > > paul > > > _______________________________________________ > Ips mailing list > Ips@ietf.org > https://www1.ietf.org/mailman/listinfo/ips >=20 _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips ------=_NextPart_000_00F5_01C730FA.2CB00980 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Just another note on what you said below "it was = stated here=20 several times...". I know it has been in emails for a long time but I = found that=20 testers' don't use what is said in emails as a criteria. That is why I = thought=20 it would be good to add a statement.
 
Eddy
----- Original Message -----
From:=20 Julian Satran
To: Eddy Quicksall =
Cc: cb_mallikarjun@yahoo.com = ; ips@ietf.org ; = Paul=20 Koning
Sent: Friday, January 05, 2007 = 3:27=20 PM
Subject: Re: [Ips] iSCSI = Implementer's=20 Guide - WG Last Call status


Eddy, =

It was stated here several times already = that the=20 general rule in RFCs is that sender has to be strict and the receiver=20 lenient.
It is however = really=20 difficult to say what exactly lenient means (as it is very much = dependent on=20 implementations). The rules are stated in terms of what a sender must=20 do.
It is also obvious = that draft=20 authors would be reluctant to make a blanket statement of the receiver = not=20 being manadated to check (as in some case that might be blatantly = incorrect).=20 Just to give you an example - would it be acceptable to say that a = sender has=20 to put a correct CRC in the frame but the receiver is free not to = check it=20 ?
A blanket statement like = the one you=20 requested would cover such a behaviour too (that would be obviously = incorect).=20 Perhaps a statement along the lines of what Paul suggest ed with =  the=20 caveat -"as long as it does not violate an explicit rule" should be=20 enough.

Regards,
Julo


"Eddy = Quicksall"=20 <Quicksall_iSCSI@Bellsouth.net>

05/01/07 11:25

To
"Paul Koning"=20 <pkoning@equallogic.com>,=20 <cb_mallikarjun@yahoo.com>=20
cc
ips@ietf.org=20
Subject
Re: [Ips] iSCSI = Implementer's=20 Guide - WG Last Call = status

=




I remember long ago talking about this when we were = developing the RFC.=20 I
remember some people clearly saying that if the RFC said "must = do X"=20 then it
meant that the peer "must check X". I didn't pursue the = issue=20 because it
seemed to be of little importance.

But as time = went on=20 and the draft got finalized, I ran into cases where that
view was = still=20 taken to hart. Of course "the customer is always right" so I
added = checks.

More recently I thought that since this guide was being = written=20 that maybe a
simple statement could be made to clarify the=20 issue.

I'm not debating the issue of the importance of making a = check=20 or even the
criteria for making the = check.

Eddy

-----=20 Original Message -----
From: "Paul Koning"=20 <pkoning@equallogic.com>
To: = <cb_mallikarjun@yahoo.com>
Cc:=20 <ips@ietf.org>
Sent: Thursday, January 04, 2007 6:00 = PM
Subject:=20 Re: [Ips] iSCSI Implementer's Guide - WG Last Call=20 status


>>>>>> "Mallikarjun" =3D=3D = Mallikarjun C=20 <cb_mallikarjun@yahoo.com> writes:
>
> = Mallikarjun> Paul,=20 Agree with everything you wrote.
>
> Mallikarjun> RFC = 3720 does=20 not require sane reactions to non-sane
> Mallikarjun> inputs. =  This draft should not say anything that
> Mallikarjun> = suggests=20 target/initiator may draw sane interpretations
> Mallikarjun> = to=20 non-sane inputs either.
>
> Great summary.
>
> = Mallikarjun> Sounds like an agreement to not add any new text to=20 me.
>
> Well, Eddy raised the issue a while back that some = people=20 writing
> conformance tests were interpreting "initiator must do = X" as=20 "target
> must check that initiator does X".  That's = clearly an=20 incorrect
> conclusion.  But given that people make this = mistake, I=20 wonder if a
> note in the guide saying "unless RFC 3720 = specifically=20 requires it, an
> implementation is not required to do protocol=20 conformance checking on
> incoming message", or something like = that,=20 would be helpful.
>
>    =20  paul
>
>
>=20 _______________________________________________
> Ips mailing=20 list
> Ips@ietf.org
>=20 https://www1.ietf.org/mailman/listinfo/ips
>=20


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

------=_NextPart_000_00F5_01C730FA.2CB00980-- --===============0453378355== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============0453378355==-- From ips-bounces@ietf.org Fri Jan 05 19:52:38 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2znC-0005lJ-33; Fri, 05 Jan 2007 19:52:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2znA-0005kc-L4 for ips@ietf.org; Fri, 05 Jan 2007 19:52:12 -0500 Received: from web51909.mail.yahoo.com ([206.190.48.72]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H2zn9-0004I6-5S for ips@ietf.org; Fri, 05 Jan 2007 19:52:12 -0500 Received: (qmail 45170 invoked by uid 60001); 6 Jan 2007 00:52:11 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type; b=y64OdWFr5axLgy3Jcb1TgudhTcEg1Y2hdPYB90xgklgVKlEz4Ki0IRi87Dq3OSr3MBrdyChClTdcGD6bN/tA+BE94WwfcYQ3ZDCp+jDzpEGjQYC5vtiOGVOJl/67YNCa+Jm8CKs6bv31x/+Bkg/2G4tdSxmnfsreOOp09trYmqQ= ; Message-ID: <20070106005210.45168.qmail@web51909.mail.yahoo.com> Received: from [15.227.217.75] by web51909.mail.yahoo.com via HTTP; Fri, 05 Jan 2007 16:52:10 PST Date: Fri, 5 Jan 2007 16:52:05 -0800 (PST) From: "Mallikarjun C." Subject: Re: [Ips] iSCSI Implementer's Guide - WG Last Call status To: ips@ietf.org MIME-Version: 1.0 X-Spam-Score: 0.3 (/) X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290 X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1128124072==" Errors-To: ips-bounces@ietf.org --===============1128124072== Content-Type: multipart/alternative; boundary="0-1512509183-1168044725=:43988" --0-1512509183-1168044725=:43988 Content-Type: text/plain; charset=ascii Content-Transfer-Encoding: quoted-printable I will add something very close to what Paul had suggested. Thanks to all = for contributing to the discussion.=0A=0AMallikarjun=0A=0A=0A----- Original= Message ----=0AFrom: Eddy Quicksall =0ATo: = Julian Satran =0ACc: cb_mallikarjun@yahoo.com; ip= s@ietf.org; Paul Koning =0ASent: Friday, January 5,= 2007 3:49:05 PM=0ASubject: Re: [Ips] iSCSI Implementer's Guide - WG Last C= all status=0A=0A=0AJust another note on what you said below "it was stated = here several times...". I know it has been in emails for a long time but I = found that testers' don't use what is said in emails as a criteria. That is= why I thought it would be good to add a statement.=0A =0AEddy=0A----- Orig= inal Message ----- =0AFrom: Julian Satran =0ATo: Eddy Quicksall =0ACc: cb_m= allikarjun@yahoo.com ; ips@ietf.org ; Paul Koning =0ASent: Friday, January = 05, 2007 3:27 PM=0ASubject: Re: [Ips] iSCSI Implementer's Guide - WG Last C= all status=0A=0A=0A=0AEddy, =0A=0AIt was stated here several times already = that the general rule in RFCs is that sender has to be strict and the recei= ver lenient. =0AIt is however really difficult to say what exactly lenient = means (as it is very much dependent on implementations). The rules are stat= ed in terms of what a sender must do. =0AIt is also obvious that draft auth= ors would be reluctant to make a blanket statement of the receiver not bein= g manadated to check (as in some case that might be blatantly incorrect). J= ust to give you an example - would it be acceptable to say that a sender ha= s to put a correct CRC in the frame but the receiver is free not to check i= t ? =0AA blanket statement like the one you requested would cover such a be= haviour too (that would be obviously incorect). Perhaps a statement along t= he lines of what Paul suggest ed with the caveat -"as long as it does not = violate an explicit rule" should be enough. =0A=0ARegards, =0AJulo =0A=0A= =0A"Eddy Quicksall" =0A05/01/07 11:25 To"Pa= ul Koning" , =0Accips@ie= tf.org =0ASubjectRe: [Ips] iSCSI Implementer's Guide - WG Last Call status= =0A=0A=0A=0A=0A=0A=0A=0AI remember long ago talking about this when we were= developing the RFC. I =0Aremember some people clearly saying that if the R= FC said "must do X" then it =0Ameant that the peer "must check X". I didn't= pursue the issue because it =0Aseemed to be of little importance.=0A=0ABut= as time went on and the draft got finalized, I ran into cases where that = =0Aview was still taken to hart. Of course "the customer is always right" s= o I =0Aadded checks.=0A=0AMore recently I thought that since this guide was= being written that maybe a =0Asimple statement could be made to clarify th= e issue.=0A=0AI'm not debating the issue of the importance of making a chec= k or even the =0Acriteria for making the check.=0A=0AEddy=0A=0A____________= ______________________________________=0ADo You Yahoo!?=0ATired of spam? Y= ahoo! Mail has the best spam protection around =0Ahttp://mail.yahoo.com --0-1512509183-1168044725=:43988 Content-Type: text/html; charset=ascii Content-Transfer-Encoding: quoted-printable
I will add something very close to what Paul had = suggested.  Thanks to all for contributing to the discussion.
=0A=
 
=0A
Mallikarjun

=0A
= ----- Original Message ----
From: Eddy Quicksall <Quicksall_iSCSI@Bel= lsouth.net>
To: Julian Satran <Julian_Satran@il.ibm.com>
Cc:= cb_mallikarjun@yahoo.com; ips@ietf.org; Paul Koning <pkoning@equallogic= .com>
Sent: Friday, January 5, 2007 3:49:05 PM
Subject: Re: [Ips] = iSCSI Implementer's Guide - WG Last Call status

=0A= =0A=0A
Just another note on what you said below "it was = stated here several times...". I know it has been in emails for a long time= but I found that testers' don't use what is said in emails as a criteria. = That is why I thought it would be good to add a statement.
=0A<= DIV> 
=0A
Eddy=0A
=0A
----- Original Message -----
=0A=0A
To:<= /B> Eddy Quicksall
=0A= =0A
S= ent: Friday, January 05, 2007 3:27 PM
=0A
Subject: Re: [Ips] iSCSI Implementer's Guide - WG Last Call s= tatus
=0A


Eddy,

It was stated here several tim= es already that the general rule in RFCs is that sender has to be strict an= d the receiver lenient.
It is h= owever really difficult to say what exactly lenient means (as it is very mu= ch dependent on implementations). The rules are stated in terms of what a s= ender must do.
It is also obvio= us that draft authors would be reluctant to make a blanket statement of the= receiver not being manadated to check (as in some case that might be blata= ntly incorrect). Just to give you an example - would it be acceptable to sa= y that a sender has to put a correct CRC in the frame but the receiver is f= ree not to check it ?
A blanket= statement like the one you requested would cover such a behaviour too (tha= t would be obviously incorect). Perhaps a statement along the lines of what Paul suggest ed with  the caveat -"= as long as it does not violate an explicit rule" should be enough. <= BR>
Regards,
Julo


=0A=0A=0A=0A
"Eddy Quicksall" <Quicksall_iSCSI@Bellsouth.net> =0A05/01/07 11:25

=0A		=0A=0A=0A=0A=0A=0A
=0ATo=0A"Paul Koning" <pkoning@equallogic.com>, &= lt;cb_mallikarjun@yahoo.com> =0A
=0A
cc
=0A		ips@ietf.org =0A
= =0A
Subject
= =0A		Re: [Ips] iSCSI Implementer's Guide= - WG Last Call status

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




I remember long ago talki= ng about this when we were developing the RFC. I
remember some people c= learly saying that if the RFC said "must do X" then it
meant that the p= eer "must check X". I didn't pursue the issue because it
seemed to be o= f little importance.

But as time went on and the draft got finalized= , I ran into cases where that
view was still taken to hart. Of course "= the customer is always right" so I
added checks.

More recently I= thought that since this guide was being written that maybe a
simple st= atement could be made to clarify the issue.

I'm not debating the iss= ue of the importance of making a check or even the
criteria for making = the check.

Eddy

=0A
=  

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


If your target =  answers=20 fast and expects data from other initiators it may have to track = ITT-TTT. This=20 is not on the fast path (data path) so I am not quite sure what is=20 difficult.

Julo =


"Eddy = Quicksall" <Quicksall_iSCSI@Bellsouth.n= et>=20

13/12/06 00:46

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

=




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


David,

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

Julo

Black_David@emc.com=20

12/12/06 20:26=20


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







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


David and Mallikarjun, =

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

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

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

Regards, =
Julo =


Black_David@emc.com=20

11/12/06 20:56=20


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









Mallikarjun,

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

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

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

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

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

Not exactly, see above.

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

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

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

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

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

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

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

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

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

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

Ok.

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

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

Thanks,
--David=20

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

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

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

_______________________________________________
Ips mailing=20 = list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips
------=_NextPart_000_01FF_01C73106.E87BA2D0-- --===============0688593363== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============0688593363==-- From ips-bounces@ietf.org Fri Jan 05 21:07:25 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H30xt-0001qd-7f; Fri, 05 Jan 2007 21:07:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H30xs-0001qX-Qt for ips@ietf.org; Fri, 05 Jan 2007 21:07:20 -0500 Received: from imf21aec.mail.bellsouth.net ([205.152.59.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H30xr-0000bM-F9 for ips@ietf.org; Fri, 05 Jan 2007 21:07:20 -0500 Received: from ibm63aec.bellsouth.net ([74.245.52.54]) by imf21aec.mail.bellsouth.net with ESMTP id <20070106020716.QMHW18446.imf21aec.mail.bellsouth.net@ibm63aec.bellsouth.net> for ; Fri, 5 Jan 2007 21:07:16 -0500 Received: from IVVTDKV0981 ([74.245.52.54]) by ibm63aec.bellsouth.net with SMTP id <20070106020716.FHNO3802.ibm63aec.bellsouth.net@IVVTDKV0981>; Fri, 5 Jan 2007 21:07:16 -0500 Message-ID: <02aa01c73137$6344e410$01faa8c0@ivivity.com> From: "Eddy Quicksall" To: "Eddy Quicksall" , "Julian Satran" Subject: Re: [Ips] Implementer's Guide - Task Management Issue Date: Fri, 5 Jan 2007 21:07:15 -0500 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.2 (/) X-Scan-Signature: e1924de3f9fb68e58c31920136007eb1 Cc: ips@ietf.org, Black_David@emc.com X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2064494859==" Errors-To: ips-bounces@ietf.org This is a multi-part message in MIME format. --===============2064494859== Content-Type: multipart/alternative; boundary="----=_NextPart_000_02A7_01C7310D.7A0A9C00" This is a multi-part message in MIME format. ------=_NextPart_000_02A7_01C7310D.7A0A9C00 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable ----- Original Message -----=20 From: Eddy Quicksall=20 To: Julian Satran=20 Cc: ips@ietf.org ; Black_David@emc.com=20 Sent: Friday, January 05, 2007 8:36 PM Subject: Re: [Ips] Implementer's Guide - Task Management Issue I'm sorry ... I realize I may have been out of context when I posted = the question ... I thought you were talking about the fast path. Eddy ----- Original Message -----=20 From: Eddy Quicksall=20 To: Julian Satran=20 Cc: ips@ietf.org ; Black_David@emc.com=20 Sent: Friday, January 05, 2007 8:20 PM Subject: Re: [Ips] Implementer's Guide - Task Management Issue The ITT-TTT are tracked for the life of the task. Eddy ----- Original Message -----=20 From: Julian Satran=20 To: Eddy Quicksall=20 Cc: ips@ietf.org ; Black_David@emc.com=20 Sent: Wednesday, December 13, 2006 10:35 AM Subject: Re: [Ips] Implementer's Guide - Task Management Issue If your target answers fast and expects data from other = initiators it may have to track ITT-TTT. This is not on the fast path = (data path) so I am not quite sure what is difficult.=20 Julo=20 "Eddy Quicksall" =20 13/12/06 00:46=20 To , Julian Satran/Haifa/IBM@IBMIL =20 cc =20 Subject Re: [Ips] Implementer's Guide - Task = Management Issue=20 =20 =20 I want to be sure of something here ... you are not requiring this = ITT-TTT tracking are you? It would be very difficult for hardware.=20 =20 Eddy=20 ------=_NextPart_000_02A7_01C7310D.7A0A9C00 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 
----- Original Message -----
From:=20 Eddy Quicksall =
Sent: Friday, January 05, 2007 = 8:36=20 PM
Subject: Re: [Ips] = Implementer's Guide -=20 Task Management Issue

I'm sorry ... I realize I may have been out of = context when=20 I posted the question ... I thought you were talking about the = fast=20 path.
 
Eddy
----- Original Message -----
From:=20 Eddy Quicksall =
Sent: Friday, January 05, = 2007 8:20=20 PM
Subject: Re: [Ips] = Implementer's Guide=20 - Task Management Issue

The ITT-TTT are tracked for the life of the=20 task.
 
Eddy
----- Original Message ----- =
From:=20 Julian Satran
To: Eddy Quicksall =
Sent: Wednesday, December = 13, 2006=20 10:35 AM
Subject: Re: [Ips] = Implementer's=20 Guide - Task Management Issue


If your target =  answers fast and expects data from other initiators it may = have to=20 track ITT-TTT. This is not on the fast path (data path) so I am = not quite=20 sure what is difficult.

Julo


"Eddy = Quicksall"=20 <Quicksall_iSCSI@Bellsouth.n= et>=20

13/12/06 00:46 =

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

=




<= FONT=20 size=3D2>I want to be sure of something here ... you are not = requiring this=20 ITT-TTT tracking are you? It would be very difficult for = hardware.=20
 
Eddy=20
------=_NextPart_000_02A7_01C7310D.7A0A9C00-- --===============2064494859== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============2064494859==-- From ips-bounces@ietf.org Sat Jan 06 00:38:59 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H34G9-0004gr-1K; Sat, 06 Jan 2007 00:38:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H34G7-0004gm-R8 for ips@ietf.org; Sat, 06 Jan 2007 00:38:23 -0500 Received: from mga01.intel.com ([192.55.52.88]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H34G5-0007vW-Gq for ips@ietf.org; Sat, 06 Jan 2007 00:38:23 -0500 Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by mga01.intel.com with ESMTP; 05 Jan 2007 21:38:18 -0800 Received: from fmsmsx333.amr.corp.intel.com ([132.233.42.2]) by fmsmga001.fm.intel.com with ESMTP; 05 Jan 2007 21:38:18 -0800 X-ExtLoop1: 1 X-IronPort-AV: i="4.13,155,1167638400"; d="scan'208,217"; a="185147388:sNHT29089417" Received: from fmsmsx411.amr.corp.intel.com ([10.19.28.152]) by fmsmsx333.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 5 Jan 2007 21:38:19 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 5 Jan 2007 21:38:18 -0800 Message-ID: <10A7D0016239E24092DEF05CCC582E4366D258@fmsmsx411.amr.corp.intel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Unsubscribe Thread-Index: AccxVN5FAmMAcLsmS8KdBmBYFQC4kQ== From: "Sumner, James L" To: X-OriginalArrivalTime: 06 Jan 2007 05:38:19.0195 (UTC) FILETIME=[DF0418B0:01C73154] X-Spam-Score: 0.2 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Subject: [Ips] Unsubscribe X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0757515416==" Errors-To: ips-bounces@ietf.org This is a multi-part message in MIME format. --===============0757515416== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C73154.DEA3CC92" This is a multi-part message in MIME format. ------_=_NextPart_001_01C73154.DEA3CC92 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Please take me off this email distribution ------_=_NextPart_001_01C73154.DEA3CC92 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Please take me off this email = distribution

------_=_NextPart_001_01C73154.DEA3CC92-- --===============0757515416== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============0757515416==-- From ips-bounces@ietf.org Sat Jan 06 09:32:07 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3CaN-0004Kk-OA; Sat, 06 Jan 2007 09:31:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3CaL-0004Kf-J3 for ips@ietf.org; Sat, 06 Jan 2007 09:31:49 -0500 Received: from mtagate4.de.ibm.com ([195.212.29.153]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H3CaH-00063R-A7 for ips@ietf.org; Sat, 06 Jan 2007 09:31:49 -0500 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate4.de.ibm.com (8.13.8/8.13.8) with ESMTP id l06EVgkT152248 for ; Sat, 6 Jan 2007 14:31:43 GMT Received: from d12av02.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1607.megacenter.de.ibm.com (8.13.6/8.13.6/NCO v8.1.1) with ESMTP id l06EVgBp3170350 for ; Sat, 6 Jan 2007 15:31:42 +0100 Received: from d12av02.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l06EVgYt015362 for ; Sat, 6 Jan 2007 15:31:42 +0100 Received: from d12mc102.megacenter.de.ibm.com (d12mc102.megacenter.de.ibm.com [9.149.167.114]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l06EVgka015359 for ; Sat, 6 Jan 2007 15:31:42 +0100 To: ips@ietf.org MIME-Version: 1.0 Subject: Fw: [Ips] Response Fence Flag X-Mailer: Lotus Notes Release 7.0.2 September 26, 2006 From: Julian Satran Message-ID: Date: Sat, 6 Jan 2007 09:31:40 -0500 X-MIMETrack: Serialize by Router on D12MC102/12/M/IBM(Release 7.0.2HF71 | November 3, 2006) at 06/01/2007 16:31:42, Serialize complete at 06/01/2007 16:31:42 X-Spam-Score: 0.5 (/) X-Scan-Signature: 7f3077fcbbd2d4a1504dfa044ebcf773 X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1785682818==" Errors-To: ips-bounces@ietf.org This is a multipart message in MIME format. --===============1785682818== Content-Type: multipart/alternative; boundary="=_alternative 004F68248525725B_=" This is a multipart message in MIME format. --=_alternative 004F68248525725B_= Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable ----- Forwarded by Julian Satran/Haifa/IBM on 06/01/07 09:27 ----- Julian Satran =20 06/01/07 09:22 To "Mallikarjun C." cc IPS , Julian Satran/Haifa/IBM@IBMIL Subject Re: Fw: [Ips] Response Fence Flag Mallikarjun & All, As I pointed out in a private discussion with you I never considered in=20 dept the response-fence (beyond what is needed for TM). It is a serious issue for any "transaction type" operations to storage -=20 but the last interface that had all the pieces correctly aligned was the=20 360 channel. SCSI had taken (traditionally) the positions that sequencing and=20 barriers are rarely needed and when needed applications should provide=20 them. And that is exactly what all of the relevant applications do (all=20 transaction monitors, databases etc.). The way all the application handle cases when the start of some SCSI=20 command has to follow the end of a previous set of operations is to just=20 wait for the end of the operations before issuing the "dependent=20 commands". Is this solution optimal? As you probably observed already this solution=20 implies that all the queues in the "stack" (at initiator, transport and=20 target) get empty before the dependent commands can be issued and that=20 is bad for performance. Can fencing (bad name BTW because it is in widespread use for defect=20 isolation) improve this? Yes (by keeping the pipes full!) provided it is=20 associated with rigorous exception handling and the later is a SCSI=20 issue (exceptions will require emptying the queues). With most=20 applications being distributed I doubt also that fencing for a single=20 I=5FT nexus is interesting and coordinating fencing and exception handling = over several I=5FTs is a complex exercise. And as transport alone brings no value to the whole issue - why should=20 we go through the exercise of defining a solution before SCSI has=20 defined one and we are confident that it is good enough and has value?=20 Again I agree that we a mechanism for TM but a good enough mechanism for=20 TM is already in and it gets now even better even without resorting to a=20 generalized fencing/barrier support. Regards, Julo Mallikarjun C. wrote: > Trying again after bouncing (>50KB), tail is now clipped.... > > ----- Forwarded Message ---- > From: Mallikarjun C. > To: ips@ietf.org > Sent: Friday, January 5, 2007 2:40:56 PM > Subject: Re: [Ips] Response Fence Flag > > Hi John, >=20 > As you correctly point out, there are two distinct but related=20 > topics here. >=20 > (1) proper response ordering across participating connections in a=20 > multi-connection session, for a handful of task/TMF responses > (2) proper way to terminate and signal tasks when actions on one=20 > session can impact multiple initiators >=20 > (1) is all about response fence, it is covered separately in section=20 > 3.3 of IG draft. That's what this email thread started off with. >=20 > (2) covers cases that IG had called as as "multi-task abort" cases=20 > that typically have a shared task set across sessions, or are the=20 > result of a Logical Unit Reset TMF. Section 4.1 of IG adresses (2). >=20 > So how are (1) and (2) related? >=20 > - Some cases covered under (2) overlap with (1), but some cases in (2)=20 > are for single connection sessions. E.g. LU Reset on a single=20 > connection session impacting several 3rd party sessions >=20 > - Some cases under (1) overlap with (2), but some cases in (1) have=20 > nothing to do with other sessions. E.g. establishment of ACA on a=20 > non-shared task set >=20 > - Section 4.1 (i.e. text for (2)) uses response fence (i.e. text for=20 > (1)) whenever multi-connection sessions are involved in multi-task=20 > abort situations. >=20 > I hope that clarifies it. Feel free to ask if that is not clear. The=20 > net is that the response fence is the underpinning notion to describe=20 > the correct iSCSI behavior in a few cases and some of those cases are=20 > about task terminations across third-party sessions. >=20 > Mallikarjun >=20 > > >=20 > ----- Original Message ---- > From: John Hufferd > To: Mallikarjun C. ; ips@ietf.org > Sent: Friday, January 5, 2007 1:01:06 PM > Subject: RE: [Ips] Response Fence Flag > > Mallikarjun, > > I must admit, that I have been a bit confused with the direction of=20 > the conversation here. > >=20 > > Therefore, I went back and reviewed the charts from Dallas . And as I=20 > remembered, the initial focus was to address the issue of Multiple=20 > Connections per Session (MC/S) (as stated on chart 4 ? ?Non-issue for=20 > single-connection iSCSI sessions?). So I think I have missed the step=20 > where we have morphed the discussion into one dealing with multiple=20 > sessions. (I am not sure how that happened, or if I miss-read the=20 > charts from Dallas , or have not followed the discussion adequately.) > >=20 > > If we are attempting to define two different issues, one with MC/S and=20 > one with Multiple Session from different Initiators, I think it would=20 > be useful to break down the conversation into Topic A ? MC/S and Topic=20 > B Multiple Sessions. It is possible that one solution will addresses=20 > both, but I for one think I am hearing arguments that might be=20 > appropriate for Topic B, while I am thinking about its applicability=20 > to Topic A. > >=20 > > Perhaps, you could address the issue as either being all about MC/S or=20 > explicitly state that it is intended to affect Multiple Sessions also,=20 > and then address the issues and solution for each separately. For=20 > example, I believe Robert was addressing the issue from a view of=20 > Multiple Sessions and if we only intended to address MC/S then I=20 > expect the response might be somewhat different. > >=20 > > Anyway, if you could clear-up some of this, I think it would be useful=20 > (at least to me). > >=20 > > . > > . > > . > > John L Hufferd > > Sr. Executive Director of Technology > > Brocade Communications Systems, Inc > > jhufferd@brocade.com > > Office Phone: (408) 333-5244; eFAX: (408) 904-4688 > > Alt Office Phone: (408) 997-6136; Cell: (408) 627-9606 > >=20 > > ------------------------------------------------------------------------ > > *From:* Mallikarjun C. [mailto:cb=5Fmallikarjun@yahoo.com] > *Sent:* Friday, January 05, 2007 10:08 AM > *To:* ips@ietf.org > *Subject:* Re: [Ips] Response Fence Flag > >=20 > > Not really. Current draft text is intentionally written to not have=20 > any dependencies on T10 dynamics. The point is that iSCSI needs such=20 > a notion for succinctly describing the proper iSCSI protocol actions=20 > in a few places - ACA, TMF, Persistent reserve/Abort to name a few.=20 > We certainly hope it will be approved by T10 and be a part of SAM-4=20 > soon, but that isn't required per se for describing what iSCSI needs=20 > for its correct behavior. > >=20 > > IPS WG has adopted what it needs in the past - staying ahead of T10=20 > review/approval cycle if necessary. I=5FT nexus loss notification,=20 > iSCSI target/port naming, clearing effects are a few I recall. > >=20 > > Mallikarjun > > > >=20 > > ----- Original Message ---- > From: Eddy Quicksall > To: Robert Snively ; "Elliott, Robert (Server=20 > Storage)" ; ips@ietf.org > Sent: Friday, January 5, 2007 8:58:47 AM > Subject: Re: [Ips] Response Fence Flag > > From an earlier email I think that Response Fence is only a proposal=20 > in T10 (http://www.t10.org:80/doc06.htm=20 > ). If so shouldn't iSCSI wait a bit=20 > until this has been ratified? > >=20 > > Eddy > > > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around > http://mail.yahoo.com > ------------------------------------------------------------------------ > > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F > Ips mailing list > Ips@ietf.org > https://www1.ietf.org/mailman/listinfo/ips >=20 --=_alternative 004F68248525725B_= Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable
----- Forwarded by J= ulian Satran/Haifa/IBM on 06/01/07 09:27 -----
Julian Satran <jul= ian.satran@gmail.com>

06/01/07 09:22

To
"Mallikarjun C." <cb=5F= mallikarjun@yahoo.com>
cc
IPS <ips@ietf.org>, Julian Sat= ran/Haifa/IBM@IBMIL
Subject
Re: Fw: [Ips] Response Fence Flag





Mallikarjun & All,

As I pointed out in a private discussion with you I never considered in
dept the response-fence (beyond what is needed for TM).
It is a serious issue for any "transaction type" operations to storage -
but the last interface that had all the pieces correctly aligned was the
360 channel.
SCSI had taken (traditionally) the positions that sequencing and
barriers are rarely needed and when needed applications should provide them.
And that is exactly what all of the relevant applications do (all
transaction monitors, databases etc.).

The way all the application handle cases when the start of some SCSI
command has to follow the end of a previous set of operations is to just
wait for the end of the operations before issuing the "dependent comma= nds".

Is this solution optimal? As you probably observed already this solution
implies that all the queues in the "stack" (at initiator, transpo= rt and
target) get empty before the dependent commands can be issued and that
is bad for performance.

Can fencing (bad name BTW because it is in widespread use for defect
isolation) improve this? Yes (by keeping the pipes full!) provided it is
associated with rigorous exception handling and the later is a SCSI
issue (exceptions will require emptying the queues). With most
applications being distributed I doubt also that fencing for a single
I=5FT nexus is interesting and coordinating fencing and exception handling
over several I=5FTs is a complex exercise.

And as transport alone brings no value to the whole issue - why  should
we go through the exercise of defining a solution before SCSI has
defined one and we are confident that it is good enough and has value?
Again I agree that we a mechanism for TM but a good enough mechanism for
TM is already in and it gets now even better even without resorting to a
generalized fencing/barrier support.

Regards,
Julo








Mallikarjun C. wrote:
> Trying again after bouncing (>50KB), tail is now clipped....
>
> ----- Forwarded Message ----
> From: Mallikarjun C. <cb=5Fmallikarjun@yahoo.com>
> To: ips@ietf.org
> Sent: Friday, January 5, 2007 2:40:56 PM
> Subject: Re: [Ips] Response Fence Flag
>
> Hi John,
>  
> As you correctly point out, there are two distinct but related
> topics here.
>  
> (1) proper response ordering across participating connections in a
> multi-connection session, for a handful of task/TMF responses
> (2) proper way to terminate and signal tasks when actions on one
> session can impact multiple initiators
>  
> (1) is all about response fence, it is covered separately in section
> 3.3 of IG draft.  That's what this email thread started off with.=
>  
> (2) covers cases that IG had called as as "multi-task abort" cases
> that typically have a shared task set across sessions, or are the
> result of a Logical Unit Reset TMF.  Section 4.1 of IG adresses (2).
>  
> So how are (1) and (2) related?
>  
> - Some cases covered under (2) overlap with (1), but some cases in (2)
> are for single connection sessions.  E.g. LU Reset on a single
> connection session impacting several 3rd party sessions
>  
> - Some cases under (1) overlap with (2), but some cases in (1) have
> nothing to do with other sessions.  E.g. establishment of ACA on a
> non-shared task set
>  
> - Section 4.1 (i.e. text for (2)) uses response fence (i.e. text for
> (1)) whenever multi-connection sessions are involved in multi-task
> abort situations.
>  
> I hope that clarifies it.  Feel free to ask if that is not clear.  The
> net is that the response fence is the underpinning notion to describe
> the correct iSCSI behavior in a few cases and some of those cases are
> about task terminations across third-party sessions.
>  
> Mallikarjun
>  
>
>
>  
> ----- Original Message ----
> From: John Hufferd <jhufferd@Brocade.COM>
> To: Mallikarjun C. <cb=5Fmallikarjun@yahoo.com>; ips@ietf.org
> Sent: Friday, January 5, 2007 1:01:06 PM
> Subject: RE: [Ips] Response Fence Flag
>
> Mallikarjun,
>
> I must admit, that I have been a bit confused with the direction of
> the conversation here.
>
>  
>
> Therefore, I went back and reviewed the charts from Dallas .  And as I
> remembered, the initial focus was to address the issue of Multiple
> Connections per Session (MC/S) (as stated on chart 4 – “No= n-issue for
> single-connection iSCSI sessions”).  So I think I have miss= ed the step
> where we have morphed the discussion into one dealing with multiple
> sessions.  (I am not sure how that happened, or if I miss-read the
> charts from Dallas , or have not followed the discussion adequately.)<= br> >
>  
>
> If we are attempting to define two different issues, one with MC/S and
> one with Multiple Session from different Initiators, I think it would
> be useful to break down the conversation into Topic A – MC/S and Topic
> B Multiple Sessions.  It is possible that one solution will addre= sses
> both, but I for one think I am hearing arguments that might be
> appropriate for Topic B, while I am thinking about its applicability
> to Topic A.
>
>  
>
> Perhaps, you could address the issue as either being all about MC/S or
> explicitly state that it is intended to affect Multiple Sessions also,
> and then address the issues and solution for each separately.  For
> example, I believe Robert was addressing the issue from a view of
> Multiple Sessions and if we only intended to address MC/S then I
> expect the response might be somewhat different.
>
>  
>
> Anyway, if you could clear-up some of this, I think it would be useful
> (at least to me).
>
>  
>
> .
>
> .
>
> .
>
> John L Hufferd
>
> Sr. Executive Director of Technology
>
> Brocade Communications Systems, Inc
>
> jhufferd@brocade.com <mailto:jhufferd@brocade.com>
>
> Office Phone: (408) 333-5244; eFAX: (408) 904-4688
>
> Alt Office Phone: (408) 997-6136; Cell: (408) 627-9606
>
>  
>
> ----------------------------------------------------------------------= --
>
> *From:* Mallikarjun C. [mailto:cb=5Fmallikarjun@yahoo.com]
> *Sent:* Friday, January 05, 2007 10:08 AM
> *To:* ips@ietf.org
> *Subject:* Re: [Ips] Response Fence Flag
>
>  
>
> Not really.  Current draft text is intentionally written to not have
> any dependencies on T10 dynamics.  The point is that iSCSI needs such
> a notion for succinctly describing the proper iSCSI protocol actions
> in a few places - ACA, TMF, Persistent reserve/Abort to name a few.  
> We certainly hope it will be approved by T10 and be a part of SAM-4
> soon, but that isn't required per se for describing what iSCSI needs
> for its correct behavior.
>
>  
>
> IPS WG has adopted what it needs in the past - staying ahead of T10
> review/approval cycle if necessary.  I=5FT nexus loss notificatio= n,
> iSCSI target/port naming, clearing effects are a few I recall.
>
>  
>
> Mallikarjun
>
>
>
>  
>
> ----- Original Message ----
> From: Eddy Quicksall <Quicksall=5FiSCSI@Bellsouth.net>
> To: Robert Snively <rsnively@Brocade.COM>; "Elliott, Robert (Server
> Storage)" <Elliott@hp.com>; ips@ietf.org
> Sent: Friday, January 5, 2007 8:58:47 AM
> Subject: Re: [Ips] Response Fence Flag
>
> From an earlier email I think that Response Fence is only a proposal
> in T10 (http://www.t10.org:80/doc06.htm
> <http://www.t10.org/doc06.htm>). If so shouldn't iSCSI wait a bit
> until this has been ratified?
>
>  
>
> Eddy
>
>
> =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F
> Do You Yahoo!?
> Tired of spam? Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
> ----------------------------------------------------------------------= --
>
> =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
> Ips mailing list
> Ips@ietf.org
> https://www1.ietf.org/mailman/listinfo/ips
>  

--=_alternative 004F68248525725B_=-- --===============1785682818== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============1785682818==-- From ips-bounces@ietf.org Sat Jan 06 12:27:36 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3FK9-0006Z0-Fv; Sat, 06 Jan 2007 12:27:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3FK7-0006Yn-Rz for ips@ietf.org; Sat, 06 Jan 2007 12:27:15 -0500 Received: from imf22aec.mail.bellsouth.net ([205.152.59.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H3FK2-0004lf-UD for ips@ietf.org; Sat, 06 Jan 2007 12:27:15 -0500 Received: from ibm65aec.bellsouth.net ([74.245.52.54]) by imf22aec.mail.bellsouth.net with ESMTP id <20070106172708.STNC28979.imf22aec.mail.bellsouth.net@ibm65aec.bellsouth.net> for ; Sat, 6 Jan 2007 12:27:08 -0500 Received: from IVVTDKV0981 ([74.245.52.54]) by ibm65aec.bellsouth.net with SMTP id <20070106172707.QMMF8392.ibm65aec.bellsouth.net@IVVTDKV0981>; Sat, 6 Jan 2007 12:27:07 -0500 Message-ID: <000d01c731b7$e3c0ad60$01faa8c0@ivivity.com> From: "Eddy Quicksall" To: , "Julian Satran" References: Subject: Re: [Ips] Response Fence Flag Date: Sat, 6 Jan 2007 12:25:11 -0500 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.3 (/) X-Scan-Signature: 27216fd639035830d9361a5ade4ff99c Cc: X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1819988584==" Errors-To: ips-bounces@ietf.org This is a multi-part message in MIME format. --===============1819988584== Content-Type: multipart/alternative; boundary="----=_NextPart_000_000A_01C7318D.B6104DA0" This is a multi-part message in MIME format. ------=_NextPart_000_000A_01C7318D.B6104DA0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable >>The way all the application handle cases when the start of some SCSI=20 >>command has to follow the end of a previous set of operations is to = just=20 >>wait for the end of the operations before issuing the "dependent = commands". This is not to object to your observation but wouldn't ordered tags were = used for the above purpose? Eddy ----- Original Message -----=20 From: Julian Satran=20 To: ips@ietf.org=20 Sent: Saturday, January 06, 2007 9:31 AM Subject: Fw: [Ips] Response Fence Flag ----- Forwarded by Julian Satran/Haifa/IBM on 06/01/07 09:27 -----=20 Julian Satran =20 06/01/07 09:22=20 To "Mallikarjun C." =20 cc IPS , Julian Satran/Haifa/IBM@IBMIL =20 Subject Re: Fw: [Ips] Response Fence Flag=20 =20 =20 Mallikarjun & All, As I pointed out in a private discussion with you I never considered = in=20 dept the response-fence (beyond what is needed for TM). It is a serious issue for any "transaction type" operations to storage = -=20 but the last interface that had all the pieces correctly aligned was = the=20 360 channel. SCSI had taken (traditionally) the positions that sequencing and=20 barriers are rarely needed and when needed applications should provide = them. And that is exactly what all of the relevant applications do (all=20 transaction monitors, databases etc.). The way all the application handle cases when the start of some SCSI=20 command has to follow the end of a previous set of operations is to = just=20 wait for the end of the operations before issuing the "dependent = commands". Is this solution optimal? As you probably observed already this = solution=20 implies that all the queues in the "stack" (at initiator, transport = and=20 target) get empty before the dependent commands can be issued and that = is bad for performance. Can fencing (bad name BTW because it is in widespread use for defect=20 isolation) improve this? Yes (by keeping the pipes full!) provided it = is=20 associated with rigorous exception handling and the later is a SCSI=20 issue (exceptions will require emptying the queues). With most=20 applications being distributed I doubt also that fencing for a single=20 I_T nexus is interesting and coordinating fencing and exception = handling=20 over several I_Ts is a complex exercise. And as transport alone brings no value to the whole issue - why = should=20 we go through the exercise of defining a solution before SCSI has=20 defined one and we are confident that it is good enough and has value? = Again I agree that we a mechanism for TM but a good enough mechanism = for=20 TM is already in and it gets now even better even without resorting to = a=20 generalized fencing/barrier support. Regards, Julo Mallikarjun C. wrote: > Trying again after bouncing (>50KB), tail is now clipped.... > > ----- Forwarded Message ---- > From: Mallikarjun C. > To: ips@ietf.org > Sent: Friday, January 5, 2007 2:40:56 PM > Subject: Re: [Ips] Response Fence Flag > > Hi John, > =20 > As you correctly point out, there are two distinct but related=20 > topics here. > =20 > (1) proper response ordering across participating connections in a=20 > multi-connection session, for a handful of task/TMF responses > (2) proper way to terminate and signal tasks when actions on one=20 > session can impact multiple initiators > =20 > (1) is all about response fence, it is covered separately in section = > 3.3 of IG draft. That's what this email thread started off with. > =20 > (2) covers cases that IG had called as as "multi-task abort" cases=20 > that typically have a shared task set across sessions, or are the=20 > result of a Logical Unit Reset TMF. Section 4.1 of IG adresses (2). > =20 > So how are (1) and (2) related? > =20 > - Some cases covered under (2) overlap with (1), but some cases in = (2)=20 > are for single connection sessions. E.g. LU Reset on a single=20 > connection session impacting several 3rd party sessions > =20 > - Some cases under (1) overlap with (2), but some cases in (1) have=20 > nothing to do with other sessions. E.g. establishment of ACA on a=20 > non-shared task set > =20 > - Section 4.1 (i.e. text for (2)) uses response fence (i.e. text for = > (1)) whenever multi-connection sessions are involved in multi-task=20 > abort situations. > =20 > I hope that clarifies it. Feel free to ask if that is not clear. = The=20 > net is that the response fence is the underpinning notion to = describe=20 > the correct iSCSI behavior in a few cases and some of those cases = are=20 > about task terminations across third-party sessions. > =20 > Mallikarjun > =20 > > > =20 > ----- Original Message ---- > From: John Hufferd > To: Mallikarjun C. ; ips@ietf.org > Sent: Friday, January 5, 2007 1:01:06 PM > Subject: RE: [Ips] Response Fence Flag > > Mallikarjun, > > I must admit, that I have been a bit confused with the direction of=20 > the conversation here. > > =20 > > Therefore, I went back and reviewed the charts from Dallas . And as = I=20 > remembered, the initial focus was to address the issue of Multiple=20 > Connections per Session (MC/S) (as stated on chart 4 - "Non-issue = for=20 > single-connection iSCSI sessions"). So I think I have missed the = step=20 > where we have morphed the discussion into one dealing with multiple=20 > sessions. (I am not sure how that happened, or if I miss-read the=20 > charts from Dallas , or have not followed the discussion = adequately.) > > =20 > > If we are attempting to define two different issues, one with MC/S = and=20 > one with Multiple Session from different Initiators, I think it = would=20 > be useful to break down the conversation into Topic A - MC/S and = Topic=20 > B Multiple Sessions. It is possible that one solution will = addresses=20 > both, but I for one think I am hearing arguments that might be=20 > appropriate for Topic B, while I am thinking about its applicability = > to Topic A. > > =20 > > Perhaps, you could address the issue as either being all about MC/S = or=20 > explicitly state that it is intended to affect Multiple Sessions = also,=20 > and then address the issues and solution for each separately. For=20 > example, I believe Robert was addressing the issue from a view of=20 > Multiple Sessions and if we only intended to address MC/S then I=20 > expect the response might be somewhat different. > > =20 > > Anyway, if you could clear-up some of this, I think it would be = useful=20 > (at least to me). > > =20 > > . > > . > > . > > John L Hufferd > > Sr. Executive Director of Technology > > Brocade Communications Systems, Inc > > jhufferd@brocade.com > > Office Phone: (408) 333-5244; eFAX: (408) 904-4688 > > Alt Office Phone: (408) 997-6136; Cell: (408) 627-9606 > > =20 > > = ------------------------------------------------------------------------ > > *From:* Mallikarjun C. [mailto:cb_mallikarjun@yahoo.com] > *Sent:* Friday, January 05, 2007 10:08 AM > *To:* ips@ietf.org > *Subject:* Re: [Ips] Response Fence Flag > > =20 > > Not really. Current draft text is intentionally written to not have = > any dependencies on T10 dynamics. The point is that iSCSI needs = such=20 > a notion for succinctly describing the proper iSCSI protocol actions = > in a few places - ACA, TMF, Persistent reserve/Abort to name a few. = > We certainly hope it will be approved by T10 and be a part of SAM-4=20 > soon, but that isn't required per se for describing what iSCSI needs = > for its correct behavior. > > =20 > > IPS WG has adopted what it needs in the past - staying ahead of T10=20 > review/approval cycle if necessary. I_T nexus loss notification,=20 > iSCSI target/port naming, clearing effects are a few I recall. > > =20 > > Mallikarjun > > > > =20 > > ----- Original Message ---- > From: Eddy Quicksall > To: Robert Snively ; "Elliott, Robert (Server=20 > Storage)" ; ips@ietf.org > Sent: Friday, January 5, 2007 8:58:47 AM > Subject: Re: [Ips] Response Fence Flag > > From an earlier email I think that Response Fence is only a proposal = > in T10 (http://www.t10.org:80/doc06.htm=20 > ). If so shouldn't iSCSI wait a bit=20 > until this has been ratified? > > =20 > > Eddy > > > __________________________________________________ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around > http://mail.yahoo.com > = ------------------------------------------------------------------------ > > _______________________________________________ > Ips mailing list > Ips@ietf.org > https://www1.ietf.org/mailman/listinfo/ips > =20 -------------------------------------------------------------------------= ----- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips ------=_NextPart_000_000A_01C7318D.B6104DA0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
>>The way all the = application=20 handle cases when the start of some SCSI
>>command has to = follow the=20 end of a previous set of operations is to just
>>wait for the = end of=20 the operations before issuing the "dependent = commands".
 
This is not to object to your observation but = wouldn't ordered=20 tags were used for the above purpose?
 
Eddy
----- Original Message -----
From:=20 Julian Satran
Sent: Saturday, January 06, = 2007 9:31=20 AM
Subject: Fw: [Ips] Response = Fence=20 Flag


----- Forwarded=20 by Julian Satran/Haifa/IBM on 06/01/07 09:27 -----
Julian = Satran <julian.satran@gmail.com>=20

06/01/07 09:22

To
"Mallikarjun C." <cb_mallikarjun@yahoo.com>= =20
cc
IPS <ips@ietf.org>, Julian = Satran/Haifa/IBM@IBMIL =
Subject
Re: Fw: [Ips] Response = Fence=20 Flag

=




Mallikarjun & All,

As I pointed out in a private = discussion=20 with you I never considered in
dept the response-fence (beyond = what is=20 needed for TM).
It is a serious issue for any "transaction type" = operations=20 to storage -
but the last interface that had all the pieces = correctly=20 aligned was the
360 channel.
SCSI had taken (traditionally) the = positions that sequencing and
barriers are rarely needed and when = needed=20 applications should provide them.
And that is exactly what all of = the=20 relevant applications do (all
transaction monitors, databases=20 etc.).

The way all the application handle cases when the start = of some=20 SCSI
command has to follow the end of a previous set of operations = is to=20 just
wait for the end of the operations before issuing the = "dependent=20 commands".

Is this solution optimal? As you probably observed = already=20 this solution
implies that all the queues in the "stack" (at = initiator,=20 transport and
target) get empty before the dependent commands can = be=20 issued and that
is bad for performance.

Can fencing (bad = name BTW=20 because it is in widespread use for defect
isolation) improve = this? Yes=20 (by keeping the pipes full!) provided it is
associated with = rigorous=20 exception handling and the later is a SCSI
issue (exceptions will = require=20 emptying the queues). With most
applications being distributed I = doubt=20 also that fencing for a single
I_T nexus is interesting and = coordinating=20 fencing and exception handling
over several I_Ts is a complex=20 exercise.

And as transport alone brings no value to the whole = issue -=20 why  should
we go through the exercise of defining a solution = before=20 SCSI has
defined one and we are confident that it is good enough = and has=20 value?
Again I agree that we a mechanism for TM but a good enough=20 mechanism for
TM is already in and it gets now even better even = without=20 resorting to a
generalized fencing/barrier=20 = support.

Regards,
Julo








Malli= karjun=20 C. wrote:
> Trying again after bouncing (>50KB), tail is now=20 clipped....
>
> ----- Forwarded Message ----
> From: = Mallikarjun C. <cb_mallikarjun@yahoo.com>
> To:=20 ips@ietf.org
> Sent: Friday, January 5, 2007 2:40:56 PM
> = Subject:=20 Re: [Ips] Response Fence Flag
>
> Hi John,
> =  
>=20 As you correctly point out, there are two distinct but related =
> topics=20 here.
>  
> (1) proper response ordering across = participating=20 connections in a
> multi-connection session, for a handful of = task/TMF=20 responses
> (2) proper way to terminate and signal tasks when = actions on=20 one
> session can impact multiple initiators
> =  
> (1)=20 is all about response fence, it is covered separately in section =
> 3.3=20 of IG draft.  That's what this email thread started off = with.
>=20  
> (2) covers cases that IG had called as as "multi-task = abort"=20 cases
> that typically have a shared task set across sessions, = or are=20 the
> result of a Logical Unit Reset TMF.  Section 4.1 of = IG=20 adresses (2).
>  
> So how are (1) and (2) = related?
>=20  
> - Some cases covered under (2) overlap with (1), but = some cases=20 in (2)
> are for single connection sessions.  E.g. LU = Reset on a=20 single
> connection session impacting several 3rd party=20 sessions
>  
> - Some cases under (1) overlap with = (2), but=20 some cases in (1) have
> nothing to do with other sessions. =  E.g.=20 establishment of ACA on a
> non-shared task set
> =  
>=20 - Section 4.1 (i.e. text for (2)) uses response fence (i.e. text for =
>=20 (1)) whenever multi-connection sessions are involved in multi-task =
>=20 abort situations.
>  
> I hope that clarifies it. =  Feel=20 free to ask if that is not clear.  The
> net is that the = response=20 fence is the underpinning notion to describe
> the correct = iSCSI=20 behavior in a few cases and some of those cases are
> about = task=20 terminations across third-party sessions.
>  
>=20 Mallikarjun
>  
>
>
>  
> = -----=20 Original Message ----
> From: John Hufferd=20 <jhufferd@Brocade.COM>
> To: Mallikarjun C.=20 <cb_mallikarjun@yahoo.com>; ips@ietf.org
> Sent: Friday, = January=20 5, 2007 1:01:06 PM
> Subject: RE: [Ips] Response Fence=20 Flag
>
> Mallikarjun,
>
> I must admit, that I = have=20 been a bit confused with the direction of
> the conversation=20 here.
>
>  
>
> Therefore, I went back = and=20 reviewed the charts from Dallas .  And as I
> remembered, = the=20 initial focus was to address the issue of Multiple
> = Connections per=20 Session (MC/S) (as stated on chart 4 =96 =93Non-issue for
>=20 single-connection iSCSI sessions=94).  So I think I have missed = the step=20
> where we have morphed the discussion into one dealing with = multiple=20
> sessions.  (I am not sure how that happened, or if I = miss-read=20 the
> charts from Dallas , or have not followed the discussion=20 adequately.)
>
>  
>
> If we are = attempting to=20 define two different issues, one with MC/S and
> one with = Multiple=20 Session from different Initiators, I think it would
> be useful = to=20 break down the conversation into Topic A =96 MC/S and Topic
> B = Multiple=20 Sessions.  It is possible that one solution will addresses =
> both,=20 but I for one think I am hearing arguments that might be
> = appropriate=20 for Topic B, while I am thinking about its applicability
> to = Topic=20 A.
>
>  
>
> Perhaps, you could address = the issue=20 as either being all about MC/S or
> explicitly state that it is = intended to affect Multiple Sessions also,
> and then address = the=20 issues and solution for each separately.  For
> example, I = believe=20 Robert was addressing the issue from a view of
> Multiple = Sessions and=20 if we only intended to address MC/S then I
> expect the = response might=20 be somewhat different.
>
>  
>
> Anyway, = if you=20 could clear-up some of this, I think it would be useful
> (at = least to=20 me).
>
>  
>
> .
>
>=20 .
>
> .
>
> John L Hufferd
>
> Sr. = Executive Director of Technology
>
> Brocade = Communications=20 Systems, Inc
>
> jhufferd@brocade.com=20 <mailto:jhufferd@brocade.com>
>
> Office Phone: = (408)=20 333-5244; eFAX: (408) 904-4688
>
> Alt Office Phone: (408) = 997-6136; Cell: (408) 627-9606
>
>  
>
>=20 = ------------------------------------------------------------------------<= BR>>
>=20 *From:* Mallikarjun C. [mailto:cb_mallikarjun@yahoo.com]
> = *Sent:*=20 Friday, January 05, 2007 10:08 AM
> *To:* ips@ietf.org
>=20 *Subject:* Re: [Ips] Response Fence Flag
>
>=20  
>
> Not really.  Current draft text is = intentionally=20 written to not have
> any dependencies on T10 dynamics. =  The point=20 is that iSCSI needs such
> a notion for succinctly describing = the=20 proper iSCSI protocol actions
> in a few places - ACA, TMF, = Persistent=20 reserve/Abort to name a few.  
> We certainly hope it will = be=20 approved by T10 and be a part of SAM-4
> soon, but that isn't = required=20 per se for describing what iSCSI needs
> for its correct=20 behavior.
>
>  
>
> IPS WG has adopted = what it=20 needs in the past - staying ahead of T10
> review/approval = cycle if=20 necessary.  I_T nexus loss notification,
> iSCSI = target/port=20 naming, clearing effects are a few I recall.
>
>=20  
>
> Mallikarjun
>
>
>
>=20  
>
> ----- Original Message ----
> From: Eddy=20 Quicksall <Quicksall_iSCSI@Bellsouth.net>
> To: Robert = Snively=20 <rsnively@Brocade.COM>; "Elliott, Robert (Server
> = Storage)"=20 <Elliott@hp.com>; ips@ietf.org
> Sent: Friday, January 5, = 2007=20 8:58:47 AM
> Subject: Re: [Ips] Response Fence = Flag
>
> From=20 an earlier email I think that Response Fence is only a proposal =
> in=20 T10 (http://www.t10.org:80/doc06.htm
>=20 <http://www.t10.org/doc06.htm>). If so shouldn't iSCSI wait a = bit=20
> until this has been ratified?
>
> =  
>
>=20 Eddy
>
>
>=20 __________________________________________________
> Do You=20 Yahoo!?
> Tired of spam? Yahoo! Mail has the best spam = protection=20 around
> http://mail.yahoo.com
>=20 = ------------------------------------------------------------------------<= BR>>
>=20 _______________________________________________
> Ips mailing=20 list
> Ips@ietf.org
>=20 https://www1.ietf.org/mailman/listinfo/ips
>   =

_______________________________________________
Ips mailing=20 = list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips
------=_NextPart_000_000A_01C7318D.B6104DA0-- --===============1819988584== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============1819988584==-- From tyebridger@znakomstva.co.uk Sat Jan 06 13:07:50 2007 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3FxO-0003HL-Q8 for ips-archive@lists.ietf.org; Sat, 06 Jan 2007 13:07:50 -0500 Received: from [220.73.120.31] (helo=znakomstva.co.uk) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H3FxN-0000DN-7r for ips-archive@lists.ietf.org; Sat, 06 Jan 2007 13:07:50 -0500 Message-ID: <686301c731ff$3ff1a110$300138d7@tyebridger> From: "KAREN" To: "LOLA" Subject: Kyle Get rid of everything you owe not even paying another dime Date: Sun, 07 Jan 2007 01:57:56 +0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1158 X-Spam-Score: 2.5 (++) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Visualize the New Year with no CardDebt and without paying back an additional dime. Contact us at: 561-282-9476 information or to finish receiving or to read postal Dorothy sighed and commenced to breathe easier. The latter had scattered throughout the town, thinking themselves perfectly secure, so that not only were they unprepared to fight, but they became panic-stricken at seeing their foes return, as it seemed, from death to life She began to realize that death was not in store for her, after all, but that she had merely started upon another adventure, which promised to be just as queer and unusual as were those she had before encountered. Their usual courage forsook them, and they ran, terrified, in every direction, only to be cut down by the revengeful Turkish simitars From ips-bounces@ietf.org Sat Jan 06 15:58:19 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3Ibz-0004F7-NN; Sat, 06 Jan 2007 15:57:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3Iby-0004F2-8H for ips@ietf.org; Sat, 06 Jan 2007 15:57:54 -0500 Received: from mtagate2.de.ibm.com ([195.212.29.151]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H3Ibt-0003My-TI for ips@ietf.org; Sat, 06 Jan 2007 15:57:54 -0500 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate2.de.ibm.com (8.13.8/8.13.8) with ESMTP id l06KvkUw017190 for ; Sat, 6 Jan 2007 20:57:46 GMT Received: from d12av02.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1607.megacenter.de.ibm.com (8.13.6/8.13.6/NCO v8.1.1) with ESMTP id l06Kvkow3170372 for ; Sat, 6 Jan 2007 21:57:46 +0100 Received: from d12av02.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l06KvkZq021590 for ; Sat, 6 Jan 2007 21:57:46 +0100 Received: from d12mc102.megacenter.de.ibm.com (d12mc102.megacenter.de.ibm.com [9.149.167.114]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l06KvkNA021587; Sat, 6 Jan 2007 21:57:46 +0100 MIME-Version: 1.0 In-Reply-To: <000d01c731b7$e3c0ad60$01faa8c0@ivivity.com> To: "Eddy Quicksall" Subject: Re: [Ips] Response Fence Flag X-Mailer: Lotus Notes Release 7.0.2 September 26, 2006 From: Julian Satran Message-ID: Date: Sat, 6 Jan 2007 15:57:44 -0500 X-MIMETrack: Serialize by Router on D12MC102/12/M/IBM(Release 7.0.2HF71 | November 3, 2006) at 06/01/2007 22:57:46, Serialize complete at 06/01/2007 22:57:46 X-Spam-Score: 0.1 (/) X-Scan-Signature: a8403cbbf1773e27474a13192645c46f Cc: ips@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0148260504==" Errors-To: ips-bounces@ietf.org This is a multipart message in MIME format. --===============0148260504== Content-Type: multipart/alternative; boundary="=_alternative 0073233F8525725B_=" This is a multipart message in MIME format. --=_alternative 0073233F8525725B_= Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Very good point. Indeed ordered tag insure similar properties with two=20 caveats: the ordering in ordered tags is ill-defined. It talks about received=20 before tasks (i.e., from a targets POV). The inititiator however has no=20 way of controlling this ordering. In iSCSI we tried to fix this with CmdSN = but to act properly you will have to assume a "serializing" interface=20 from SCSI to iSCSI (which I am not sure iSCSI can enforce. applications may not be interested in the execution order of every command = just in the order at barier points. Ordered tags are ill suited for that. SCSI folks may want to pitch in as I have only second-guessed them and may = be wrong. Julo "Eddy Quicksall" =20 06/01/07 12:25 To , Julian Satran/Haifa/IBM@IBMIL cc Subject Re: [Ips] Response Fence Flag >>The way all the application handle cases when the start of some SCSI=20 >>command has to follow the end of a previous set of operations is to just = >>wait for the end of the operations before issuing the "dependent=20 commands". =20 This is not to object to your observation but wouldn't ordered tags were=20 used for the above purpose? =20 Eddy ----- Original Message -----=20 From: Julian Satran=20 To: ips@ietf.org=20 Sent: Saturday, January 06, 2007 9:31 AM Subject: Fw: [Ips] Response Fence Flag ----- Forwarded by Julian Satran/Haifa/IBM on 06/01/07 09:27 -----=20 Julian Satran =20 06/01/07 09:22=20 To "Mallikarjun C." =20 cc IPS , Julian Satran/Haifa/IBM@IBMIL=20 Subject Re: Fw: [Ips] Response Fence Flag Mallikarjun & All, As I pointed out in a private discussion with you I never considered in=20 dept the response-fence (beyond what is needed for TM). It is a serious issue for any "transaction type" operations to storage -=20 but the last interface that had all the pieces correctly aligned was the=20 360 channel. SCSI had taken (traditionally) the positions that sequencing and=20 barriers are rarely needed and when needed applications should provide=20 them. And that is exactly what all of the relevant applications do (all=20 transaction monitors, databases etc.). The way all the application handle cases when the start of some SCSI=20 command has to follow the end of a previous set of operations is to just=20 wait for the end of the operations before issuing the "dependent=20 commands". Is this solution optimal? As you probably observed already this solution=20 implies that all the queues in the "stack" (at initiator, transport and=20 target) get empty before the dependent commands can be issued and that=20 is bad for performance. Can fencing (bad name BTW because it is in widespread use for defect=20 isolation) improve this? Yes (by keeping the pipes full!) provided it is=20 associated with rigorous exception handling and the later is a SCSI=20 issue (exceptions will require emptying the queues). With most=20 applications being distributed I doubt also that fencing for a single=20 I=5FT nexus is interesting and coordinating fencing and exception handling = over several I=5FTs is a complex exercise. And as transport alone brings no value to the whole issue - why should=20 we go through the exercise of defining a solution before SCSI has=20 defined one and we are confident that it is good enough and has value?=20 Again I agree that we a mechanism for TM but a good enough mechanism for=20 TM is already in and it gets now even better even without resorting to a=20 generalized fencing/barrier support. Regards, Julo Mallikarjun C. wrote: > Trying again after bouncing (>50KB), tail is now clipped.... > > ----- Forwarded Message ---- > From: Mallikarjun C. > To: ips@ietf.org > Sent: Friday, January 5, 2007 2:40:56 PM > Subject: Re: [Ips] Response Fence Flag > > Hi John, >=20 > As you correctly point out, there are two distinct but related=20 > topics here. >=20 > (1) proper response ordering across participating connections in a=20 > multi-connection session, for a handful of task/TMF responses > (2) proper way to terminate and signal tasks when actions on one=20 > session can impact multiple initiators >=20 > (1) is all about response fence, it is covered separately in section=20 > 3.3 of IG draft. That's what this email thread started off with. >=20 > (2) covers cases that IG had called as as "multi-task abort" cases=20 > that typically have a shared task set across sessions, or are the=20 > result of a Logical Unit Reset TMF. Section 4.1 of IG adresses (2). >=20 > So how are (1) and (2) related? >=20 > - Some cases covered under (2) overlap with (1), but some cases in (2)=20 > are for single connection sessions. E.g. LU Reset on a single=20 > connection session impacting several 3rd party sessions >=20 > - Some cases under (1) overlap with (2), but some cases in (1) have=20 > nothing to do with other sessions. E.g. establishment of ACA on a=20 > non-shared task set >=20 > - Section 4.1 (i.e. text for (2)) uses response fence (i.e. text for=20 > (1)) whenever multi-connection sessions are involved in multi-task=20 > abort situations. >=20 > I hope that clarifies it. Feel free to ask if that is not clear. The=20 > net is that the response fence is the underpinning notion to describe=20 > the correct iSCSI behavior in a few cases and some of those cases are=20 > about task terminations across third-party sessions. >=20 > Mallikarjun >=20 > > >=20 > ----- Original Message ---- > From: John Hufferd > To: Mallikarjun C. ; ips@ietf.org > Sent: Friday, January 5, 2007 1:01:06 PM > Subject: RE: [Ips] Response Fence Flag > > Mallikarjun, > > I must admit, that I have been a bit confused with the direction of=20 > the conversation here. > >=20 > > Therefore, I went back and reviewed the charts from Dallas . And as I=20 > remembered, the initial focus was to address the issue of Multiple=20 > Connections per Session (MC/S) (as stated on chart 4 ? ?Non-issue for=20 > single-connection iSCSI sessions?). So I think I have missed the step=20 > where we have morphed the discussion into one dealing with multiple=20 > sessions. (I am not sure how that happened, or if I miss-read the=20 > charts from Dallas , or have not followed the discussion adequately.) > >=20 > > If we are attempting to define two different issues, one with MC/S and=20 > one with Multiple Session from different Initiators, I think it would=20 > be useful to break down the conversation into Topic A ? MC/S and Topic=20 > B Multiple Sessions. It is possible that one solution will addresses=20 > both, but I for one think I am hearing arguments that might be=20 > appropriate for Topic B, while I am thinking about its applicability=20 > to Topic A. > >=20 > > Perhaps, you could address the issue as either being all about MC/S or=20 > explicitly state that it is intended to affect Multiple Sessions also,=20 > and then address the issues and solution for each separately. For=20 > example, I believe Robert was addressing the issue from a view of=20 > Multiple Sessions and if we only intended to address MC/S then I=20 > expect the response might be somewhat different. > >=20 > > Anyway, if you could clear-up some of this, I think it would be useful=20 > (at least to me). > >=20 > > . > > . > > . > > John L Hufferd > > Sr. Executive Director of Technology > > Brocade Communications Systems, Inc > > jhufferd@brocade.com > > Office Phone: (408) 333-5244; eFAX: (408) 904-4688 > > Alt Office Phone: (408) 997-6136; Cell: (408) 627-9606 > >=20 > > ------------------------------------------------------------------------ > > *From:* Mallikarjun C. [mailto:cb=5Fmallikarjun@yahoo.com] > *Sent:* Friday, January 05, 2007 10:08 AM > *To:* ips@ietf.org > *Subject:* Re: [Ips] Response Fence Flag > >=20 > > Not really. Current draft text is intentionally written to not have=20 > any dependencies on T10 dynamics. The point is that iSCSI needs such=20 > a notion for succinctly describing the proper iSCSI protocol actions=20 > in a few places - ACA, TMF, Persistent reserve/Abort to name a few.=20 > We certainly hope it will be approved by T10 and be a part of SAM-4=20 > soon, but that isn't required per se for describing what iSCSI needs=20 > for its correct behavior. > >=20 > > IPS WG has adopted what it needs in the past - staying ahead of T10=20 > review/approval cycle if necessary. I=5FT nexus loss notification,=20 > iSCSI target/port naming, clearing effects are a few I recall. > >=20 > > Mallikarjun > > > >=20 > > ----- Original Message ---- > From: Eddy Quicksall > To: Robert Snively ; "Elliott, Robert (Server=20 > Storage)" ; ips@ietf.org > Sent: Friday, January 5, 2007 8:58:47 AM > Subject: Re: [Ips] Response Fence Flag > > From an earlier email I think that Response Fence is only a proposal=20 > in T10 (http://www.t10.org:80/doc06.htm=20 > ). If so shouldn't iSCSI wait a bit=20 > until this has been ratified? > >=20 > > Eddy > > > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around > http://mail.yahoo.com > ------------------------------------------------------------------------ > > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F > Ips mailing list > Ips@ietf.org > https://www1.ietf.org/mailman/listinfo/ips >=20 =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --=_alternative 0073233F8525725B_= Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable
Very good point. Indeed ordered tag insure similar properties with two caveats:
  • the ordering in ordered tags is ill-= defined. It talks about received before tasks (i.e., from a targets POV). The initit= iator however has no way of controlling this ordering. In iSCSI we tried to fix this with CmdSN but to act properly you will have to  assume a "s= erializing" interface from SCSI to iSCSI (which I am not sure iSCSI can enforce.
  • applications may not be interested in the execution order of every command just in the order at barier points. Ordered tags are ill suited for that.


SCSI folks may want to pitch in as I have only second-guessed them and may be wrong.

Julo


"Eddy Quicksall&= quot; <Quicksall=5FiSCSI@Bellsouth.net>

06/01/07 12:25

To
<ips@ietf.org>, Julian Satran/= Haifa/IBM@IBMIL
cc
Subject
Re: [Ips] Response Fence Flag=





>>The way all the application handle cases when the start of some SCSI
>>command has to follow the end of a previous set of operations is to just
>>wait for the end of the operations before issuing the "depende= nt commands".
 
This is not to object to your observation but wouldn't ordered tags were used for the above purpose?
 
Eddy
----- Original Message -----
From: Julian Satran
To: ips@ietf.org
Sent: Saturday, January 06, 2007 9:31 AM
Subject: Fw: [Ips] Response Fence Flag


----- Forwarded by Julian Satran/Haifa/IBM on 06/01/07 09:27 -----
Julian Satran <julian.satran@gmail.com>

06/01/07 09:22 =


To
"Mallikarjun C.&quo= t; <cb=5Fmallikarjun@yahoo.com>
cc
IPS <ips@ietf.org>, Julian Satran/Haifa/IBM@IBMIL
Subject
Re: Fw: [Ips] Response Fence Flag







Mallikarjun & All,

As I pointed out in a private discussion with you I never considered in
dept the response-fence (beyond what is needed for TM).
It is a serious issue for any "transaction type" operations to storage -
but the last interface that had all the pieces correctly aligned was the
360 channel.
SCSI had taken (traditionally) the positions that sequencing and
barriers are rarely needed and when needed applications should provide them.
And that is exactly what all of the relevant applications do (all
transaction monitors, databases etc.).

The way all the application handle cases when the start of some SCSI
command has to follow the end of a previous set of operations is to just
wait for the end of the operations before issuing the "dependent comma= nds".

Is this solution optimal? As you probably observed already this solution
implies that all the queues in the "stack" (at initiator, transpo= rt and
target) get empty before the dependent commands can be issued and that
is bad for performance.

Can fencing (bad name BTW because it is in widespread use for defect
isolation) improve this? Yes (by keeping the pipes full!) provided it is
associated with rigorous exception handling and the later is a SCSI
issue (exceptions will require emptying the queues). With most
applications being distributed I doubt also that fencing for a single
I=5FT nexus is interesting and coordinating fencing and exception handling
over several I=5FTs is a complex exercise.

And as transport alone brings no value to the whole issue - why  should
we go through the exercise of defining a solution before SCSI has
defined one and we are confident that it is good enough and has value?
Again I agree that we a mechanism for TM but a good enough mechanism for
TM is already in and it gets now even better even without resorting to a
generalized fencing/barrier support.

Regards,
Julo








Mallikarjun C. wrote:
> Trying again after bouncing (>50KB), tail is now clipped....
>
> ----- Forwarded Message ----
> From: Mallikarjun C. <cb=5Fmallikarjun@yahoo.com>
> To: ips@ietf.org
> Sent: Friday, January 5, 2007 2:40:56 PM
> Subject: Re: [Ips] Response Fence Flag
>
> Hi John,
>  
> As you correctly point out, there are two distinct but related
> topics here.
>  
> (1) proper response ordering across participating connections in a
> multi-connection session, for a handful of task/TMF responses
> (2) proper way to terminate and signal tasks when actions on one
> session can impact multiple initiators
>  
> (1) is all about response fence, it is covered separately in section
> 3.3 of IG draft.  That's what this email thread started off with.=
>  
> (2) covers cases that IG had called as as "multi-task abort" cases
> that typically have a shared task set across sessions, or are the
> result of a Logical Unit Reset TMF.  Section 4.1 of IG adresses (2).
>  
> So how are (1) and (2) related?
>  
> - Some cases covered under (2) overlap with (1), but some cases in (2)
> are for single connection sessions.  E.g. LU Reset on a single
> connection session impacting several 3rd party sessions
>  
> - Some cases under (1) overlap with (2), but some cases in (1) have
> nothing to do with other sessions.  E.g. establishment of ACA on a
> non-shared task set
>  
> - Section 4.1 (i.e. text for (2)) uses response fence (i.e. text for
> (1)) whenever multi-connection sessions are involved in multi-task
> abort situations.
>  
> I hope that clarifies it.  Feel free to ask if that is not clear.  The
> net is that the response fence is the underpinning notion to describe
> the correct iSCSI behavior in a few cases and some of those cases are
> about task terminations across third-party sessions.
>  
> Mallikarjun
>  
>
>
>  
> ----- Original Message ----
> From: John Hufferd <jhufferd@Brocade.COM>
> To: Mallikarjun C. <cb=5Fmallikarjun@yahoo.com>; ips@ietf.org
> Sent: Friday, January 5, 2007 1:01:06 PM
> Subject: RE: [Ips] Response Fence Flag
>
> Mallikarjun,
>
> I must admit, that I have been a bit confused with the direction of
> the conversation here.
>
>  
>
> Therefore, I went back and reviewed the charts from Dallas .  And as I
> remembered, the initial focus was to address the issue of Multiple
> Connections per Session (MC/S) (as stated on chart 4 – “No= n-issue for
> single-connection iSCSI sessions”).  So I think I have miss= ed the step
> where we have morphed the discussion into one dealing with multiple
> sessions.  (I am not sure how that happened, or if I miss-read the
> charts from Dallas , or have not followed the discussion adequately.)<= br> >
>  
>
> If we are attempting to define two different issues, one with MC/S and
> one with Multiple Session from different Initiators, I think it would
> be useful to break down the conversation into Topic A – MC/S and Topic
> B Multiple Sessions.  It is possible that one solution will addre= sses
> both, but I for one think I am hearing arguments that might be
> appropriate for Topic B, while I am thinking about its applicability
> to Topic A.
>
>  
>
> Perhaps, you could address the issue as either being all about MC/S or
> explicitly state that it is intended to affect Multiple Sessions also,
> and then address the issues and solution for each separately.  For
> example, I believe Robert was addressing the issue from a view of
> Multiple Sessions and if we only intended to address MC/S then I
> expect the response might be somewhat different.
>
>  
>
> Anyway, if you could clear-up some of this, I think it would be useful
> (at least to me).
>
>  
>
> .
>
> .
>
> .
>
> John L Hufferd
>
> Sr. Executive Director of Technology
>
> Brocade Communications Systems, Inc
>
> jhufferd@brocade.com <mailto:jhufferd@brocade.com>
>
> Office Phone: (408) 333-5244; eFAX: (408) 904-4688
>
> Alt Office Phone: (408) 997-6136; Cell: (408) 627-9606
>
>  
>
> ----------------------------------------------------------------------= --
>
> *From:* Mallikarjun C. [mailto:cb=5Fmallikarjun@yahoo.com]
> *Sent:* Friday, January 05, 2007 10:08 AM
> *To:* ips@ietf.org
> *Subject:* Re: [Ips] Response Fence Flag
>
>  
>
> Not really.  Current draft text is intentionally written to not have
> any dependencies on T10 dynamics.  The point is that iSCSI needs such
> a notion for succinctly describing the proper iSCSI protocol actions
> in a few places - ACA, TMF, Persistent reserve/Abort to name a few.  
> We certainly hope it will be approved by T10 and be a part of SAM-4
> soon, but that isn't required per se for describing what iSCSI needs
> for its correct behavior.
>
>  
>
> IPS WG has adopted what it needs in the past - staying ahead of T10
> review/approval cycle if necessary.  I=5FT nexus loss notificatio= n,
> iSCSI target/port naming, clearing effects are a few I recall.
>
>  
>
> Mallikarjun
>
>
>
>  
>
> ----- Original Message ----
> From: Eddy Quicksall <Quicksall=5FiSCSI@Bellsouth.net>
> To: Robert Snively <rsnively@Brocade.COM>; "Elliott, Robert (Server
> Storage)" <Elliott@hp.com>; ips@ietf.org
> Sent: Friday, January 5, 2007 8:58:47 AM
> Subject: Re: [Ips] Response Fence Flag
>
> From an earlier email I think that Response Fence is only a proposal
> in T10 (http://www.t10.org:80/doc06.htm
> <http://www.t10.org/doc06.htm>). If so shouldn't iSCSI wait a bit
> until this has been ratified?
>
>  
>
> Eddy
>
>
> =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F
> Do You Yahoo!?
> Tired of spam? Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
> ----------------------------------------------------------------------= --
>
> =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
> Ips mailing list
> Ips@ietf.org
> https://www1.ietf.org/mailman/listinfo/ips
>  

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

--=_alternative 0073233F8525725B_=-- --===============0148260504== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============0148260504==-- From ips-bounces@ietf.org Sat Jan 06 18:02:06 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3KXh-0002iJ-Q6; Sat, 06 Jan 2007 18:01:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3KXg-0002iB-MM for ips@ietf.org; Sat, 06 Jan 2007 18:01:36 -0500 Received: from web51907.mail.yahoo.com ([206.190.48.70]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H3KXc-0000Xh-Fp for ips@ietf.org; Sat, 06 Jan 2007 18:01:36 -0500 Received: (qmail 19863 invoked by uid 60001); 6 Jan 2007 22:54:49 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=zbxhZgbxE/3A0mn64MjuWMpyUO+uLbhwIZ9satfFWpcJFRt6tPqwNW2ooKBwU2AS3wjstFlsPGvEm8KXe88X6ApsCyKa+rKl1/mRAQA8hqIMoX0rWTgVkwH3TQieZc/Q/kSM4RRJunIiDYxedfiIktek4P7KXKMXc0lacsB/0ww= ; Message-ID: <20070106225449.19861.qmail@web51907.mail.yahoo.com> Received: from [15.246.143.45] by web51907.mail.yahoo.com via HTTP; Sat, 06 Jan 2007 14:54:49 PST Date: Sat, 6 Jan 2007 14:54:49 -0800 (PST) From: "Mallikarjun C." Subject: Re: Fw: [Ips] Response Fence Flag To: IPS MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ips-bounces@ietf.org Julian,=0A=0AI am surprised that you have not referred to the SCSI task att= ributes in the command ordering discussion. In any case, in the interest o= f staying on the response fence topic, I will not respond to the command or= dering points you made (debate topics for some other time, :-)).=0A=0AThe w= hole notion of response fence though is all about ordering responses, where= such ordering is needed (only a very small % of responses, which are liste= d in section 3.3.3 of IG draft as we know them today). The updated draft, = which I will forward for publication today, lists one additional case - tha= t of Persistent Reserve/Abort Tasks.=0A=0AI am not sure of your intended co= ntext of how SCSI-level rigorous exception handling relates to response fen= ce.=0A=0AAnd yes, response fence is not for cross-session collaboration, it= is in fact limited to a single I_T_L nexus (please refer to section 3.3 of= implementer's guide).=0A=0ARegarding why iSCSI should define it, because i= t is required for succinctly describing iSCSI protocol behavior in multi-ch= annel I_T nexus situations (iSCSI and SAS, as we know them today). As ment= ioned to Eddy yesterday, it (or a concept like it with any other name - thi= s concept is in section 10.6.2 of RFC 3720 as well even though we didn't ca= ll it such) is required for iSCSI's proper behavior.=0A=0AThanks.=0A=0AMall= ikarjun =0A=0A=0A----- Original Message ----=0AFrom: Julian Satran =0ATo: Mallikarjun C. =0ACc: IPS= ; Julian_Satran@il.ibm.com=0ASent: Saturday, January 6, 2007= 6:22:52 AM=0ASubject: Re: Fw: [Ips] Response Fence Flag=0A=0AMallikarjun &= All,=0A=0AAs I pointed out in a private discussion with you I never consid= ered in =0Adept the response-fence (beyond what is needed for TM).=0AIt is = a serious issue for any "transaction type" operations to storage - =0Abut t= he last interface that had all the pieces correctly aligned was the =0A360 = channel.=0ASCSI had taken (traditionally) the positions that sequencing and= =0Abarriers are rarely needed and when needed applications should provide = them.=0AAnd that is exactly what all of the relevant applications do (all = =0Atransaction monitors, databases etc.).=0A=0AThe way all the application = handle cases when the start of some SCSI =0Acommand has to follow the end o= f a previous set of operations is to just =0Await for the end of the operat= ions before issuing the "dependent commands".=0A=0AIs this solution optimal= ? As you probably observed already this solution =0Aimplies that all the qu= eues in the "stack" (at initiator, transport and =0Atarget) get empty befor= e the dependent commands can be issued and that =0Ais bad for performance.= =0A=0ACan fencing (bad name BTW because it is in widespread use for defect = =0Aisolation) improve this? Yes (by keeping the pipes full!) provided it is= =0Aassociated with rigorous exception handling and the later is a SCSI =0A= issue (exceptions will require emptying the queues). With most =0Aapplicati= ons being distributed I doubt also that fencing for a single =0AI_T nexus i= s interesting and coordinating fencing and exception handling =0Aover sever= al I_Ts is a complex exercise.=0A=0AAnd as transport alone brings no value = to the whole issue - why should =0Awe go through the exercise of defining = a solution before SCSI has =0Adefined one and we are confident that it is g= ood enough and has value? =0AAgain I agree that we a mechanism for TM but a= good enough mechanism for =0ATM is already in and it gets now even better = even without resorting to a =0Ageneralized fencing/barrier support.=0A=0ARe= gards,=0AJulo=0A=0A=0A=0A=0A=0A=0A=0A=0AMallikarjun C. wrote:=0A> Trying ag= ain after bouncing (>50KB), tail is now clipped....=0A>=0A> ----- Forwarded= Message ----=0A> From: Mallikarjun C. =0A> To: i= ps@ietf.org=0A> Sent: Friday, January 5, 2007 2:40:56 PM=0A> Subject: Re: [= Ips] Response Fence Flag=0A>=0A> Hi John,=0A> =0A> As you correctly point = out, there are two distinct but related =0A> topics here.=0A> =0A> (1) pro= per response ordering across participating connections in a =0A> multi-conn= ection session, for a handful of task/TMF responses=0A> (2) proper way to t= erminate and signal tasks when actions on one =0A> session can impact multi= ple initiators=0A> =0A> (1) is all about response fence, it is covered sep= arately in section =0A> 3.3 of IG draft. That's what this email thread sta= rted off with.=0A> =0A> (2) covers cases that IG had called as as "multi-t= ask abort" cases =0A> that typically have a shared task set across sessions= , or are the =0A> result of a Logical Unit Reset TMF. Section 4.1 of IG ad= resses (2).=0A> =0A> So how are (1) and (2) related?=0A> =0A> - Some case= s covered under (2) overlap with (1), but some cases in (2) =0A> are for si= ngle connection sessions. E.g. LU Reset on a single =0A> connection sessio= n impacting several 3rd party sessions=0A> =0A> - Some cases under (1) ove= rlap with (2), but some cases in (1) have =0A> nothing to do with other ses= sions. E.g. establishment of ACA on a =0A> non-shared task set=0A> =0A> -= Section 4.1 (i.e. text for (2)) uses response fence (i.e. text for =0A> (1= )) whenever multi-connection sessions are involved in multi-task =0A> abort= situations.=0A> =0A> I hope that clarifies it. Feel free to ask if that = is not clear. The =0A> net is that the response fence is the underpinning = notion to describe =0A> the correct iSCSI behavior in a few cases and some = of those cases are =0A> about task terminations across third-party sessions= .=0A> =0A> Mallikarjun=0A> =0A>=0A>=0A> =0A> ----- Original Message ----= =0A> From: John Hufferd =0A> To: Mallikarjun C. ; ips@ietf.org=0A> Sent: Friday, January 5, 2007 1:01:= 06 PM=0A> Subject: RE: [Ips] Response Fence Flag=0A>=0A> Mallikarjun,=0A>= =0A> I must admit, that I have been a bit confused with the direction of = =0A> the conversation here.=0A>=0A> =0A>=0A> Therefore, I went back and re= viewed the charts from Dallas . And as I =0A> remembered, the initial focu= s was to address the issue of Multiple =0A> Connections per Session (MC/S) = (as stated on chart 4 =96 =93Non-issue for =0A> single-connection iSCSI ses= sions=94). So I think I have missed the step =0A> where we have morphed th= e discussion into one dealing with multiple =0A> sessions. (I am not sure = how that happened, or if I miss-read the =0A> charts from Dallas , or have = not followed the discussion adequately.)=0A>=0A> =0A>=0A> If we are attemp= ting to define two different issues, one with MC/S and =0A> one with Multip= le Session from different Initiators, I think it would =0A> be useful to br= eak down the conversation into Topic A =96 MC/S and Topic =0A> B Multiple S= essions. It is possible that one solution will addresses =0A> both, but I = for one think I am hearing arguments that might be =0A> appropriate for Top= ic B, while I am thinking about its applicability =0A> to Topic A.=0A>=0A> = =0A>=0A> Perhaps, you could address the issue as either being all about MC= /S or =0A> explicitly state that it is intended to affect Multiple Sessions= also, =0A> and then address the issues and solution for each separately. = For =0A> example, I believe Robert was addressing the issue from a view of = =0A> Multiple Sessions and if we only intended to address MC/S then I =0A> = expect the response might be somewhat different.=0A>=0A> =0A>=0A> Anyway, = if you could clear-up some of this, I think it would be useful =0A> (at lea= st to me).=0A>=0A> =0A>=0A> .=0A>=0A> .=0A>=0A> .=0A>=0A> John L Hufferd= =0A>=0A> Sr. Executive Director of Technology=0A>=0A> Brocade Communication= s Systems, Inc=0A>=0A> jhufferd@brocade.com = =0A>=0A> Office Phone: (408) 333-5244; eFAX: (408) 904-4688=0A>=0A> Alt Off= ice Phone: (408) 997-6136; Cell: (408) 627-9606=0A>=0A> =0A>=0A> ---------= ---------------------------------------------------------------=0A>=0A> *Fr= om:* Mallikarjun C. [mailto:cb_mallikarjun@yahoo.com]=0A> *Sent:* Friday, J= anuary 05, 2007 10:08 AM=0A> *To:* ips@ietf.org=0A> *Subject:* Re: [Ips] Re= sponse Fence Flag=0A>=0A> =0A>=0A> Not really. Current draft text is inte= ntionally written to not have =0A> any dependencies on T10 dynamics. The p= oint is that iSCSI needs such =0A> a notion for succinctly describing the p= roper iSCSI protocol actions =0A> in a few places - ACA, TMF, Persistent re= serve/Abort to name a few. =0A> We certainly hope it will be approved by T= 10 and be a part of SAM-4 =0A> soon, but that isn't required per se for des= cribing what iSCSI needs =0A> for its correct behavior.=0A>=0A> =0A>=0A> I= PS WG has adopted what it needs in the past - staying ahead of T10 =0A> rev= iew/approval cycle if necessary. I_T nexus loss notification, =0A> iSCSI t= arget/port naming, clearing effects are a few I recall.=0A>=0A> =0A>=0A> M= allikarjun=0A>=0A>=0A>=0A> =0A>=0A> ----- Original Message ----=0A> From: = Eddy Quicksall =0A> To: Robert Snively ; "Elliott, Robert (Server =0A> Storage)" = ; ips@ietf.org=0A> Sent: Friday, January 5, 2007 8:58:47 AM=0A> Subject: Re= : [Ips] Response Fence Flag=0A>=0A> From an earlier email I think that Resp= onse Fence is only a proposal =0A> in T10 (http://www.t10.org:80/doc06.htm = =0A> ). If so shouldn't iSCSI wait a bit =0A>= until this has been ratified?=0A>=0A> =0A>=0A> Eddy=0A>=0A>=0A> _________= _________________________________________=0A> Do You Yahoo!?=0A> Tired of s= pam? Yahoo! Mail has the best spam protection around=0A> http://mail.yahoo.= com=0A> -------------------------------------------------------------------= -----=0A>=0A> _______________________________________________=0A> Ips maili= ng list=0A> Ips@ietf.org=0A> https://www1.ietf.org/mailman/listinfo/ips=0A>= =0A=0A=0A=0A=0A=0A__________________________________________________=0AD= o You Yahoo!?=0ATired of spam? Yahoo! Mail has the best spam protection ar= ound =0Ahttp://mail.yahoo.com _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ewindham@africanbigfive.com Sun Jan 07 06:56:36 2007 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3Wdg-0006Jp-3n; Sun, 07 Jan 2007 06:56:36 -0500 Received: from cp1054249-a.roose1.nb.home.nl ([84.26.55.104]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H3Wd9-0006QC-KT; Sun, 07 Jan 2007 06:56:36 -0500 Received: from 89.106.12.84 (HELO mx14.turkticaret.net) by lists.ietf.org with esmtp (D8;N*-2X,CV0 0.4(1) id *C7W6T-XUHY?1-A4 for ips-archive@lists.ietf.org; Sun, 7 Jan 2007 11:56:03 -0060 Message-ID: <01c73252$ce830ab0$6c822ecf@ewindham> From: "Emil Morrison" To: Subject: OEM or Retail Date: Sun, 7 Jan 2007 11:56:03 -0060 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_000F_01C7325B.304772B0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-Spam-Score: 2.3 (++) X-Scan-Signature: b360bd6cb019c35178e5cf9eeb747a5c This is a multi-part message in MIME format. ------=_NextPart_000_000F_01C7325B.304772B0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0010_01C7325B.304772B0" ------=_NextPart_001_0010_01C7325B.304772B0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable And piled up at the base of the columnsWhat can we know of whatever picture= -planeToward . . . that seems to be the whispered questionAnd half-starved = foxes shake and pawDim, and die tonight?At San Biagio, in the most intense = roomHe never even dreams, being sheer snow;It is as though I were at a seco= nd threshold.trainer flips young alligators over on their backs,Across the = heavens' gray.To mark that square, perhaps: were Mère and Pèrethe= re's a pulpy orange-y smell from juice factories....Traces of those deep cu= ts lie thickly uponGray the cloud-like oaksScrawny wolves, and you,Before t= hose virile women!Between the high and the low, in this night.Among us, onl= y Alberti, then Sangallo,Bronze the sky, with no ------=_NextPart_001_0010_01C7325B.304772B0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

3D""
And piled up at the base of the columns
What can we know of whateve= r picture-plane
Toward . . . that seems to be the whispered question
= And half-starved foxes shake and paw
Dim, and die tonight?
At San Bia= gio, in the most intense room
He never even dreams, being sheer snow;It is as though I were at a second threshold.
trainer flips young allig= ators over on their backs,
Across the heavens' gray.
To mark that squ= are, perhaps: were Mère and Père
there's a pulpy orange-y smel= l from juice factories....
Traces of those deep cuts lie thickly uponGray the cloud-like oaks
Scrawny wolves, and you,
Before those viril= e women!
Between the high and the low, in this night.
Among us, only = Alberti, then Sangallo,
Bronze the sky, with no
------=_NextPart_001_0010_01C7325B.304772B0-- ------=_NextPart_000_000F_01C7325B.304772B0 Content-Type: image/gif; name="lzwkhrpj.gif" Content-ID: <006901c73252$ce830ab0$6c822ecf@97BFD3> Content-Transfer-Encoding: base64 R0lGODlhuQGrAbMAAP///wAAAAQE/B9hqmGw5Orq2729u8/PzvfwYvvQCGBUI7OZbPqCBvv7+wQE BAAAACwAAAAAuQGrAQAE/hDISau9OOvNu/9gKI5kaZ5oqq5s675wLM90bd94ru987//AoHBILBqP yKRyyWw6n9CodEqtWq/YrHbL7Xq/4LB4TC6bz+i0es1uu9/wuHxOr9vv+LzeGehn+gEVfnyAE4Ee gIl/hQCKjYcziZCCjheSlJKVlpmZIZM8g1yhJJ8imoaMqISMo4ucrY+Fl4+Rr5inEpwUr6mbvLAa wDnCVsQdxse9qMhKrcyn0JPMLs7SocqpypYb04ilex/dGOLj2rHfhJTcxL2j5CnA15/V6sHoqirv 4Pik9960uwLRC4hNoDtcuWbdsvZLGLJBDSHOQ6hw0aaEFzFaYOdPIweJ/vIqVsTI6hAuPyUJmhtZ LpbKeywTSvTIb+FBcwEBqhooU1OnntpsvQzZ0Nc6g0V1nisYMxlNfvFgOnX6UxfQao5QjqwKSegy hDa/BrU6NGW9jT+XGtOqjme2kJiWEZwrU25NpWinKnULt65fTya/ycuY92PHr3bxvmV4K7HLnI// Lj4a92/ky4sDn21J93K9eU9BnsVaGS9ApnfXHtZ58PNAWDgtPvUYlfBRXp1pW0PbtRTq2TNd87a3 WbLv3hN7Q5Zt2TO+wYo1E1++PHbt0P6mQcc+m/rddd512/5e7lf47aZZHycMOzBMwdknji+cHv3D 3fSFa3zdkSf1tN2h/pceefS1BplquP0TnnrzDZjfdNUx5FV77K13lU1NYZcgbwKK191m1xUGHX/g LYhVJSH69yBne8nnoFoZFlefciuK0w2FNCVlWooWXoWcV+Pp6CONIEoH4YwsssXdi9E1uFSARH7Y 3HA5uqiaCSFGOJ+Nq+0Y5TM9ainjk0yyKKVKUMF34GEGjsmggMExB2WJPLpJYE1t7hdfCQ6pOaed K5rp4ZnA+enldPo0WaKYxSl5ZJZawuneaMmVhuNvirqiKZ5W8hemk0um9umipA7qXIcFnWfkczgK OtZ3eXoGVpGV2iaQd/ah2pdlk/Hqoj0nFklpZ73KaVRzxd4JqoyS/iKn6q6HYrZrbIU6m5hPRDVm mKUc5eYfWTOyBCSMjc4K40n4cboVgL5MCO6Qy3K4YasKvUshu/Tay26D756bnCzHrVbvvv/FeuKv C5W3ErocGtaUwf/CR+2QTHGEEzkRRVnlTa2y2vHGC0/84cNvafsxsBJ2uc/KVCSahsssx2wGzGfQ LPPNYNhMhs4497wFzzmL7PPQYwD9hdBEJ6300kw37fTTUEct9dRUV2311VhnrfXWXHft9ddgh6My DEaXGvbZSJQ9gtrGou02EWwDZkPcb9eN5dgv0B2o3XzTkFXE5xXoHsJktovO330nPjeQZJEWqUgp t7fvhopXTk22/satKuuP11orLWOd621537+VLk0jBf8qGrE9Yjr66ydcJ7tyuQr+J3OQwq673CL6 OVjtwyJpOHmi74727BW+STiDwotV8t7GRy+onsn/vvyIhp6TZrzSdy98ndYzS2OdwQPqvfeOu37r LqiL7zG3+Tl+/vzcTiv/lPmGzvpNiNHvv/MtEtf9CqUudOlLEcX739YQ95JxbKNGGiNZszSnwApa 8IIYzKAGN8jBDnrwgyAMoQhHSMISmvCEKEyhClfIwha68IUwjKEMZ0jDGtrwhjjMoQ53yMMeerAB IGiAEIcogSECcQJGJIEQO3BEDizxA0Bs4hMpkEQfmmGKFSCi/giMyMUMTFGLXqwiErGYxSEWoAEF SKMa1XiAAxTAjWnk4hLl2MUxzrGJFhCjFWsAxi3iMYh4rGMZpUhIOhbSkFw84xrT2MZGGuCRkIyk JCdJSQPAsYtERCQZMRBFAPxxjzj4ZAr66MlNFtGQefTkKYWoyEU6spKVXAAsZxlLAizAlgvIZS4t GUdNolKUqswiKEMJTBnIsZRmRCMbHXkAWkpSls6MpjQhCc1IQpMABrAlLh/pxiP68phOHKYxoxjI O35yk3JsJRvf2MhmUlKW0KzmNOc5SXnS8572tKUBqgnHNYLTnKYsojhp8MV0LpKRr8TnPRfK0IY6 lJ6NVCMi/sM40BewEo7udKY9H8rRjnr0o9JsZjvPSM5S5rGYFTUBGi3Zxn2C9KUwjalMnSlSXmLS jihN6QjQ2M5sunSmQKVpUIdKy5p2k5yE1CkLVurIXOoTnpRsp1SnWlNuUnWSGfVoVi3JVUluNahQ 1aVYx7rLjUbSnSPtpB6VigKe1jSe2bwlJKV60Deuc6p2xehVRWpUbs6Vq1WFJV/P2lK0gjSsZE2s YuHJWKxa1ardRCJbW1AAwBpgAE516Ub7WdfOLlKZCC3sYKfKUr8a9ar0hOs+FytWBiyAAbCNrWxj m4DZ2va2t32tLivJzAM8MaCT3SJgD7AAzCqguLfk50g9/nvXNq5zjT01bF/R+tXUrpa1uURAdheg Xe0mYAHfzeV3xwte8I7XtbVNLwPUq971wra27nWtfMXK27R2MrgnYKpfrYnZzUL3v65kbnS7OkvE ajex5K3ta9mbgAY7+MEOfq+E3ZveBlP4whiWcHtpi9sOx3aXhE0rftvagMLCEpuCpasbV4zXfib0 ndcd64Fn3N0EIOC73k1web+L3gszeL0VpjB8Lcze+FYYvrLdcJEnjFuoWna4ZxzxCSr7ZJpSlcXt JICWt4zNA/e4yEeGsJgf/N4wE3nMEAYymINMZDVr2MdKXjKTO4zkJiMAsvYVJSmlTMXAWrmfvswm l/d5/uNCc3fH5l1zms+M5jEDGc4/PvOj2zxpH3O4vWDmsJE9bNvdPnakq5won8fY16LSVaIkNaOg uexdITd60a6OMKNhPWtZk5nNirY0g5E85Nn2etOa5jRsX3vW4SIVmTnFrxAHO0u+2tWfqUajELm8 5RzL2s2KFvOkX41mIVdazbgOMpwtXeYJU7rOvk7ynDu9yyunGtmj5mRXq+vViPYSkaveMnfNXGtu a7vR2/73rr0taVrreshKNjeG0S3s2RrgzpaFo0mRGe88MluwLLU3qpNZWWoTwNrgFnjBw81vWx8Z 3ChfdKTLnWlxexvY6g52w+cLTdG2cc/AneyyTWxq/oxuPNoN8PjHHX1yk7865P4Oc6WvPettB5zc 134zuefMcGHnkq981XOylVriizsWr3EEurTzreXz9tvoSU860ktecoLjWsM/hjvMLy3zmQ/7zjaP bBkrXko/N1vjipR24BtA9qEf/fAjZ7uZsR3pNi9+5EsfN68VvmG7c/rqoyVpMHPO1p2XtufsdO7g jVh4BKx97WlPPepTP3DI23rhjwb25CtvedliHuu+9ebE4w3EUj+TrAfWLX1ZOW2PM+DGik++ylnP 9NeTPPFObzmmMx1fdVfd8rLEfZThXfHe97Seix02AxQw/gVE+wAeRz7z1Y745Z/91m5nM8G/jWnY /su59rlFAO6PulYpex6W9EVoxMVPBgBb5+dx47V+Cthtyud+RMdo89dyTHZ96YZ/H8ZddAVOvAcA UvVO2UVNq5Vxq5V7y5Z+3LZ6C7h+AXdrrbeCjLd0CPdmlUeBM0d+2ZeBe+Z/AFBZfvdI9EVcd0Zs alSADEBSjGSC/oaCCvh0LChyqBdykVd/Czd71bduFvhhDIBll8R5nceBPPd73PVIELdPLuZag4d+ 1JaAKbiGC4h0TAiDEMh0tMVwv3aFuZVxEZWD/vdGBAaGH7gAA1gAjHV1gYeGrMaGiMiGp+d+LKdr bvZtCleFdniDeaiHysaDfWhNjRWEuoSFElVi/giYiEsoiuEWa26HbRk2eZJoh01mfszUfyN2UT2o ifDUUlTmgwYQZYqEhKTYi6QIhZJ2cOJGhazYZHhlicHFU5/ngZrlg2j1iaxUAKHoi9S4fCn3ds3n gudGdRVIgzN3e+3EhZ2HiQW2W4AoaOgHaEYkjdSmftX4jqy3giu3aao4g8VojFKFjDrHhy1VSZgV SdjEYgTgW0DHjlxmY/CYkEYnj7lWa1A3d/fYaXhIgnznSey0jLQYgFqGhmJ3RtOokCB5gv8WeTJo hb9Wh5OYhfm4dSl1URj5TMelSwFpiASwjkPEiyGZkIyndI8Xh9aXYRGJj+HIkjpFeLPogwRw/lz9 NUnEt44fmZNQeY3ZKH0WdltSGJSwNVX62JIW6XuSdFxiCFlvREckhZNQeZaoyIL095P2GInFOJHb 130l9pLNhmphJ203mYZnCZJKqJaOF4Hppop1Z4F4t2IFUJEWSZf1hFkEkFejl0ygeJDuuJfvuJMw GIUwd391tpmsSIl6x3dz2Y+URAAOoACmaZqNeYu5N3pmSZkh+YR/uWQJB3tYOWyu2EhEKU5HdJH0 ZgAKMADcZEsKUJOXBYiJVIIH6ZrKyYQt2Gv3R3feaHeuyE65OUzk5JVzBZbN9EYLoACVBYhiV3zJ qZx86YRyWH+COXWDaYGA6Fxu1H1992KS/vSPPTUAzVRcR3WA40meOXmNRgZ/0/eQQBmdHgaO71mR hJeJMDmTlaUAuEiCXESThsefy5lm0Bl7UoeSBDpz7DSW1WmdXaeYlmSafoWfcjV6RqiXFBqVBedq U0dpq1h1G4pbGQiaXdeb3DQAClCaO2oARumjhmSQWjaZK0qNUgmMwhiJcoaSq9hwEXWgoGlYzYaU K+aDj5mXW1ake+mi8rekbrmeM3pbvORcH2qdzBRLPGpcvLRPNWmTrNSOWqqQsSaBdDqB9teNtZdx cYSgX1hJwjkAPEpNVypE+YaQcSqnRQdpLyp1dHaPY3pUo+ZNXhdVXOWgxQVJiCSkBHCo/pXZdD1Z krHHmdRHe00qpqC2gZ4kn5NUmsCJn6uFWQRJR+1IpNxWaJwqkiond+epaaTaqGHKAGO6pxUpWoKV SzvKqpYkS3hJfGdEk7fai6ZYdPJXklfpiL1qeXgojgPVRKpaX5bqoPs0qITHarTaaLb6rO23a6V4 rdf6k+uJW496mIiJdbCko8CZTW1kn7fEfxG6n8xXroe6iM03jNbKlupZqh72cKKHmG5FS8i1owow gOiXS02JlzSJAACLrirYemQWfdUnqsEGsrYVnY9apuJErAA4nAnlVMtqRM6asRq7hmkZm3SXipkp ib+6XCZrRUB0kbPEqiQ6lm5kSZl6/ogxq4iOt5Dn6ZwGy7Q1i7C2VbI7u0coS0kO2kxJuWJMdW/M KplHi7RNGIdeOoe4JbJ2mI8IuoPdCkng2kYOunFu+qbVBrNfm4L+mbSMOqo4y42cJrWIiYm9iWLN dLWtJHiQGXRZSrcONpmKS55SmajbyLRXqaEf+662xWKaV5G8mbK/CUmfmGpiZ7Rr2LhaCpuyeae0 iW6/+mEriaCAC0u/uQClOZCf1bJG5LVJ547naqgPhnyki5Zi26IEK5hOC5Gc9qRTy7P82JsO8EgO +rbdFG2jBwDkmruv9rvPinL0+KVOq7oja4WyhWXaqlM+S2/g6qCwipd3KUeGiLH+/ua7NlZo52qr 9Ntg2KuTDomNHku8T/ur7am1yetDRima75SUOkq0Hnq4WLqp8Hu9vWu/vLu4EgzBjvuAfnmzp7u3 jCps9uW6fepY3Qme0Wu7RNS+7muuhlq/DTy/ExzBpeuTXarBxBijBZqFoRfAPbRsIjpXOoui7Ktv DTxmQYyQLCzBRezCFWrB2xuDZgu1NChiCPqjvZlcLAVavTSoBomxJyxmviu/7lvEWkzEFKx+94uI DImkEhiYMQeqVoe541tROnyU3Wmvl+qjg1eQaDQAWrZvSBy/FAzB9cu7gUzGcXqkNMvGqFuBx8ti OMxDO0fAaNqdpkmQoJtOt9Rl/mL8wH6sxSo8xiocxLu7pWj3gnFXvDSMfVBso1I6S1nbTAPAtXgc dHocxly8yYJsy12My2MMYWVstxbsfLLHjTNcuU1mw2TKsAOsoE/2tr5JyRXbtXosSxH8yfHLybgs v9ecwn2MvwDqfGumpFXovdgXepkbpTvsV/bqAK9shM88RNk0AGHMuJsMv/Gcwtj8xWJMyNtMoQ+p mdvLq05qmG+sm6l6lPtEn6slUauZToQXzVtMz9bMyV58z16sy0dcwXBIs8Mszo06W/oXjoiZqufc naXpAOa3vu3crHt8ALtb0fTr0vOMzzKdyb0MrQAnuYpspxxdqq/lxiHthftV/l/FGb1XCrro949c /MUSPdERrdRKnc+3XNOJyJCxObyDyZmX16FxOawi+lX2OZbsHLdoyF2dXM9OHc9OTcQvfcu8/Mcs ird/OXdUmJ4F+r9tFNLep8zcdKxgCdYkDLrsCIjTvNSEXc1qTdhobdiB7Jo7CbkZSswzd323+Zl8 hkcfzF9chVl3GdbptMcnTNFnLdHZrNiKrbsPLNUym79xp8G0abmu9dHHHNJnOppt28ybfZxmtMcG kM+I3du+vdSl/dSm/dZ+ebqmLKNQy7od2sg7lNc4elwt9bb3FsvFJ9gQ/duijdjVbNYtvNjAi4KJ PKAIW3W5RM7MzUPf56ex/vubnFXJdHQAsPrS2D3f2X3Ni43aqR3DeLvB4CudqTysqxxLnevMzwx0 aHgAMU3fnw3cTG3LNK3PlLl6dzrMct1hGJiHeM2DvXkAqJmsABye/RqxuezbuSRfsaXg893C3y28 cY3Va5zTxrjcGT6pMMnXtBt47k1SE/twob3UrzV+vqbgwY2Q4GWaKv7WdxuqSwzQVtlpsJ17M67X kCS46y2u0oufTE3YkmybJX7htsjJCnBjx4V8RZ4ACmDm3Ynm2ozf7MeT+u3a+AeOW919rxtVOoqa rqgAJcasuM2OPJ7lEj1sf75eYcimDgrmxlpeRY4Ax3VcDWZe+CzKql25/sVbj994qgzLj7OklKb5 1TfXkXLkmx+H3QXA6K+tfxibXdhErql+5pJ8Y2luXq7u1ozdpftNuZP45AOdUpvrVY/UvJfF4bnI cQwtt3/OyaUu0QU45sku6PgqaJysS/Eb5qneXYw+Xmw+ije9jZDd3zRY3hH108pIb27rvMLOSMvK 2UME38eO7Fpc6iX+5whO1iXa7r396qdpmqG8z0Yaf44Izk8rbHgor6DZlefsvAPuwzap47e01Mmu 7Hf38DZ2g9Au0ZI85hir77Kb2EeOqBccde3qYZKt6+KezLzVuZeFwDget+veZRhb6g8P8wgA77Al v8QmaKX18jOf76ZJ/tYO0Oo+buTaBbH8nt/Omaji3e39bXsDf9461LC9eb6lCWjSq8AFAJyE/fBg Ln40l1ncNPOtTtaMHuaSTNJnfuZDb+QhPPZFv7G56nqPzdoNF4a46fQ4tO5SDt+/6QDEZVMrT5Yr 9XEyr/UwT/PC110sTdZiD/YmHe2nyaM7aqyNDun6PvTZvu37e7MvXnvZV8V2f/cDjKPdmayvDFqA v47Z5O5gL/Oobu0+jkvZBfRgr39j3rxDz9KuHubTDrGl2Z9s9+9yT6BeTtlyCcleNeCee9vqvovc xfpav/q+++eHhmjgNfPdudQxSe2Vn+++q+8db9O7OrZ0/b0Wnq2f/n9D4x71zluauXjFQeqyo57s 8g/9aeTFx75daJ7xIq7FvsldjW/mEICQSkvJNC9O3X8wRMJOYcDz/NKOZdI3eeG5tu8FMQ6+aQBg UDgkFo1HZFK5ZDadT2hUOi36eDtDVqslKBaOw2BRKDQOvka5jEaXDwREQSKP1+X0U+4g0UkMiIXA hT0EhzsJi5wNiz8FCoccwAQHR8cREsxMD43MFwSVz4UamZibGVJT04UdnrMfKthY2VnaWtvbICvW LV6DAQWCgoUBMrU0NmO2g5xDO2eyDGe+SEAvOQNIPg2JbMsJRQXKCwuvzEvNTJPPFhkZihdHeAaT dpr6VPwZvVYf/lz/f4ABBQ4EYOZAloO9DCTScsDYGjYRjxUg8OcOnYvOGOyh82dhoGraHI0x4G0C hg0UEFVA54FCyw/nyLmc98kEhXcMFrhDdepGz3w1Vh3s8YrgUaRJlQ40s0vhwWGVdox5GDFZmlXN Dl2UszMjIESBRkYqEK4StQ3a+KgccS4DiQtvYVbKQG/djJcmUrz0eQ8G0KBCWRVdWtjwYcRK0FxJ uKXxx4oGCgxweMyyxDVw7GwtFqeADLXTLFQYRw2Q6dAYNLxUTcJtW0ElLFACNw/nu7c3K8zTmYAe PRc0AufbRzjxceTJj1ohqlCLAwe/BlW2DBFi9YWdn3mOkwcR/tjTFVDL4Zi6tYQNHdyqd1nCg7i8 5bLt9H2BHjudMMq1E+VXOFDA8BmKH6OUM/BABKkwCAvnhingIDHSqAqziLLYyrNiMmRJhUgI8cgi MipxhBDzEHFAm53WskRE3wJxwCUvHCnhpdlifKmEE8bRizRU6unpx+FsmK6VghI08kgkj1jwMccs aE6BylypDhkf3BiDO86cYSlFZurgTkUXUVspB99oq48SDQJpESVO6sKJPhnPOtEE+l7YKS/e8HKB FACDxAEBog5IclBCj2zqCud8GSQLYia07rIqqXomQ0q9zNBSDL+RwxJFwBFnNXLQ+4K+UDt4UcZL YqyTrvpm/nKvUz3L2fOvUvzEYbA1CtV116QKBIKxRLOoBBKH1rhKoolA3GwzSslYFiMvv0HERhvj 4PRE3xoRMSVKZNuv1f3iiW+b+njjaadS2vHPVuJaMY5XeOMF6AeDmmuwoorOOOO6iahEQ1KumsVy 4Eu3sqasC9CcIJpvLJgAOrpWUy+cQuqbNscTOIFYRhXUJUGF4HwMuVY/EeKhDHlTVhkXYBMVcSgJ j60SWcmebbZggp8tpNqSphVJkZDIhI210crZ9k76WNrtnI5XELljkNdlFwd3BV35aqynSMOpYAmI qtiZj72ujJqd7ezmTLmShg4R18rhi2lehHuSSN5ejUUK/u6cByZNmmanx6d7nLqGP4gqIGvEE0/i lZafctcXMiSk0F+DzA6Y0gYmzfIQa+rAZtq6dUSvbbPASTEa9vgOoek9+WxhVuFiH87kyhS3/fZc HrRXIQXEEFYyR5FtA9qbz8bwbO22yubn0SP2LRoZVZceHb/xcz24UQZ/gfZccfc+6613V4gcSshw ReyZkXGI2cuNd/9CTe8YTUUvtFGPD7nWm77vj0X2H3btzQAhO+je9wyYsjSIzzG+6F0r1kCd9E3O bFhCW8AGJo2TlCg1b9Hf/jyorurN6h6Cs4etdODAIh1QhYUySvgYxDtGWChybbBKBAtWvPYdLyMX aoYG/ttyiR9+UIgg/J//+BRAwrnrcL5aYRMR1MIHvZB3FVGAL8CWDJkhY4fIcx8C0rCsaNHBh0GU yxDN6LS/jRCAJJuayQyABifGMUFQxAKTtvALK1ZRcvzyl7E29z4c5gyDG8Qf6tpyRumxAI0ipJXU 2oirfshRkk+Moh23QD5HAK9fY0OW+zJ3ue1AazvaEKMP84fIDyoyaiXEDxsDFBQ3RnKSs0yOD7im kMhoIXJSohykJmg5y7GvUvDroXlQZ8gyorITy/QY7I7ok8HtwhW0pOZxEijFBToiOqsgYNgiWMP3 Met4gyTmGIPYmlMqsyWtI2Ij04XEGQSKOtWkp2Eq/mlJC/EgKr1TwAwvYyzM5ExtFkze2sx5ykMC UZ2J9AAjQbbGNrpLlvWk6FF0lyjGnIwx/YIUDcPGw3CqbQ4jjRZJTXmODi60f+1sqBof+pNHXoGJ FaWpP2ypwDsS8IoyA6hHM8c+PmzRWQbFVCntZz8OqhQmrEujM2v1NO1Jc6I1paotdIHPLARCmljs aCclVNRg/pJ4XzKqMcmYOqWiYJ1NPaJLZTecARVlplWlqxMKlECcamEVA+omJ/9plaF+BaSBxWBZ S5RUDiQzrWpl5OtAaAMSRnUwcKxrZWHBHGwOkAD69NobI8fVb/rxlwTjISm/NFLD/hCdiV2sB1ep /spnIrEVO6CsZW0LhasGaxgL6OzJOCq8R412qKg1aFlTGxr2HHITrUVjS0PWTmgK7pWwnOxUb3vd xTWgjs5ZxiVdsa/0ZbENYUTt5sIIPw0yLKFoZS5jnbbK/z0ViUOSK3bti4RXLEm3ToFgTz36kLBq ZZQmNepxOaDclKa1emn82xqfOd3ZBaq296XwEDCL1WV4bRieLUZH/Ts8w4oSvSU96FER297mrgC2 Do2tIwXEgMFIqcIztnCguLtb3z0IfY/ypnDJO2IxipKQhVQuijHBTvhCNLaDk+eEaUzh3NoxIUNa xR497NMqFTOoxDXtIE+KzCKjeMENZqk72Ti1/iHR1rpPxi5zsJoFr822v7+VoICDTFzjlni1Rk4x fMns1Oy9M6IEmiubbfsDGwfrIxHKkATDiwYSd9k8Bj4qENerUD4f+c8+giqEAyOKJq/Z0NfN6yVZ oTszUIlffCxDpNWiZXOqRrVlTDBzk7zpkZnC00GpWkEKPerK1iuzOb3CZ68c3DaQKDSGVW+lz5NU ENRapUh2bhGh+VZa+WlRRBI1sC1b6jpCJTtV4eOVPzlGaJ+Yg89ObjKlrVSoubd1gl6y9nrtZG8H GwAFuCUv5Mxb8CJ7ShLhQaxjfeIwZ5p/Rqx2DKAaXTQHCiL5tq8LLSlPmXZYvKr2gQ8prRZD/uLv 0ukWM4MXae3/XPvMxIGxu3xN8TY3rhdKbLQvvTnwBC7b1QZft7r5vGARWluNu7bVdLrZbZhTld+l rhrmJPdNwFZJ2To3OCGhnXAjj5mI1huZf4iOA/oWMOmWveabHVismh/bwx/n+cjXu1yFc33rLMa2 yoNkdIekcOzBLjtGad5hjop3hg9KjZabfVJ2vxve1GOrO+MbwLAjfe8VXfqw5Ym5nvq1k7CuuqzT jdK4N1Pur7Xe178ulG3Pc/LBvig+m74v0Np81SEecnqRi2D2hv69orfH6HVddMaIffVU7bvfT9bo CWEZoOb7DLrNiky4Kzb0QW8wkgW9cnaF/l3vw6+p1Jl+do3LvpdZPrish6xetCpenVHTNPuxt67T Cyj19Po196mpXUTN/O/h5+nkEiiHwxO5w0M4Wos+3Rs9oXuotrK7iHOg+rM/Wio+7nIg5Hs0jvuo BwnASgs5z3s79Zu2llopuXMpIIEnnaCvfnhACJSjmxq2GNOxCvwrzcsyAws5hrm6AjxAeeO9wCG9 EoKnyNu+FaymH6gk7jo1tBs8nAutiVgfq1OoDgSzHJy+ZXI/6Fqy+JM/iRrCqtIvx6HAz9I8Thqb 4XpCG8Q9HWQmalvAXEs5eJIqyeNCFpSmmcOVJMwyylm16qADAjwnD7wfkss09ms/HlQl/lYywROU qDiUwxVaDBeMsSQEvKvgsVVTtnUrsllLKExLwx2Mt754v5XLQqohNEaspwt7Clxxuq4CLi0CuQMD xMQTAU40uYZrOEMsQSCMMXwrxUk6FONzCLR7OnLbJDzEqwOQvtSBwgL8QAVjsKBTwL/wi3oDQrxb RF48oKvCMDAMQ+HxPxoEORxMJ2ScRY9hqyv8xD5BxLiSsWuMQC/UP41yumEMHmMBxld0jWRsN3J0 L9+bO2mMHVFEvY1qRyI8lItDwgrcOK+SkIITwGjLx3HUPT+rNk7LtsdDRH3QRWskSNxZEMtTojtE tnm0CieEyHFkxtbSOtgqsweDKeyB/jwUVEGO9J560cZIXMJu7DHdSaxa6yCUTElnxLXHWsCA/DSp EsKZdCJwq5pINLaRLDeDuMfc20cR9MRWejzosruitBNdRMqkxEYAeJw63EZ/gkqvggh7/Emq7J9B jK9W+kTsG5x1BAKZ/MrE2ZoBgkdg1DiRJEbQaoVNXMuVurX3aiwg8bSttJMhET67VKGa/EXMW8Vu vA53MUDBVB12QrkejCx13AXGbEwDwkvXA7+ae0q/bEIeiMjLLMe2vLWue0mMvBWXA005Ekt/Q0j+ y8mzlLodUEuJVKtNa6syO7NpNMG4WiLadCJ+C5bXS8jTjD3vO0bf/M2tE72rfKeG/sq22BQSz9zI 5Lwa3bHJyPywyRwbwJzOn2O8wBlOEsLF7ZzLuvxOlXlHf9OoppySkewjHtCM1Ww8I2rNxoKo7eRO FJJPxzTCsSRLC9RNf0qgzWKt/lTPl+pH4qw745ytzzRQxbmnL7xJY+ux3yK3i0LPrBO6oXSseZOu AU0F7tlFDUWcyhvNeFRCs7RA69isLFhNRVqdisxOrjMzBlzRyPPOF90VCaxPsvzQ/PQvNaCIPohQ lkIBMyPB7ElMW2nR+CxSFioIBHUcGJREqKuhJcTRYxTMELJFNB2FoQu0FRUMB8xSLdUV/PvIbcS5 JbUhg3hQElUmpmKqipQvNmwx/gvdzhd00ThFoC6Fxy/lKrPMvJlBFHKMt92L0k5zpSBtU8KBJCI9 1CS5qYPcv/CjoeDhuAchAP48wDMtx+qEy5a00s58U069y6ZwQdJUQjrzv+V7A0KgztLjwROlUtlx 1ahSok2NVSTBPxk9Pm501GGUwQbYrIrY0yHaUet0TfnSzrjE1BugHTYwVvDZri9c1BDNyeWTHF3N 0bg702ccwWt1T20NDG41VG+VU/ocoP3bpHJNvgU1VXRNQ6ArvQD9wXe9UmKF03mdo++bUafEst0E qP3cAR1csesBWCys0IGF1+oy2IM9EF+8OGVdWEY9zT6C1l0VREJsVXqrVGFF/sR4ldeN7VSZs9da DdlxxcMm9QFTNVXLbEZ+NMdnJJmVHVCN1NiXraWYpZ2P1Vc9/C+PaoVTTVd+BNrXhMagZdmMLdai taaEkDI75MvntNNyNYOcDURbm1SfpdJXqlokGtqslZeODVd5XMV8FdVjeAN+NYD2as1O1M72FNCL xQcTCLcUJNq2NQxh69C9dE4l7SNwstt+LdFelVRnKs6/LTo4pMvC5ZVE00vnZEIQpbNSjQxp1TRV tULHQjm+hc3KxYdQ88rMRZLZ6tBFXdivpdt+ydmK4NkU2z2rzDV3HdS/FYWufLnXLZSM4ty41Vdw ElOxzVkINSOrDEGJDdBK/l1dNAs3ISDc4k2K2JXdkCRVYrw5y7Db3B1dlQzBoKQ7i8xW670BYqVL 7d3eozhapEW+m+UxZw08nM1ZNXEtk1vJQpxYw2TTS21fO2k5Vohf+eXe7nWMmQ1Z/B1Db8LdP0Ak vT3bAAagfzTgIJEnzF3gQYlR5O1cG8VP233WnH3ctVorK7xFdLzWNuTgoPACDFVgECYIEdbL711c Ew7f8aVgNQROiZXe6vNPp+JMtcXI44wkG75hf1g6jz2+79Vfm/ta8jUAOFgqvpneIn7hh3NDGQ6M GnbiY8UrVGw6r/WrsL25G8VdpVlhv1nJFUvdf8RKyArjVAjCJiZjXMhh/gdOWhOmxAsUVTLA3aft USEOymaa42AFSALG43ygYSyYOD5OkNaT3WYJ5B62sikx5P4dM61rrhTFziN2KGyFZCEpWHpx3Upe CheaQIX14fETOGMg384iXSJe1cJ0sTuuUlS+XsOBo25t5eO4ZCRN3Gb9Wj+6Mk8eAUkV5f+txTXt wev74l9WBYnrRmJGDFui06Zs1nIjT64yZAJAX2pNVfT10UENkLR1yV/2Agap0T3eZrsKzyj+WJG9 U/xNA1MdAAIYALxN5x4d4v9kw8CIrN+9Zp3ozjBdZXpGity6TVBNvhk0t2QgZ0kgs1wWQQQMNK9T aMhrCPDqqodWihaU/jIKDEZwzl8qXox/fuk64VHXNNHqRaIkfk9ukiEQRZmShmhfxORlZd6BY9Ym 9OSkoVZVrcIEZMCbNuCc7oHYQ86eZgqD5Nwd1l9HxcmJeGl/zoHeBVaGM2LgBempgWddmoj7xdqp xq3whOVvbumhfrRj6eeXDuhQ1uUrJMrrI2vjdAyvnYi1Xo6t1WEYDN+wzepJPAYs9ucuwFv1LWJK dTiBLWC+/rScloyYud/DCWymyCuJy2RBZlo7/afJ+GfGVhrJZVcWe7CWrOwAMmsZKp404OzOjtnm XGkqzmq/5GqdVbGOZsm5m2zXzsWGuJlU42na/odZvWfjhk7EZlg0/qDrARADUehTzfRdyX4dvx1u y94CHCqG5A6Ixzxmcc3tuFbmYzBtmLZrvWbJF07dseZuAfFr2d7s8P6H5ngMjGvu/NVtWuZn3nZs 927vdZXa+JZvG4Bt4JndDrtv/MYpibvqmiXqxLYC0/bnKqJQanZk7KZsBAc7+taxYgEbB/eHzf1j ZF7p5ybqZPHn6fbnOS6izbRUIG1qDr5sES+GJCxxE7dtUDXs81ZjE/aF6X7pdTDohzPol+TlDw8K rSruHGc+5OZxWljOKJbyUJ1bmp1bB3Xx6fZqa51SX4bLR27ySN4r7tnLEWdlKsetBpZZfB5V8T3s XnqDF//nTyZK/pSFzb4VbjNXhctWc+Yj8TafBdFE6ToF2bh+ynzl6i83gHRhZwPfaxvna63iJvBL XKspdFkIH0T/5juV5XGFiAv/5/1gJbdS8umi3D8XkkC3Z0HndEOvPO/NTTHdMQl+iDB48SIf6HZV uYR251YHcUzP9L2cZyqHYia5vPG8WU3uYfy1c14ngHatN/dETPYd9idfR5DkAVnv9CiCZXGN6kWX 688t9ekGhEiXWiT38GGHq0CIjNc7u2+PhUM/5pB0FDpncSYlcl7P8/f+vWwfeO7WC1fPKkjs9nqP hYtK0Nn1YTo373LddV7PAjXl8Hc3QS8IBEBfCKRlytpZ+CmA/mLk3SnS9tyIT2yK4HXfmdDXouOD hjgEv3RIB/HeAvnZFPkosDjCVly6HVVyb9ILv3O9PuWMD4ybQPOFgAqD1wdB+HiQ13kpONJwe3jT BPqhLtehf3FsFdSjF4r84I0n9/in53ib5yuMIxKp33lwRfHCpmiLLnflY/l07w/JBlLtqfS7W3qy Z4W9GgTAr+485q2nDrdeW/snMONlR8LMTmZnBy0tfwi6p26Z13vrDQQbEwRu2vywb/oE3yt5h3O1 R/wmiGjyvmrH//md9iZ/f/FV+EG3zPjHmTJREHxt2zBMX6CcJ33F2DeZuzwJV75lJne0Vmy6ryJ6 O3D5BrXC/oF0s9eebbdXw/d23i99z05SAIN4n5Jz66D4aR9zQP367dz4hcglkYbV6l+Cqtb9FK/Z 4kfvZRbGrU/3QyR48ZfLv7/NU3PZ9Pe1/D59CCiyNGorpi1v3L2mZcRQmsOyMEyytuzqwjFd2zee 6zvfr8pPkUoRFgQDEnlYihqAJzQqnVKr1is2q91yu94vOCyebpaGQ1K5PBTYEwlnI7rQ5RdQB94w nEwMxMzLi4xPoeEh4uHQgoERY9KayNgkZaXlJWamJhkaWlpn5FtcXcjH3aicR8VBX4mCQcwg4Wxi rW0tkIKu0IACisDQ0UDjJ9sHwMam8jJzs/NzA2iaGlv1/gRqaqm2aimHBkmf0Mz4bbl5+SKjOvGj QRGSntOT/HO9/T0+foeZZ3GoBRxSeLAJbFKhAJ9WRWwMEnTu4a1cDHYtQGFxETEkRzZ+MkgvH8iQ IkeGidZp2hkmb/ScarINz5w8BzUkHCDA1YAEC1rIkgXxZyIVGDGmOZKmXcoDH46RbOr0qdNoZ6aq Sepmpbesd7amiiOzwAAHrVLw8AkUqERdC3ily4jybailHZAlg2r3Lt5MTsrwmxbqatfAdbpyVZV1 A7g+ZGkxPuuYgdB0SP0qoWZMLma6eTdz7gymr981V68F9JqN8MDBGRKKNcGInNnH5nKprdj2rWVQ TDDz/q5b1zPw4MIBSPOnkrTXEINfblOO4YAvmydgya4eWTJc0fzW9O7OdDj48HedrKEKicnogty0 fk19GmyrEovJxarOI9da2/opW9XO3aN3vc0jHoEFioRQP5WJ1gZWMdkhl3p0AHQQBiS0dkJs9vkA BGSSTdaff5EEOKJcUHxkIIop6kVccecdh5xAGZxymmDrUVCTYipouAN+QqTAx48fhqhdPCQa6dtc Kiq5ZCWgKRgJYKox9+BWzklIYVgm3DQAZDvucB1RkIC4nRtHlogMXXudmeaJTLr5ZhYImkcNgw0+ CFONLZkyYwWJ9UGdhhz6aBsK67iD0pC7mcnbGL/B/vkopFFUUNknSdkZT4R4svQSBwYosKUJ4lQH RGQdDoFboiot+l2krbp6yaQnGVdnaROqxx6FIGBVRnzy6fiQCoOm8w6qiQJI4qvJKgtrG3NaRSuM 76GynEy5zkFBr1z+ik4M2GWX6qpJLjsuuWIgROmT6RHUXq0yUlilu3v0Ol8PQkE2aKHD/PjtkMeO WC7AAXeRTLOyPqtuQVPO2NzCq/T6iiIeTtZPqkr5a6TAGWtcRR5TiWYZtLdO625zX9VKwIWhEoCD vRKfimjFFyPb5sY111xwUnQifFhpybGrq40IlZCyLzmA+TKlFS8RLpom2vw01PKYpF1/DRZW8kxZ /jvYzYTRlHCTABdK/M6+oaVa5KJQq702GW34p0bIJEtpmCnWSkgKK/N6qJHZ/crMKBlsC26z1HIs 6J8oPW/tja2EdZOHQRVFp18whxoXYhtHarZX4IN7Tvg+6FVDJGkxqmbjncqxZIY7RhRhlFEuxmym JFnQ/DnuyiJ5+OgrtUuyjKrT+K4d/ajjyMRKx8Mm4Gk6L+mAuUu/cTKrqIReyL/THRhMATWr0SKv i6kb72gj2/QWUqM/PfvjfgCl7wzuDNCljbOOBPKWJ837ggEyfww9HEUFzi2lfQZ0n+HcYA3fLTA9 Ehjdx47SiNd9qGqY85+jutO5ATLldgf84Jv2/vQiB8ZvdLhBSez2hz3SnQ8LrAIhDAe3FLeVaYFv GA1fPtYi5bEwMx6MIRCDqCZTxOWBDIrGBBSoNPKJLi6SWlMQoyhFNA1xhtrJAAkhSEPEGZE71cvM FMMoRjLULQ9XVGD8soe4uTRvjG58Y4AeyEMu+s9ESBLgG/P4udt9EYz/u1IL9SjIQZIxgPMw0yHF Bb0nErKRhAykIyMpyfRNspKWvCQmM6nJTUYxAJ70JBQ+KcpQTkGUnwylKQMghVSWcpRPUGUUYElK Wb6SlFUwJRVoCQBW2nKXq1ylK1uJy1rGMpi+jCUqh9lLYiYTlMx85jF1yUmS6LKav7TmL5GZ/sts QhOWtFTlN3cZTmgu85iz1GYvZenMZ2KTm7YcZzrdSc5XwtOcxAznOKU5TZG0s5v2/Oc/9QlQb27T nOB8p0HLOU98ohOhtVSnQgdaSmbqk6ANnacvIbpQiiYUo/vMh0DLedCLBvSWEwVoNM95z46itKLI rOdKHxpPLUjToigV6UknqtGWcnSnIf0oPk5ZUI4qtJ8ktak2IapRi+6UpCxtakxTylIs1JSot+Sl U6UK1aiOdKpAbYpQl9nUVFZ1qA7lZlfTylWzztSrUtWqWMPazLCOVahGvSlTI6pUlXr0qyFpJ1nb Ks+iblSmhk3oVnkqzmGW1adulag/C3tX/oHutbAZ5etN/VoPo0J1rGwlrGIve9jKhjap2WxsPBNb VnbqNbJZJa1LR2vPn2q2GZyV7GAp687bNvSbiS0pTwEb14vGVrDCPapJUUlcedK2tvdQ5llNy9yr GpOecnUtcBcbTGW6FKterWZ1QQteuU42uSINL2+dq971sre97n0vfOMr3/nSt772vS9+86vf/fK3 v/79L4ADLOABE7jABj4wgt8ogAULAGrNTXAjGbxgB0N4kwv+YcAeXGFBTnhtGt4wFjochQZLQcJT IPGIGyxiKKCYxS0usYmrIOEXA6DDDHbxilN8YxzH+AkzlnGPU+xjEQf5Cj8+cZGHPGQU/hf5wyC2 Qo53zGMYv3jCUb4ykI9M5SLP+MZdRrKWu8zkL29Zyjw2MZmNnOYlJ1nMKtZyZp+8hStX2cw1xjKd YUwFBsvDznxeso77/Oc7t3jQZr5woAGNY0HXWQCMdrSis8zoRUd6yY+edF/lrIUVO7rQkOZ0Azwt 6BGHOsVt8jORIa1jF+tZyJUmNKtxTOUhn+jQdW71nrEM61XHutdKzrSmQzzmO8c61cT+9bGJbWwk k2HZknI2spGdY2RAe9qhJrG1OX1rV+dazc32NK6R7eRg49rKw062uXttbGj7Wt1uZreuk81tbXeb 0G7mdrTlHW5m8zvf8R43uYWMaGWr/prgox64kgdubppNG93vPne72S1tcPP74RSPOI3bve9ox1vc AQ9DuhMO7nXfmuRArvedMdxxh6Oc3hUvOJS3rfGZz9zlGI/ox7MQcoILfNh49nnG9T1xnct86P22 uasb3m9/B13o+Pb1ykUM8JyXusVVl8LVTaTiZtf42V3P8qxfzfKnp7rRUM/zrvEd9aaj+tW23rfU cw4GVNOY7rk2e8zHDHMpD1rfHec7wtFOaHoAfu9Fd/rZ9U7pm3N76jm3e9hlDebI+33NZ1473C0/ bTGDuc2HR7q9+x76zX8exY7/eKmxnvHUe32ANGZ9vq9tZ617PvOqr/3tZ0/tJFc+/tw5ln22eY95 YMu9+JU4vaYtrvzlM7/5zn8+9KMv/elTv/oTRr6cra/97XO/+97/PvhvjH3jk/8K4y8/+geb/vWD 4fzsf79fvendnHbht1Ttq/stgVQr5L+4mcg/MN3fJQCgGOwfudjfZ9EUzgkgAzqFAdpWAh7fJjwY ABJgGCCgq/wWODmTK22XODVTRq2TdhUUQdFVb33gdXmgCb7TCnZVZG0gZZEXKKnTDIagdfkWDm6T DHLgBwITB67gXN2gWD2UNdlVD3ZgW+2gUqkVwMCUcq0VC+bUOiEVavXgW4EXPVlVNC3VS0mXCwLX FNKfTfFgFobhWY1hK0XXBprV/v4V4RDOVhamIREOoWN1VD55VrngIBKeoXShVR9CFhVGVRImVz4h F1yRUyCaH2vBYT0Z4E85oWiJISLyoRpiFEO94UEx4QnC4QK2CiRyIg3uoR+yIHoJYgkOVWcZYSUK 4SEC4mupoinOFneJ4HUtohDqVnQRFR4WIhty4kplYjGFIiz64rh8Ii+WlnFlWl5F4Wrh4Vs9Ixpe oWJBIhdW4ieC1iYilnk9I1/t4h+eYCPK1BcK4hsSH5wYYx/6XzLGWStKIzrVYSwyohdi1ipu4jFG IjuuFiZ2YS8G1zreIzja42XFlv9doye+Vjp+oxYm4jxS4iBSVCLSoEEtIz7WlmM6jSFGEmM0bpUZ SiQukqNsLaJE4hVp+aIzRiT/NWEwiuIWyp8Z+qBJ1mI7MuRTBSM0JlNLziQhOtUpheJEAuNK2iRO 6hQt1mBIeSAb/mBRjpRuDeMICtZiBaUtsmOkWGDuWOWyYGVeaCVwcOXgeGUGZmXGgKWDkSWkiGBY wp9ariVbtqVbviVcxqVcziVd1qVdCkwEAAA7 ------=_NextPart_000_000F_01C7325B.304772B0-- From ips-bounces@ietf.org Sun Jan 07 09:46:58 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3ZIA-0001AG-IP; Sun, 07 Jan 2007 09:46:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3ZI9-0001AB-IZ for ips@ietf.org; Sun, 07 Jan 2007 09:46:33 -0500 Received: from mtagate5.de.ibm.com ([195.212.29.154]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H3ZI5-0008TS-4F for ips@ietf.org; Sun, 07 Jan 2007 09:46:33 -0500 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate5.de.ibm.com (8.13.8/8.13.8) with ESMTP id l07EkS9S239222 for ; Sun, 7 Jan 2007 14:46:28 GMT Received: from d12av02.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1607.megacenter.de.ibm.com (8.13.6/8.13.6/NCO v8.1.1) with ESMTP id l07EkSgg3289120 for ; Sun, 7 Jan 2007 15:46:28 +0100 Received: from d12av02.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l07EkSus019945 for ; Sun, 7 Jan 2007 15:46:28 +0100 Received: from d12mc102.megacenter.de.ibm.com (d12mc102.megacenter.de.ibm.com [9.149.167.114]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l07EkRV3019939 for ; Sun, 7 Jan 2007 15:46:27 +0100 In-Reply-To: <20070106225449.19861.qmail@web51907.mail.yahoo.com> To: "Mallikarjun C." MIME-Version: 1.0 Subject: Re: Fw: [Ips] Response Fence Flag X-Mailer: Lotus Notes Release 7.0.2 September 26, 2006 From: Julian Satran Message-ID: Date: Sun, 7 Jan 2007 09:46:26 -0500 X-MIMETrack: Serialize by Router on D12MC102/12/M/IBM(Release 7.0.2HF71 | November 3, 2006) at 07/01/2007 16:46:27, Serialize complete at 07/01/2007 16:46:27 X-Spam-Score: 0.5 (/) X-Scan-Signature: 959bc20619a369a796f66bb9e13b5f74 Cc: IPS X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0431690396==" Errors-To: ips-bounces@ietf.org This is a multipart message in MIME format. --===============0431690396== Content-Type: multipart/alternative; boundary="=_alternative 005123988525725C_=" This is a multipart message in MIME format. --=_alternative 005123988525725C_= Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Mallikarjun, I did reffer to the SCSI task atributes and why the ordering attribute is=20 ill conceived as an ordering mechanism. I am repeating here the arguments: based on receiver time ordering (not controlled by application) makes=20 them unsuitable for applications=20 they are done either on every command or none while applications=20 (transactions) just need a "barrier" between groups Reponse ordering servs just this as the reponse with the barrier has to be = (hold) the last of a group and allows the next group to start. The ordering of responses is a way for an application to achieve a partial = ordering in execution. This is the way I read the draft. In order to be valuable exceptions have to result in dropping and=20 reissuing all queued commands including the barrier and after. As for multi I=5FT=5FL nexuses (or even multi I=5FT) for the barrier to be = used/relevant it has to accomodate multiple units (nexi) as interesting=20 applications hold multiple nexi. This accomodation is especially difficult in the face on of failures. If=20 this is what scsi had intended it for it looks to me that it is not=20 finished yet (SCSI will need a synchronized barrier accomodating several=20 nexi) and makes whatever we do of questionable value. I am still OK with how it is written (as I I said before) - my change in=20 mind is only in "if ought to be doing it" (as I doubt its value without=20 additions) or we have to wait for SCSI to finish its work. For TM we already did what we had to do (without the barrier) and doing=20 the barrier is IMHO premature (although it answers nicely the single nexi=20 issue). Regards, Julo "Mallikarjun C." =20 06/01/07 17:54 To IPS cc Subject Re: Fw: [Ips] Response Fence Flag Julian, I am surprised that you have not referred to the SCSI task attributes in=20 the command ordering discussion. In any case, in the interest of staying=20 on the response fence topic, I will not respond to the command ordering=20 points you made (debate topics for some other time, :-)). The whole notion of response fence though is all about ordering responses, = where such ordering is needed (only a very small % of responses, which are = listed in section 3.3.3 of IG draft as we know them today). The updated=20 draft, which I will forward for publication today, lists one additional=20 case - that of Persistent Reserve/Abort Tasks. I am not sure of your intended context of how SCSI-level rigorous=20 exception handling relates to response fence. And yes, response fence is not for cross-session collaboration, it is in=20 fact limited to a single I=5FT=5FL nexus (please refer to section 3.3 of=20 implementer's guide). Regarding why iSCSI should define it, because it is required for=20 succinctly describing iSCSI protocol behavior in multi-channel I=5FT nexus = situations (iSCSI and SAS, as we know them today). As mentioned to Eddy=20 yesterday, it (or a concept like it with any other name - this concept is=20 in section 10.6.2 of RFC 3720 as well even though we didn't call it such)=20 is required for iSCSI's proper behavior. Thanks. Mallikarjun=20 ----- Original Message ---- From: Julian Satran To: Mallikarjun C. Cc: IPS ; Julian=5FSatran@il.ibm.com Sent: Saturday, January 6, 2007 6:22:52 AM Subject: Re: Fw: [Ips] Response Fence Flag Mallikarjun & All, As I pointed out in a private discussion with you I never considered in=20 dept the response-fence (beyond what is needed for TM). It is a serious issue for any "transaction type" operations to storage -=20 but the last interface that had all the pieces correctly aligned was the=20 360 channel. SCSI had taken (traditionally) the positions that sequencing and=20 barriers are rarely needed and when needed applications should provide=20 them. And that is exactly what all of the relevant applications do (all=20 transaction monitors, databases etc.). The way all the application handle cases when the start of some SCSI=20 command has to follow the end of a previous set of operations is to just=20 wait for the end of the operations before issuing the "dependent=20 commands". Is this solution optimal? As you probably observed already this solution=20 implies that all the queues in the "stack" (at initiator, transport and=20 target) get empty before the dependent commands can be issued and that=20 is bad for performance. Can fencing (bad name BTW because it is in widespread use for defect=20 isolation) improve this? Yes (by keeping the pipes full!) provided it is=20 associated with rigorous exception handling and the later is a SCSI=20 issue (exceptions will require emptying the queues). With most=20 applications being distributed I doubt also that fencing for a single=20 I=5FT nexus is interesting and coordinating fencing and exception handling = over several I=5FTs is a complex exercise. And as transport alone brings no value to the whole issue - why should=20 we go through the exercise of defining a solution before SCSI has=20 defined one and we are confident that it is good enough and has value?=20 Again I agree that we a mechanism for TM but a good enough mechanism for=20 TM is already in and it gets now even better even without resorting to a=20 generalized fencing/barrier support. Regards, Julo Mallikarjun C. wrote: > Trying again after bouncing (>50KB), tail is now clipped.... > > ----- Forwarded Message ---- > From: Mallikarjun C. > To: ips@ietf.org > Sent: Friday, January 5, 2007 2:40:56 PM > Subject: Re: [Ips] Response Fence Flag > > Hi John, >=20 > As you correctly point out, there are two distinct but related=20 > topics here. >=20 > (1) proper response ordering across participating connections in a=20 > multi-connection session, for a handful of task/TMF responses > (2) proper way to terminate and signal tasks when actions on one=20 > session can impact multiple initiators >=20 > (1) is all about response fence, it is covered separately in section=20 > 3.3 of IG draft. That's what this email thread started off with. >=20 > (2) covers cases that IG had called as as "multi-task abort" cases=20 > that typically have a shared task set across sessions, or are the=20 > result of a Logical Unit Reset TMF. Section 4.1 of IG adresses (2). >=20 > So how are (1) and (2) related? >=20 > - Some cases covered under (2) overlap with (1), but some cases in (2)=20 > are for single connection sessions. E.g. LU Reset on a single=20 > connection session impacting several 3rd party sessions >=20 > - Some cases under (1) overlap with (2), but some cases in (1) have=20 > nothing to do with other sessions. E.g. establishment of ACA on a=20 > non-shared task set >=20 > - Section 4.1 (i.e. text for (2)) uses response fence (i.e. text for=20 > (1)) whenever multi-connection sessions are involved in multi-task=20 > abort situations. >=20 > I hope that clarifies it. Feel free to ask if that is not clear. The=20 > net is that the response fence is the underpinning notion to describe=20 > the correct iSCSI behavior in a few cases and some of those cases are=20 > about task terminations across third-party sessions. >=20 > Mallikarjun >=20 > > >=20 > ----- Original Message ---- > From: John Hufferd > To: Mallikarjun C. ; ips@ietf.org > Sent: Friday, January 5, 2007 1:01:06 PM > Subject: RE: [Ips] Response Fence Flag > > Mallikarjun, > > I must admit, that I have been a bit confused with the direction of=20 > the conversation here. > >=20 > > Therefore, I went back and reviewed the charts from Dallas . And as I=20 > remembered, the initial focus was to address the issue of Multiple=20 > Connections per Session (MC/S) (as stated on chart 4 ? ?Non-issue for=20 > single-connection iSCSI sessions?). So I think I have missed the step=20 > where we have morphed the discussion into one dealing with multiple=20 > sessions. (I am not sure how that happened, or if I miss-read the=20 > charts from Dallas , or have not followed the discussion adequately.) > >=20 > > If we are attempting to define two different issues, one with MC/S and=20 > one with Multiple Session from different Initiators, I think it would=20 > be useful to break down the conversation into Topic A ? MC/S and Topic=20 > B Multiple Sessions. It is possible that one solution will addresses=20 > both, but I for one think I am hearing arguments that might be=20 > appropriate for Topic B, while I am thinking about its applicability=20 > to Topic A. > >=20 > > Perhaps, you could address the issue as either being all about MC/S or=20 > explicitly state that it is intended to affect Multiple Sessions also,=20 > and then address the issues and solution for each separately. For=20 > example, I believe Robert was addressing the issue from a view of=20 > Multiple Sessions and if we only intended to address MC/S then I=20 > expect the response might be somewhat different. > >=20 > > Anyway, if you could clear-up some of this, I think it would be useful=20 > (at least to me). > >=20 > > . > > . > > . > > John L Hufferd > > Sr. Executive Director of Technology > > Brocade Communications Systems, Inc > > jhufferd@brocade.com > > Office Phone: (408) 333-5244; eFAX: (408) 904-4688 > > Alt Office Phone: (408) 997-6136; Cell: (408) 627-9606 > >=20 > > ------------------------------------------------------------------------ > > *From:* Mallikarjun C. [mailto:cb=5Fmallikarjun@yahoo.com] > *Sent:* Friday, January 05, 2007 10:08 AM > *To:* ips@ietf.org > *Subject:* Re: [Ips] Response Fence Flag > >=20 > > Not really. Current draft text is intentionally written to not have=20 > any dependencies on T10 dynamics. The point is that iSCSI needs such=20 > a notion for succinctly describing the proper iSCSI protocol actions=20 > in a few places - ACA, TMF, Persistent reserve/Abort to name a few.=20 > We certainly hope it will be approved by T10 and be a part of SAM-4=20 > soon, but that isn't required per se for describing what iSCSI needs=20 > for its correct behavior. > >=20 > > IPS WG has adopted what it needs in the past - staying ahead of T10=20 > review/approval cycle if necessary. I=5FT nexus loss notification,=20 > iSCSI target/port naming, clearing effects are a few I recall. > >=20 > > Mallikarjun > > > >=20 > > ----- Original Message ---- > From: Eddy Quicksall > To: Robert Snively ; "Elliott, Robert (Server=20 > Storage)" ; ips@ietf.org > Sent: Friday, January 5, 2007 8:58:47 AM > Subject: Re: [Ips] Response Fence Flag > > From an earlier email I think that Response Fence is only a proposal=20 > in T10 (http://www.t10.org:80/doc06.htm=20 > ). If so shouldn't iSCSI wait a bit=20 > until this has been ratified? > >=20 > > Eddy > > > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around > http://mail.yahoo.com > ------------------------------------------------------------------------ > > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F > Ips mailing list > Ips@ietf.org > https://www1.ietf.org/mailman/listinfo/ips >=20 =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around=20 http://mail.yahoo.com=20 =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --=_alternative 005123988525725C_= Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable
Mallikarjun,

I did reffer to the SCSI task atribu= tes and why the ordering attribute is ill conceived as an ordering mechanism. I am repeating here the arguments:
  • based on receiver time ordering (not controlled by application)  makes them unsuitable for applications
  • they are done either on every command or none while applications (transactions) just need a "barrier" between groups


Reponse ordering servs just this as the reponse with the barrier has to be (hold) the last of a group and allows the next group to start.
The ordering of responses is a way f= or an application to achieve a partial ordering in execution.

This is the way I read the draft.


In order to be valuable exceptions h= ave to result in dropping and reissuing all queued commands including the barri= er and after.

As for multi I=5FT=5FL nexuses (or e= ven multi I=5FT) for the barrier to be used/relevant it has to accomodate multi= ple units (nexi) as interesting applications hold multiple nexi.
This accomodation is especially diff= icult in the face on of failures. If this is what scsi had intended it for it looks to me that it is not finished yet (SCSI will need a synchronized barrier accomodating several nexi) and makes whatever we do of questionable value.

I am still OK with how it is written (as I I said before) - my change in mind is only in "if ought to be doing it" (as I doubt its value without additions) or we have to wait for SCSI to finish its work.

For TM we already did what we had to do (without the barrier) and doing the barrier is IMHO premature (although it answers nicely the single nexi issue).

Regards,
Julo


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

06/01/07 17:54

To
IPS <ips@ietf.org>
cc
Subject
Re: Fw: [Ips] Response Fence Flag





Julian,

I am surprised that you have not referred to the SCSI task attributes in the command ordering discussion.  In any case, in the interest of staying on the response fence topic, I will not respond to the command ordering points you made (debate topics for some other time, :-)).

The whole notion of response fence though is all about ordering responses, where such ordering is needed (only a very small % of responses, which are listed in section 3.3.3 of IG draft as we know them today).  The updated draft, which I will forward for publication today, lists one additi= onal case - that of Persistent Reserve/Abort Tasks.

I am not sure of your intended context of how SCSI-level rigorous exception handling relates to response fence.

And yes, response fence is not for cross-session collaboration, it is in fact limited to a single I=5FT=5FL nexus (please refer to section 3.3 of im= plementer's guide).

Regarding why iSCSI should define it, because it is required for succinctly describing iSCSI protocol behavior in multi-channel I=5FT nexus situations (iSCSI and SAS, as we know them today).  As mentioned to Eddy yesterda= y, it (or a concept like it with any other name - this concept is in section 10.6.2 of RFC 3720 as well even though we didn't call it such) is required for iSCSI's proper behavior.

Thanks.

Mallikarjun


----- Original Message ----
From: Julian Satran <julian.satran@gmail.com>
To: Mallikarjun C. <cb=5Fmallikarjun@yahoo.com>
Cc: IPS <ips@ietf.org>; Julian=5FSatran@il.ibm.com
Sent: Saturday, January 6, 2007 6:22:52 AM
Subject: Re: Fw: [Ips] Response Fence Flag

Mallikarjun & All,

As I pointed out in a private discussion with you I never considered in
dept the response-fence (beyond what is needed for TM).
It is a serious issue for any "transaction type" operations to storage -
but the last interface that had all the pieces correctly aligned was the
360 channel.
SCSI had taken (traditionally) the positions that sequencing and
barriers are rarely needed and when needed applications should provide them.
And that is exactly what all of the relevant applications do (all
transaction monitors, databases etc.).

The way all the application handle cases when the start of some SCSI
command has to follow the end of a previous set of operations is to just
wait for the end of the operations before issuing the "dependent comma= nds".

Is this solution optimal? As you probably observed already this solution
implies that all the queues in the "stack" (at initiator, transpo= rt and
target) get empty before the dependent commands can be issued and that
is bad for performance.

Can fencing (bad name BTW because it is in widespread use for defect
isolation) improve this? Yes (by keeping the pipes full!) provided it is
associated with rigorous exception handling and the later is a SCSI
issue (exceptions will require emptying the queues). With most
applications being distributed I doubt also that fencing for a single
I=5FT nexus is interesting and coordinating fencing and exception handling
over several I=5FTs is a complex exercise.

And as transport alone brings no value to the whole issue - why  should
we go through the exercise of defining a solution before SCSI has
defined one and we are confident that it is good enough and has value?
Again I agree that we a mechanism for TM but a good enough mechanism for
TM is already in and it gets now even better even without resorting to a
generalized fencing/barrier support.

Regards,
Julo








Mallikarjun C. wrote:
> Trying again after bouncing (>50KB), tail is now clipped....
>
> ----- Forwarded Message ----
> From: Mallikarjun C. <cb=5Fmallikarjun@yahoo.com>
> To: ips@ietf.org
> Sent: Friday, January 5, 2007 2:40:56 PM
> Subject: Re: [Ips] Response Fence Flag
>
> Hi John,
>  
> As you correctly point out, there are two distinct but related
> topics here.
>  
> (1) proper response ordering across participating connections in a
> multi-connection session, for a handful of task/TMF responses
> (2) proper way to terminate and signal tasks when actions on one
> session can impact multiple initiators
>  
> (1) is all about response fence, it is covered separately in section
> 3.3 of IG draft.  That's what this email thread started off with.=
>  
> (2) covers cases that IG had called as as "multi-task abort" cases
> that typically have a shared task set across sessions, or are the
> result of a Logical Unit Reset TMF.  Section 4.1 of IG adresses (2).
>  
> So how are (1) and (2) related?
>  
> - Some cases covered under (2) overlap with (1), but some cases in (2)
> are for single connection sessions.  E.g. LU Reset on a single
> connection session impacting several 3rd party sessions
>  
> - Some cases under (1) overlap with (2), but some cases in (1) have
> nothing to do with other sessions.  E.g. establishment of ACA on a
> non-shared task set
>  
> - Section 4.1 (i.e. text for (2)) uses response fence (i.e. text for
> (1)) whenever multi-connection sessions are involved in multi-task
> abort situations.
>  
> I hope that clarifies it.  Feel free to ask if that is not clear.  The
> net is that the response fence is the underpinning notion to describe
> the correct iSCSI behavior in a few cases and some of those cases are
> about task terminations across third-party sessions.
>  
> Mallikarjun
>  
>
>
>  
> ----- Original Message ----
> From: John Hufferd <jhufferd@Brocade.COM>
> To: Mallikarjun C. <cb=5Fmallikarjun@yahoo.com>; ips@ietf.org
> Sent: Friday, January 5, 2007 1:01:06 PM
> Subject: RE: [Ips] Response Fence Flag
>
> Mallikarjun,
>
> I must admit, that I have been a bit confused with the direction of
> the conversation here.
>
>  
>
> Therefore, I went back and reviewed the charts from Dallas .  And as I
> remembered, the initial focus was to address the issue of Multiple
> Connections per Session (MC/S) (as stated on chart 4 – “No= n-issue for
> single-connection iSCSI sessions”).  So I think I have miss= ed the step
> where we have morphed the discussion into one dealing with multiple
> sessions.  (I am not sure how that happened, or if I miss-read the
> charts from Dallas , or have not followed the discussion adequately.)<= br> >
>  
>
> If we are attempting to define two different issues, one with MC/S and
> one with Multiple Session from different Initiators, I think it would
> be useful to break down the conversation into Topic A – MC/S and Topic
> B Multiple Sessions.  It is possible that one solution will addre= sses
> both, but I for one think I am hearing arguments that might be
> appropriate for Topic B, while I am thinking about its applicability
> to Topic A.
>
>  
>
> Perhaps, you could address the issue as either being all about MC/S or
> explicitly state that it is intended to affect Multiple Sessions also,
> and then address the issues and solution for each separately.  For
> example, I believe Robert was addressing the issue from a view of
> Multiple Sessions and if we only intended to address MC/S then I
> expect the response might be somewhat different.
>
>  
>
> Anyway, if you could clear-up some of this, I think it would be useful
> (at least to me).
>
>  
>
> .
>
> .
>
> .
>
> John L Hufferd
>
> Sr. Executive Director of Technology
>
> Brocade Communications Systems, Inc
>
> jhufferd@brocade.com <mailto:jhufferd@brocade.com>
>
> Office Phone: (408) 333-5244; eFAX: (408) 904-4688
>
> Alt Office Phone: (408) 997-6136; Cell: (408) 627-9606
>
>  
>
> ----------------------------------------------------------------------= --
>
> *From:* Mallikarjun C. [mailto:cb=5Fmallikarjun@yahoo.com]
> *Sent:* Friday, January 05, 2007 10:08 AM
> *To:* ips@ietf.org
> *Subject:* Re: [Ips] Response Fence Flag
>
>  
>
> Not really.  Current draft text is intentionally written to not have
> any dependencies on T10 dynamics.  The point is that iSCSI needs such
> a notion for succinctly describing the proper iSCSI protocol actions
> in a few places - ACA, TMF, Persistent reserve/Abort to name a few.  
> We certainly hope it will be approved by T10 and be a part of SAM-4
> soon, but that isn't required per se for describing what iSCSI needs
> for its correct behavior.
>
>  
>
> IPS WG has adopted what it needs in the past - staying ahead of T10
> review/approval cycle if necessary.  I=5FT nexus loss notificatio= n,
> iSCSI target/port naming, clearing effects are a few I recall.
>
>  
>
> Mallikarjun
>
>
>
>  
>
> ----- Original Message ----
> From: Eddy Quicksall <Quicksall=5FiSCSI@Bellsouth.net>
> To: Robert Snively <rsnively@Brocade.COM>; "Elliott, Robert (Server
> Storage)" <Elliott@hp.com>; ips@ietf.org
> Sent: Friday, January 5, 2007 8:58:47 AM
> Subject: Re: [Ips] Response Fence Flag
>
> From an earlier email I think that Response Fence is only a proposal
> in T10 (http://www.t10.org:80/doc06.htm
> <http://www.t10.org/doc06.htm>). If so shouldn't iSCSI wait a bit
> until this has been ratified?
>
>  
>
> Eddy
>
>
> =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F
> Do You Yahoo!?
> Tired of spam? Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
> ----------------------------------------------------------------------= --
>
> =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
> Ips mailing list
> Ips@ietf.org
> https://www1.ietf.org/mailman/listinfo/ips
>  





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

=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
Ips mailing list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips
--=_alternative 005123988525725C_=-- --===============0431690396== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============0431690396==-- From ips-bounces@ietf.org Sun Jan 07 10:40:28 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3a87-0004Kj-MY; Sun, 07 Jan 2007 10:40:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3a87-0004JY-43 for ips@ietf.org; Sun, 07 Jan 2007 10:40:15 -0500 Received: from imf25aec.mail.bellsouth.net ([205.152.59.73]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H3a7m-0005LY-D2 for ips@ietf.org; Sun, 07 Jan 2007 10:40:15 -0500 Received: from ibm69aec.bellsouth.net ([74.245.52.54]) by imf25aec.mail.bellsouth.net with ESMTP id <20070107153954.XHNV21237.imf25aec.mail.bellsouth.net@ibm69aec.bellsouth.net> for ; Sun, 7 Jan 2007 10:39:54 -0500 Received: from IVVTDKV0981 ([74.245.52.54]) by ibm69aec.bellsouth.net with SMTP id <20070107153952.PVEL14910.ibm69aec.bellsouth.net@IVVTDKV0981>; Sun, 7 Jan 2007 10:39:52 -0500 Message-ID: <001001c73272$123c49f0$01faa8c0@ivivity.com> From: "Eddy Quicksall" To: "Mallikarjun C." , "Julian Satran" References: Subject: Re: Fw: [Ips] Response Fence Flag Date: Sun, 7 Jan 2007 10:39:48 -0500 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.7 (/) X-Scan-Signature: 6a5c486139a804859f37cd11eb5255b5 Cc: IPS X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0307524927==" Errors-To: ips-bounces@ietf.org This is a multi-part message in MIME format. --===============0307524927== Content-Type: multipart/alternative; boundary="----=_NextPart_000_000D_01C73248.2754A000" This is a multi-part message in MIME format. ------=_NextPart_000_000D_01C73248.2754A000 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Maybe this was already mentioned but wouldn't the Response Fence be = necessary for even commands with ordered tags? If an ordered command were sent on one connection then an ordered = command were sent on another connection, the response for the 2nd = ordered command may get back to the initiator before the response for = the first ordered command. But that is not what would be expected by the = initiator. A case for this could also be made regarding one or more = simples followed by an ordered. Eddy ----- Original Message -----=20 From: Julian Satran=20 To: Mallikarjun C.=20 Cc: IPS=20 Sent: Sunday, January 07, 2007 9:46 AM Subject: Re: Fw: [Ips] Response Fence Flag Mallikarjun,=20 I did reffer to the SCSI task atributes and why the ordering attribute = is ill conceived as an ordering mechanism. I am repeating here the = arguments:=20 a.. based on receiver time ordering (not controlled by application) = makes them unsuitable for applications=20 b.. they are done either on every command or none while applications = (transactions) just need a "barrier" between groups Reponse ordering servs just this as the reponse with the barrier has = to be (hold) the last of a group and allows the next group to start.=20 The ordering of responses is a way for an application to achieve a = partial ordering in execution.=20 This is the way I read the draft.=20 In order to be valuable exceptions have to result in dropping and = reissuing all queued commands including the barrier and after.=20 As for multi I_T_L nexuses (or even multi I_T) for the barrier to be = used/relevant it has to accomodate multiple units (nexi) as interesting = applications hold multiple nexi.=20 This accomodation is especially difficult in the face on of failures. = If this is what scsi had intended it for it looks to me that it is not = finished yet (SCSI will need a synchronized barrier accomodating several = nexi) and makes whatever we do of questionable value.=20 I am still OK with how it is written (as I I said before) - my change = in mind is only in "if ought to be doing it" (as I doubt its value = without additions) or we have to wait for SCSI to finish its work.=20 For TM we already did what we had to do (without the barrier) and = doing the barrier is IMHO premature (although it answers nicely the = single nexi issue).=20 Regards,=20 Julo=20 "Mallikarjun C." =20 06/01/07 17:54=20 To IPS =20 cc =20 Subject Re: Fw: [Ips] Response Fence Flag=20 =20 =20 Julian, I am surprised that you have not referred to the SCSI task attributes = in the command ordering discussion. In any case, in the interest of = staying on the response fence topic, I will not respond to the command = ordering points you made (debate topics for some other time, :-)). The whole notion of response fence though is all about ordering = responses, where such ordering is needed (only a very small % of = responses, which are listed in section 3.3.3 of IG draft as we know them = today). The updated draft, which I will forward for publication today, = lists one additional case - that of Persistent Reserve/Abort Tasks. I am not sure of your intended context of how SCSI-level rigorous = exception handling relates to response fence. And yes, response fence is not for cross-session collaboration, it is = in fact limited to a single I_T_L nexus (please refer to section 3.3 of = implementer's guide). Regarding why iSCSI should define it, because it is required for = succinctly describing iSCSI protocol behavior in multi-channel I_T nexus = situations (iSCSI and SAS, as we know them today). As mentioned to Eddy = yesterday, it (or a concept like it with any other name - this concept = is in section 10.6.2 of RFC 3720 as well even though we didn't call it = such) is required for iSCSI's proper behavior. Thanks. Mallikarjun=20 ----- Original Message ---- From: Julian Satran To: Mallikarjun C. Cc: IPS ; Julian_Satran@il.ibm.com Sent: Saturday, January 6, 2007 6:22:52 AM Subject: Re: Fw: [Ips] Response Fence Flag Mallikarjun & All, As I pointed out in a private discussion with you I never considered = in=20 dept the response-fence (beyond what is needed for TM). It is a serious issue for any "transaction type" operations to storage = -=20 but the last interface that had all the pieces correctly aligned was = the=20 360 channel. SCSI had taken (traditionally) the positions that sequencing and=20 barriers are rarely needed and when needed applications should provide = them. And that is exactly what all of the relevant applications do (all=20 transaction monitors, databases etc.). The way all the application handle cases when the start of some SCSI=20 command has to follow the end of a previous set of operations is to = just=20 wait for the end of the operations before issuing the "dependent = commands". Is this solution optimal? As you probably observed already this = solution=20 implies that all the queues in the "stack" (at initiator, transport = and=20 target) get empty before the dependent commands can be issued and that = is bad for performance. Can fencing (bad name BTW because it is in widespread use for defect=20 isolation) improve this? Yes (by keeping the pipes full!) provided it = is=20 associated with rigorous exception handling and the later is a SCSI=20 issue (exceptions will require emptying the queues). With most=20 applications being distributed I doubt also that fencing for a single=20 I_T nexus is interesting and coordinating fencing and exception = handling=20 over several I_Ts is a complex exercise. And as transport alone brings no value to the whole issue - why = should=20 we go through the exercise of defining a solution before SCSI has=20 defined one and we are confident that it is good enough and has value? = Again I agree that we a mechanism for TM but a good enough mechanism = for=20 TM is already in and it gets now even better even without resorting to = a=20 generalized fencing/barrier support. Regards, Julo Mallikarjun C. wrote: > Trying again after bouncing (>50KB), tail is now clipped.... > > ----- Forwarded Message ---- > From: Mallikarjun C. > To: ips@ietf.org > Sent: Friday, January 5, 2007 2:40:56 PM > Subject: Re: [Ips] Response Fence Flag > > Hi John, > =20 > As you correctly point out, there are two distinct but related=20 > topics here. > =20 > (1) proper response ordering across participating connections in a=20 > multi-connection session, for a handful of task/TMF responses > (2) proper way to terminate and signal tasks when actions on one=20 > session can impact multiple initiators > =20 > (1) is all about response fence, it is covered separately in section = > 3.3 of IG draft. That's what this email thread started off with. > =20 > (2) covers cases that IG had called as as "multi-task abort" cases=20 > that typically have a shared task set across sessions, or are the=20 > result of a Logical Unit Reset TMF. Section 4.1 of IG adresses (2). > =20 > So how are (1) and (2) related? > =20 > - Some cases covered under (2) overlap with (1), but some cases in = (2)=20 > are for single connection sessions. E.g. LU Reset on a single=20 > connection session impacting several 3rd party sessions > =20 > - Some cases under (1) overlap with (2), but some cases in (1) have=20 > nothing to do with other sessions. E.g. establishment of ACA on a=20 > non-shared task set > =20 > - Section 4.1 (i.e. text for (2)) uses response fence (i.e. text for = > (1)) whenever multi-connection sessions are involved in multi-task=20 > abort situations. > =20 > I hope that clarifies it. Feel free to ask if that is not clear. = The=20 > net is that the response fence is the underpinning notion to = describe=20 > the correct iSCSI behavior in a few cases and some of those cases = are=20 > about task terminations across third-party sessions. > =20 > Mallikarjun > =20 > > > =20 > ----- Original Message ---- > From: John Hufferd > To: Mallikarjun C. ; ips@ietf.org > Sent: Friday, January 5, 2007 1:01:06 PM > Subject: RE: [Ips] Response Fence Flag > > Mallikarjun, > > I must admit, that I have been a bit confused with the direction of=20 > the conversation here. > > =20 > > Therefore, I went back and reviewed the charts from Dallas . And as = I=20 > remembered, the initial focus was to address the issue of Multiple=20 > Connections per Session (MC/S) (as stated on chart 4 - "Non-issue = for=20 > single-connection iSCSI sessions"). So I think I have missed the = step=20 > where we have morphed the discussion into one dealing with multiple=20 > sessions. (I am not sure how that happened, or if I miss-read the=20 > charts from Dallas , or have not followed the discussion = adequately.) > > =20 > > If we are attempting to define two different issues, one with MC/S = and=20 > one with Multiple Session from different Initiators, I think it = would=20 > be useful to break down the conversation into Topic A - MC/S and = Topic=20 > B Multiple Sessions. It is possible that one solution will = addresses=20 > both, but I for one think I am hearing arguments that might be=20 > appropriate for Topic B, while I am thinking about its applicability = > to Topic A. > > =20 > > Perhaps, you could address the issue as either being all about MC/S = or=20 > explicitly state that it is intended to affect Multiple Sessions = also,=20 > and then address the issues and solution for each separately. For=20 > example, I believe Robert was addressing the issue from a view of=20 > Multiple Sessions and if we only intended to address MC/S then I=20 > expect the response might be somewhat different. > > =20 > > Anyway, if you could clear-up some of this, I think it would be = useful=20 > (at least to me). > > =20 > > . > > . > > . > > John L Hufferd > > Sr. Executive Director of Technology > > Brocade Communications Systems, Inc > > jhufferd@brocade.com > > Office Phone: (408) 333-5244; eFAX: (408) 904-4688 > > Alt Office Phone: (408) 997-6136; Cell: (408) 627-9606 > > =20 > > = ------------------------------------------------------------------------ > > *From:* Mallikarjun C. [mailto:cb_mallikarjun@yahoo.com] > *Sent:* Friday, January 05, 2007 10:08 AM > *To:* ips@ietf.org > *Subject:* Re: [Ips] Response Fence Flag > > =20 > > Not really. Current draft text is intentionally written to not have = > any dependencies on T10 dynamics. The point is that iSCSI needs = such=20 > a notion for succinctly describing the proper iSCSI protocol actions = > in a few places - ACA, TMF, Persistent reserve/Abort to name a few. = > We certainly hope it will be approved by T10 and be a part of SAM-4=20 > soon, but that isn't required per se for describing what iSCSI needs = > for its correct behavior. > > =20 > > IPS WG has adopted what it needs in the past - staying ahead of T10=20 > review/approval cycle if necessary. I_T nexus loss notification,=20 > iSCSI target/port naming, clearing effects are a few I recall. > > =20 > > Mallikarjun > > > > =20 > > ----- Original Message ---- > From: Eddy Quicksall > To: Robert Snively ; "Elliott, Robert (Server=20 > Storage)" ; ips@ietf.org > Sent: Friday, January 5, 2007 8:58:47 AM > Subject: Re: [Ips] Response Fence Flag > > From an earlier email I think that Response Fence is only a proposal = > in T10 (http://www.t10.org:80/doc06.htm=20 > ). If so shouldn't iSCSI wait a bit=20 > until this has been ratified? > > =20 > > Eddy > > > __________________________________________________ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around > http://mail.yahoo.com > = ------------------------------------------------------------------------ > > _______________________________________________ > Ips mailing list > Ips@ietf.org > https://www1.ietf.org/mailman/listinfo/ips > =20 __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around=20 http://mail.yahoo.com=20 _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips -------------------------------------------------------------------------= ----- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips ------=_NextPart_000_000D_01C73248.2754A000 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Maybe this was already mentioned but wouldn't the = Response=20 Fence be necessary for even commands with ordered = tags?
 
If an ordered command were sent on one = connection=20 then an ordered command were sent on another connection, the response = for the=20 2nd ordered command may get back to the initiator before the = response for=20 the first ordered command. But that is not what would be expected = by the=20 initiator. A case for this could also be made regarding one or more = simples=20 followed by an ordered.
 
Eddy
----- Original Message -----
From:=20 Julian Satran
Cc: IPS
Sent: Sunday, January 07, 2007 = 9:46=20 AM
Subject: Re: Fw: [Ips] Response = Fence=20 Flag


Mallikarjun,=20

I did reffer to the SCSI task = atributes=20 and why the ordering attribute is ill conceived as an ordering = mechanism. I am=20 repeating here the arguments:
  • based on receiver time ordering = (not=20 controlled by application)  makes them unsuitable for = applications=20
  • they are done either on every = command or=20 none while applications (transactions) just need a "barrier" between = groups


Reponse ordering=20 servs just this as the reponse with the barrier has to be (hold) the = last of a=20 group and allows the next group to start.
The ordering of responses is a way for an application to = achieve a=20 partial ordering in execution.

This is the way I read the draft.


In order to be valuable exceptions have to = result in=20 dropping and reissuing all queued commands including the barrier and=20 after.

As for multi = I_T_L nexuses=20 (or even multi I_T) for the barrier to be used/relevant it has to = accomodate=20 multiple units (nexi) as interesting applications hold multiple = nexi.=20
This accomodation is especially = difficult in=20 the face on of failures. If this is what scsi had intended it for it = looks to=20 me that it is not finished yet (SCSI will need a synchronized barrier=20 accomodating several nexi) and makes whatever we do of questionable=20 value.

I am still OK = with how it=20 is written (as I I said before) - my change in mind is only in "if = ought to be=20 doing it" (as I doubt its value without additions) or we have to wait = for SCSI=20 to finish its work.

For TM we=20 already did what we had to do (without the barrier) and doing the = barrier is=20 IMHO premature (although it answers nicely the single nexi = issue).=20

Regards,
Julo


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

06/01/07 17:54

To
IPS = <ips@ietf.org>=20
cc
Subject
Re: Fw: [Ips] Response = Fence=20 Flag

=




Julian,

I am surprised that you have not referred to = the SCSI=20 task attributes in the command ordering discussion.  In any case, = in the=20 interest of staying on the response fence topic, I will not respond to = the=20 command ordering points you made (debate topics for some other time,=20 :-)).

The whole notion of response fence though is all about = ordering=20 responses, where such ordering is needed (only a very small % of = responses,=20 which are listed in section 3.3.3 of IG draft as we know them today).=20  The updated draft, which I will forward for publication today, = lists one=20 additional case - that of Persistent Reserve/Abort Tasks.

I am = not sure=20 of your intended context of how SCSI-level rigorous exception handling = relates=20 to response fence.

And yes, response fence is not for = cross-session=20 collaboration, it is in fact limited to a single I_T_L nexus (please = refer to=20 section 3.3 of implementer's guide).

Regarding why iSCSI should = define=20 it, because it is required for succinctly describing iSCSI protocol = behavior=20 in multi-channel I_T nexus situations (iSCSI and SAS, as we know them = today).=20  As mentioned to Eddy yesterday, it (or a concept like it with = any other=20 name - this concept is in section 10.6.2 of RFC 3720 as well even = though we=20 didn't call it such) is required for iSCSI's proper=20 behavior.

Thanks.

Mallikarjun


----- Original = Message=20 ----
From: Julian Satran <julian.satran@gmail.com>
To: = Mallikarjun=20 C. <cb_mallikarjun@yahoo.com>
Cc: IPS <ips@ietf.org>;=20 Julian_Satran@il.ibm.com
Sent: Saturday, January 6, 2007 6:22:52=20 AM
Subject: Re: Fw: [Ips] Response Fence Flag

Mallikarjun = &=20 All,

As I pointed out in a private discussion with you I never=20 considered in
dept the response-fence (beyond what is needed for=20 TM).
It is a serious issue for any "transaction type" operations to = storage=20 -
but the last interface that had all the pieces correctly aligned = was the=20
360 channel.
SCSI had taken (traditionally) the positions that=20 sequencing and
barriers are rarely needed and when needed = applications=20 should provide them.
And that is exactly what all of the relevant=20 applications do (all
transaction monitors, databases = etc.).

The way=20 all the application handle cases when the start of some SCSI =
command has=20 to follow the end of a previous set of operations is to just
wait = for the=20 end of the operations before issuing the "dependent = commands".

Is this=20 solution optimal? As you probably observed already this solution =
implies=20 that all the queues in the "stack" (at initiator, transport and =
target)=20 get empty before the dependent commands can be issued and that
is = bad for=20 performance.

Can fencing (bad name BTW because it is in = widespread use=20 for defect
isolation) improve this? Yes (by keeping the pipes = full!)=20 provided it is
associated with rigorous exception handling and the = later=20 is a SCSI
issue (exceptions will require emptying the queues). = With most=20
applications being distributed I doubt also that fencing for a = single=20
I_T nexus is interesting and coordinating fencing and exception = handling=20
over several I_Ts is a complex exercise.

And as transport = alone=20 brings no value to the whole issue - why  should
we go = through the=20 exercise of defining a solution before SCSI has
defined one and we = are=20 confident that it is good enough and has value?
Again I agree that = we a=20 mechanism for TM but a good enough mechanism for
TM is already in = and it=20 gets now even better even without resorting to a
generalized=20 fencing/barrier=20 = support.

Regards,
Julo








Malli= karjun=20 C. wrote:
> Trying again after bouncing (>50KB), tail is now=20 clipped....
>
> ----- Forwarded Message ----
> From: = Mallikarjun C. <cb_mallikarjun@yahoo.com>
> To:=20 ips@ietf.org
> Sent: Friday, January 5, 2007 2:40:56 PM
> = Subject:=20 Re: [Ips] Response Fence Flag
>
> Hi John,
> =  
>=20 As you correctly point out, there are two distinct but related =
> topics=20 here.
>  
> (1) proper response ordering across = participating=20 connections in a
> multi-connection session, for a handful of = task/TMF=20 responses
> (2) proper way to terminate and signal tasks when = actions on=20 one
> session can impact multiple initiators
> =  
> (1)=20 is all about response fence, it is covered separately in section =
> 3.3=20 of IG draft.  That's what this email thread started off = with.
>=20  
> (2) covers cases that IG had called as as "multi-task = abort"=20 cases
> that typically have a shared task set across sessions, = or are=20 the
> result of a Logical Unit Reset TMF.  Section 4.1 of = IG=20 adresses (2).
>  
> So how are (1) and (2) = related?
>=20  
> - Some cases covered under (2) overlap with (1), but = some cases=20 in (2)
> are for single connection sessions.  E.g. LU = Reset on a=20 single
> connection session impacting several 3rd party=20 sessions
>  
> - Some cases under (1) overlap with = (2), but=20 some cases in (1) have
> nothing to do with other sessions. =  E.g.=20 establishment of ACA on a
> non-shared task set
> =  
>=20 - Section 4.1 (i.e. text for (2)) uses response fence (i.e. text for =
>=20 (1)) whenever multi-connection sessions are involved in multi-task =
>=20 abort situations.
>  
> I hope that clarifies it. =  Feel=20 free to ask if that is not clear.  The
> net is that the = response=20 fence is the underpinning notion to describe
> the correct = iSCSI=20 behavior in a few cases and some of those cases are
> about = task=20 terminations across third-party sessions.
>  
>=20 Mallikarjun
>  
>
>
>  
> = -----=20 Original Message ----
> From: John Hufferd=20 <jhufferd@Brocade.COM>
> To: Mallikarjun C.=20 <cb_mallikarjun@yahoo.com>; ips@ietf.org
> Sent: Friday, = January=20 5, 2007 1:01:06 PM
> Subject: RE: [Ips] Response Fence=20 Flag
>
> Mallikarjun,
>
> I must admit, that I = have=20 been a bit confused with the direction of
> the conversation=20 here.
>
>  
>
> Therefore, I went back = and=20 reviewed the charts from Dallas .  And as I
> remembered, = the=20 initial focus was to address the issue of Multiple
> = Connections per=20 Session (MC/S) (as stated on chart 4 =96 =93Non-issue for
>=20 single-connection iSCSI sessions=94).  So I think I have missed = the step=20
> where we have morphed the discussion into one dealing with = multiple=20
> sessions.  (I am not sure how that happened, or if I = miss-read=20 the
> charts from Dallas , or have not followed the discussion=20 adequately.)
>
>  
>
> If we are = attempting to=20 define two different issues, one with MC/S and
> one with = Multiple=20 Session from different Initiators, I think it would
> be useful = to=20 break down the conversation into Topic A =96 MC/S and Topic
> B = Multiple=20 Sessions.  It is possible that one solution will addresses =
> both,=20 but I for one think I am hearing arguments that might be
> = appropriate=20 for Topic B, while I am thinking about its applicability
> to = Topic=20 A.
>
>  
>
> Perhaps, you could address = the issue=20 as either being all about MC/S or
> explicitly state that it is = intended to affect Multiple Sessions also,
> and then address = the=20 issues and solution for each separately.  For
> example, I = believe=20 Robert was addressing the issue from a view of
> Multiple = Sessions and=20 if we only intended to address MC/S then I
> expect the = response might=20 be somewhat different.
>
>  
>
> Anyway, = if you=20 could clear-up some of this, I think it would be useful
> (at = least to=20 me).
>
>  
>
> .
>
>=20 .
>
> .
>
> John L Hufferd
>
> Sr. = Executive Director of Technology
>
> Brocade = Communications=20 Systems, Inc
>
> jhufferd@brocade.com=20 <mailto:jhufferd@brocade.com>
>
> Office Phone: = (408)=20 333-5244; eFAX: (408) 904-4688
>
> Alt Office Phone: (408) = 997-6136; Cell: (408) 627-9606
>
>  
>
>=20 = ------------------------------------------------------------------------<= BR>>
>=20 *From:* Mallikarjun C. [mailto:cb_mallikarjun@yahoo.com]
> = *Sent:*=20 Friday, January 05, 2007 10:08 AM
> *To:* ips@ietf.org
>=20 *Subject:* Re: [Ips] Response Fence Flag
>
>=20  
>
> Not really.  Current draft text is = intentionally=20 written to not have
> any dependencies on T10 dynamics. =  The point=20 is that iSCSI needs such
> a notion for succinctly describing = the=20 proper iSCSI protocol actions
> in a few places - ACA, TMF, = Persistent=20 reserve/Abort to name a few.  
> We certainly hope it will = be=20 approved by T10 and be a part of SAM-4
> soon, but that isn't = required=20 per se for describing what iSCSI needs
> for its correct=20 behavior.
>
>  
>
> IPS WG has adopted = what it=20 needs in the past - staying ahead of T10
> review/approval = cycle if=20 necessary.  I_T nexus loss notification,
> iSCSI = target/port=20 naming, clearing effects are a few I recall.
>
>=20  
>
> Mallikarjun
>
>
>
>=20  
>
> ----- Original Message ----
> From: Eddy=20 Quicksall <Quicksall_iSCSI@Bellsouth.net>
> To: Robert = Snively=20 <rsnively@Brocade.COM>; "Elliott, Robert (Server
> = Storage)"=20 <Elliott@hp.com>; ips@ietf.org
> Sent: Friday, January 5, = 2007=20 8:58:47 AM
> Subject: Re: [Ips] Response Fence = Flag
>
> From=20 an earlier email I think that Response Fence is only a proposal =
> in=20 T10 (http://www.t10.org:80/doc06.htm
>=20 <http://www.t10.org/doc06.htm>). If so shouldn't iSCSI wait a = bit=20
> until this has been ratified?
>
> =  
>
>=20 Eddy
>
>
>=20 __________________________________________________
> Do You=20 Yahoo!?
> Tired of spam? Yahoo! Mail has the best spam = protection=20 around
> http://mail.yahoo.com
>=20 = ------------------------------------------------------------------------<= BR>>
>=20 _______________________________________________
> Ips mailing=20 list
> Ips@ietf.org
>=20 https://www1.ietf.org/mailman/listinfo/ips
>  =20 =





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

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

_______________________________________________
Ips mailing=20 = list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips
------=_NextPart_000_000D_01C73248.2754A000-- --===============0307524927== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============0307524927==-- From ips-bounces@ietf.org Sun Jan 07 11:04:36 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3aVO-0004Wr-26; Sun, 07 Jan 2007 11:04:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3aVM-0004Ro-Ox for ips@ietf.org; Sun, 07 Jan 2007 11:04:16 -0500 Received: from mtagate5.de.ibm.com ([195.212.29.154]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H3aVI-0003Ox-5C for ips@ietf.org; Sun, 07 Jan 2007 11:04:16 -0500 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate5.de.ibm.com (8.13.8/8.13.8) with ESMTP id l07G4BA6060208 for ; Sun, 7 Jan 2007 16:04:11 GMT Received: from d12av02.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1607.megacenter.de.ibm.com (8.13.6/8.13.6/NCO v8.1.1) with ESMTP id l07G4B7R2855108 for ; Sun, 7 Jan 2007 17:04:11 +0100 Received: from d12av02.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l07G4B5T003094 for ; Sun, 7 Jan 2007 17:04:11 +0100 Received: from d12mc102.megacenter.de.ibm.com (d12mc102.megacenter.de.ibm.com [9.149.167.114]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l07G4Bcs003089 for ; Sun, 7 Jan 2007 17:04:11 +0100 In-Reply-To: <001001c73272$123c49f0$01faa8c0@ivivity.com> To: "Eddy Quicksall" MIME-Version: 1.0 Subject: Re: Fw: [Ips] Response Fence Flag X-Mailer: Lotus Notes Release 7.0.2 September 26, 2006 From: Julian Satran Message-ID: Date: Sun, 7 Jan 2007 11:04:08 -0500 X-MIMETrack: Serialize by Router on D12MC102/12/M/IBM(Release 7.0.2HF71 | November 3, 2006) at 07/01/2007 18:04:10, Serialize complete at 07/01/2007 18:04:10 X-Spam-Score: 0.5 (/) X-Scan-Signature: af7c9eab0f208726cc6b32d194122b96 Cc: IPS X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1883707586==" Errors-To: ips-bounces@ietf.org This is a multipart message in MIME format. --===============1883707586== Content-Type: multipart/alternative; boundary="=_alternative 005840C08525725C_=" This is a multipart message in MIME format. --=_alternative 005840C08525725C_= Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Odered commands guarantee a complete ordered excution at the target (in=20 the order the commands are received by the target). Unordered responses=20 can be expected (as the standards are completely mute about them). The=20 trouble is that the appliaction has no control about the order the=20 commands are received at the target. Julo "Eddy Quicksall" =20 07/01/07 10:39 To "Mallikarjun C." , Julian Satran/Haifa/IBM@IBMIL cc "IPS" Subject Re: Fw: [Ips] Response Fence Flag Maybe this was already mentioned but wouldn't the Response Fence be=20 necessary for even commands with ordered tags? =20 If an ordered command were sent on one connection then an ordered command=20 were sent on another connection, the response for the 2nd ordered command=20 may get back to the initiator before the response for the first ordered=20 command. But that is not what would be expected by the initiator. A case=20 for this could also be made regarding one or more simples followed by an=20 ordered. =20 Eddy ----- Original Message -----=20 From: Julian Satran=20 To: Mallikarjun C.=20 Cc: IPS=20 Sent: Sunday, January 07, 2007 9:46 AM Subject: Re: Fw: [Ips] Response Fence Flag Mallikarjun,=20 I did reffer to the SCSI task atributes and why the ordering attribute is=20 ill conceived as an ordering mechanism. I am repeating here the arguments: = based on receiver time ordering (not controlled by application) makes=20 them unsuitable for applications=20 they are done either on every command or none while applications=20 (transactions) just need a "barrier" between groups Reponse ordering servs just this as the reponse with the barrier has to be = (hold) the last of a group and allows the next group to start.=20 The ordering of responses is a way for an application to achieve a partial = ordering in execution.=20 This is the way I read the draft.=20 In order to be valuable exceptions have to result in dropping and=20 reissuing all queued commands including the barrier and after.=20 As for multi I=5FT=5FL nexuses (or even multi I=5FT) for the barrier to be = used/relevant it has to accomodate multiple units (nexi) as interesting=20 applications hold multiple nexi.=20 This accomodation is especially difficult in the face on of failures. If=20 this is what scsi had intended it for it looks to me that it is not=20 finished yet (SCSI will need a synchronized barrier accomodating several=20 nexi) and makes whatever we do of questionable value.=20 I am still OK with how it is written (as I I said before) - my change in=20 mind is only in "if ought to be doing it" (as I doubt its value without=20 additions) or we have to wait for SCSI to finish its work.=20 For TM we already did what we had to do (without the barrier) and doing=20 the barrier is IMHO premature (although it answers nicely the single nexi=20 issue).=20 Regards,=20 Julo=20 "Mallikarjun C." =20 06/01/07 17:54=20 To IPS =20 cc Subject Re: Fw: [Ips] Response Fence Flag Julian, I am surprised that you have not referred to the SCSI task attributes in=20 the command ordering discussion. In any case, in the interest of staying=20 on the response fence topic, I will not respond to the command ordering=20 points you made (debate topics for some other time, :-)). The whole notion of response fence though is all about ordering responses, = where such ordering is needed (only a very small % of responses, which are = listed in section 3.3.3 of IG draft as we know them today). The updated=20 draft, which I will forward for publication today, lists one additional=20 case - that of Persistent Reserve/Abort Tasks. I am not sure of your intended context of how SCSI-level rigorous=20 exception handling relates to response fence. And yes, response fence is not for cross-session collaboration, it is in=20 fact limited to a single I=5FT=5FL nexus (please refer to section 3.3 of=20 implementer's guide). Regarding why iSCSI should define it, because it is required for=20 succinctly describing iSCSI protocol behavior in multi-channel I=5FT nexus = situations (iSCSI and SAS, as we know them today). As mentioned to Eddy=20 yesterday, it (or a concept like it with any other name - this concept is=20 in section 10.6.2 of RFC 3720 as well even though we didn't call it such)=20 is required for iSCSI's proper behavior. Thanks. Mallikarjun=20 ----- Original Message ---- From: Julian Satran To: Mallikarjun C. Cc: IPS ; Julian=5FSatran@il.ibm.com Sent: Saturday, January 6, 2007 6:22:52 AM Subject: Re: Fw: [Ips] Response Fence Flag Mallikarjun & All, As I pointed out in a private discussion with you I never considered in=20 dept the response-fence (beyond what is needed for TM). It is a serious issue for any "transaction type" operations to storage -=20 but the last interface that had all the pieces correctly aligned was the=20 360 channel. SCSI had taken (traditionally) the positions that sequencing and=20 barriers are rarely needed and when needed applications should provide=20 them. And that is exactly what all of the relevant applications do (all=20 transaction monitors, databases etc.). The way all the application handle cases when the start of some SCSI=20 command has to follow the end of a previous set of operations is to just=20 wait for the end of the operations before issuing the "dependent=20 commands". Is this solution optimal? As you probably observed already this solution=20 implies that all the queues in the "stack" (at initiator, transport and=20 target) get empty before the dependent commands can be issued and that=20 is bad for performance. Can fencing (bad name BTW because it is in widespread use for defect=20 isolation) improve this? Yes (by keeping the pipes full!) provided it is=20 associated with rigorous exception handling and the later is a SCSI=20 issue (exceptions will require emptying the queues). With most=20 applications being distributed I doubt also that fencing for a single=20 I=5FT nexus is interesting and coordinating fencing and exception handling = over several I=5FTs is a complex exercise. And as transport alone brings no value to the whole issue - why should=20 we go through the exercise of defining a solution before SCSI has=20 defined one and we are confident that it is good enough and has value?=20 Again I agree that we a mechanism for TM but a good enough mechanism for=20 TM is already in and it gets now even better even without resorting to a=20 generalized fencing/barrier support. Regards, Julo Mallikarjun C. wrote: > Trying again after bouncing (>50KB), tail is now clipped.... > > ----- Forwarded Message ---- > From: Mallikarjun C. > To: ips@ietf.org > Sent: Friday, January 5, 2007 2:40:56 PM > Subject: Re: [Ips] Response Fence Flag > > Hi John, >=20 > As you correctly point out, there are two distinct but related=20 > topics here. >=20 > (1) proper response ordering across participating connections in a=20 > multi-connection session, for a handful of task/TMF responses > (2) proper way to terminate and signal tasks when actions on one=20 > session can impact multiple initiators >=20 > (1) is all about response fence, it is covered separately in section=20 > 3.3 of IG draft. That's what this email thread started off with. >=20 > (2) covers cases that IG had called as as "multi-task abort" cases=20 > that typically have a shared task set across sessions, or are the=20 > result of a Logical Unit Reset TMF. Section 4.1 of IG adresses (2). >=20 > So how are (1) and (2) related? >=20 > - Some cases covered under (2) overlap with (1), but some cases in (2)=20 > are for single connection sessions. E.g. LU Reset on a single=20 > connection session impacting several 3rd party sessions >=20 > - Some cases under (1) overlap with (2), but some cases in (1) have=20 > nothing to do with other sessions. E.g. establishment of ACA on a=20 > non-shared task set >=20 > - Section 4.1 (i.e. text for (2)) uses response fence (i.e. text for=20 > (1)) whenever multi-connection sessions are involved in multi-task=20 > abort situations. >=20 > I hope that clarifies it. Feel free to ask if that is not clear. The=20 > net is that the response fence is the underpinning notion to describe=20 > the correct iSCSI behavior in a few cases and some of those cases are=20 > about task terminations across third-party sessions. >=20 > Mallikarjun >=20 > > >=20 > ----- Original Message ---- > From: John Hufferd > To: Mallikarjun C. ; ips@ietf.org > Sent: Friday, January 5, 2007 1:01:06 PM > Subject: RE: [Ips] Response Fence Flag > > Mallikarjun, > > I must admit, that I have been a bit confused with the direction of=20 > the conversation here. > >=20 > > Therefore, I went back and reviewed the charts from Dallas . And as I=20 > remembered, the initial focus was to address the issue of Multiple=20 > Connections per Session (MC/S) (as stated on chart 4 ? ?Non-issue for=20 > single-connection iSCSI sessions?). So I think I have missed the step=20 > where we have morphed the discussion into one dealing with multiple=20 > sessions. (I am not sure how that happened, or if I miss-read the=20 > charts from Dallas , or have not followed the discussion adequately.) > >=20 > > If we are attempting to define two different issues, one with MC/S and=20 > one with Multiple Session from different Initiators, I think it would=20 > be useful to break down the conversation into Topic A ? MC/S and Topic=20 > B Multiple Sessions. It is possible that one solution will addresses=20 > both, but I for one think I am hearing arguments that might be=20 > appropriate for Topic B, while I am thinking about its applicability=20 > to Topic A. > >=20 > > Perhaps, you could address the issue as either being all about MC/S or=20 > explicitly state that it is intended to affect Multiple Sessions also,=20 > and then address the issues and solution for each separately. For=20 > example, I believe Robert was addressing the issue from a view of=20 > Multiple Sessions and if we only intended to address MC/S then I=20 > expect the response might be somewhat different. > >=20 > > Anyway, if you could clear-up some of this, I think it would be useful=20 > (at least to me). > >=20 > > . > > . > > . > > John L Hufferd > > Sr. Executive Director of Technology > > Brocade Communications Systems, Inc > > jhufferd@brocade.com > > Office Phone: (408) 333-5244; eFAX: (408) 904-4688 > > Alt Office Phone: (408) 997-6136; Cell: (408) 627-9606 > >=20 > > ------------------------------------------------------------------------ > > *From:* Mallikarjun C. [mailto:cb=5Fmallikarjun@yahoo.com] > *Sent:* Friday, January 05, 2007 10:08 AM > *To:* ips@ietf.org > *Subject:* Re: [Ips] Response Fence Flag > >=20 > > Not really. Current draft text is intentionally written to not have=20 > any dependencies on T10 dynamics. The point is that iSCSI needs such=20 > a notion for succinctly describing the proper iSCSI protocol actions=20 > in a few places - ACA, TMF, Persistent reserve/Abort to name a few.=20 > We certainly hope it will be approved by T10 and be a part of SAM-4=20 > soon, but that isn't required per se for describing what iSCSI needs=20 > for its correct behavior. > >=20 > > IPS WG has adopted what it needs in the past - staying ahead of T10=20 > review/approval cycle if necessary. I=5FT nexus loss notification,=20 > iSCSI target/port naming, clearing effects are a few I recall. > >=20 > > Mallikarjun > > > >=20 > > ----- Original Message ---- > From: Eddy Quicksall > To: Robert Snively ; "Elliott, Robert (Server=20 > Storage)" ; ips@ietf.org > Sent: Friday, January 5, 2007 8:58:47 AM > Subject: Re: [Ips] Response Fence Flag > > From an earlier email I think that Response Fence is only a proposal=20 > in T10 (http://www.t10.org:80/doc06.htm=20 > ). If so shouldn't iSCSI wait a bit=20 > until this has been ratified? > >=20 > > Eddy > > > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around > http://mail.yahoo.com > ------------------------------------------------------------------------ > > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F > Ips mailing list > Ips@ietf.org > https://www1.ietf.org/mailman/listinfo/ips >=20 =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around=20 http://mail.yahoo.com=20 =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --=_alternative 005840C08525725C_= Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable
Odered commands guarantee a complete ordered excution at the target (in the order the commands are received by the target). Unordered responses can be  expected (as the standards are completely mute about them). The trouble is that the appliaction has no control about the order the commands are received at the target.

Julo


"Eddy Quicksall&= quot; <Quicksall=5FiSCSI@Bellsouth.net>

07/01/07 10:39

To
"Mallikarjun C." <cb=5F= mallikarjun@yahoo.com>, Julian Satran/Haifa/IBM@IBMIL
cc
"IPS" <ips@ietf.org>=
Subject
Re: Fw: [Ips] Response Fence Flag





Maybe this was already mentioned but wouldn't the Respon= se Fence be necessary for even commands with ordered tags?
 
If an ordered command were sent on one connection then an ordered command were sent on another connection, the response for the 2nd ordered command may get back to the initiator before the response for the first ordered command. But that is not what would be expected by the initiator. A case for this could also be made regarding one or more simples followed by an ordered.
 
Eddy
----- Original Message -----
From: Julian Satran
To: Mallikarjun C.
Cc: IPS
Sent: Sunday, January 07, 2007 9:46 AM
Subject: Re: Fw: [Ips] Response Fence Flag


Mallikarjun,

I did reffer to the SCSI task atributes and why the ordering attribute is ill conceived as an ordering mechanism. I am repeating here the argument= s:
  • based on receiver time ordering (not controlled by application)  makes them unsuitable for applications
  • they are done either on every command or none while applications (transactions) just need a "barrier" between groups


Reponse ordering servs just this as the reponse with the barrier has to be (hold) the last of a group and allows the next group to start.
The ordering of responses is a way for an application to achieve a partial ordering in execution.

This is the way I read the draft.


In order to be valuable exceptions have to result in dropping and reissuing all queued commands including the barrier and after.

As for multi I=5FT=5FL nexuses (or even multi I=5FT) for the barrier to be = used/relevant it has to accomodate multiple units (nexi) as interesting applications hold multiple nexi.
This accomodation is especially difficult in the face on of failures. If this is what scsi had intended it for it looks to me that it is not finished yet (SCSI will need a synchronized barrier accomodating several nexi) and makes whatever we do of questionable value.

I am still OK with how it is written (as I I said before) - my change in mind is only in "if ought to be doing it" (as I doubt its value without additions) or we have to wait for SCSI to finish its work.

For TM we already did what we had to do (without the barrier) and doing the barrier is IMHO premature (although it answers nicely the single nexi issue).

Regards, Julo

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

06/01/07 17:54 =


To
IPS <ips@ietf.org>=
cc
Subject
Re: Fw: [Ips] Response Fence Flag







Julian,

I am surprised that you have not referred to the SCSI task attributes in the command ordering discussion.  In any case, in the interest of staying on the response fence topic, I will not respond to the command ordering points you made (debate topics for some other time, :-)).

The whole notion of response fence though is all about ordering responses, where such ordering is needed (only a very small % of responses, which are listed in section 3.3.3 of IG draft as we know them today).  The updated draft, which I will forward for publication today, lists one additi= onal case - that of Persistent Reserve/Abort Tasks.

I am not sure of your intended context of how SCSI-level rigorous exception handling relates to response fence.

And yes, response fence is not for cross-session collaboration, it is in fact limited to a single I=5FT=5FL nexus (please refer to section 3.3 of im= plementer's guide).

Regarding why iSCSI should define it, because it is required for succinctly describing iSCSI protocol behavior in multi-channel I=5FT nexus situations (iSCSI and SAS, as we know them today).  As mentioned to Eddy yesterda= y, it (or a concept like it with any other name - this concept is in section 10.6.2 of RFC 3720 as well even though we didn't call it such) is required for iSCSI's proper behavior.

Thanks.

Mallikarjun


----- Original Message ----
From: Julian Satran <julian.satran@gmail.com>
To: Mallikarjun C. <cb=5Fmallikarjun@yahoo.com>
Cc: IPS <ips@ietf.org>; Julian=5FSatran@il.ibm.com
Sent: Saturday, January 6, 2007 6:22:52 AM
Subject: Re: Fw: [Ips] Response Fence Flag

Mallikarjun & All,

As I pointed out in a private discussion with you I never considered in
dept the response-fence (beyond what is needed for TM).
It is a serious issue for any "transaction type" operations to storage -
but the last interface that had all the pieces correctly aligned was the
360 channel.
SCSI had taken (traditionally) the positions that sequencing and
barriers are rarely needed and when needed applications should provide them.
And that is exactly what all of the relevant applications do (all
transaction monitors, databases etc.).

The way all the application handle cases when the start of some SCSI
command has to follow the end of a previous set of operations is to just
wait for the end of the operations before issuing the "dependent comma= nds".

Is this solution optimal? As you probably observed already this solution
implies that all the queues in the "stack" (at initiator, transpo= rt and
target) get empty before the dependent commands can be issued and that
is bad for performance.

Can fencing (bad name BTW because it is in widespread use for defect
isolation) improve this? Yes (by keeping the pipes full!) provided it is
associated with rigorous exception handling and the later is a SCSI
issue (exceptions will require emptying the queues). With most
applications being distributed I doubt also that fencing for a single
I=5FT nexus is interesting and coordinating fencing and exception handling
over several I=5FTs is a complex exercise.

And as transport alone brings no value to the whole issue - why  should
we go through the exercise of defining a solution before SCSI has
defined one and we are confident that it is good enough and has value?
Again I agree that we a mechanism for TM but a good enough mechanism for
TM is already in and it gets now even better even without resorting to a
generalized fencing/barrier support.

Regards,
Julo








Mallikarjun C. wrote:
> Trying again after bouncing (>50KB), tail is now clipped....
>
> ----- Forwarded Message ----
> From: Mallikarjun C. <cb=5Fmallikarjun@yahoo.com>
> To: ips@ietf.org
> Sent: Friday, January 5, 2007 2:40:56 PM
> Subject: Re: [Ips] Response Fence Flag
>
> Hi John,
>  
> As you correctly point out, there are two distinct but related
> topics here.
>  
> (1) proper response ordering across participating connections in a
> multi-connection session, for a handful of task/TMF responses
> (2) proper way to terminate and signal tasks when actions on one
> session can impact multiple initiators
>  
> (1) is all about response fence, it is covered separately in section
> 3.3 of IG draft.  That's what this email thread started off with.=
>  
> (2) covers cases that IG had called as as "multi-task abort" cases
> that typically have a shared task set across sessions, or are the
> result of a Logical Unit Reset TMF.  Section 4.1 of IG adresses (2).
>  
> So how are (1) and (2) related?
>  
> - Some cases covered under (2) overlap with (1), but some cases in (2)
> are for single connection sessions.  E.g. LU Reset on a single
> connection session impacting several 3rd party sessions
>  
> - Some cases under (1) overlap with (2), but some cases in (1) have
> nothing to do with other sessions.  E.g. establishment of ACA on a
> non-shared task set
>  
> - Section 4.1 (i.e. text for (2)) uses response fence (i.e. text for
> (1)) whenever multi-connection sessions are involved in multi-task
> abort situations.
>  
> I hope that clarifies it.  Feel free to ask if that is not clear.  The
> net is that the response fence is the underpinning notion to describe
> the correct iSCSI behavior in a few cases and some of those cases are
> about task terminations across third-party sessions.
>  
> Mallikarjun
>  
>
>
>  
> ----- Original Message ----
> From: John Hufferd <jhufferd@Brocade.COM>
> To: Mallikarjun C. <cb=5Fmallikarjun@yahoo.com>; ips@ietf.org
> Sent: Friday, January 5, 2007 1:01:06 PM
> Subject: RE: [Ips] Response Fence Flag
>
> Mallikarjun,
>
> I must admit, that I have been a bit confused with the direction of
> the conversation here.
>
>  
>
> Therefore, I went back and reviewed the charts from Dallas .  And as I
> remembered, the initial focus was to address the issue of Multiple
> Connections per Session (MC/S) (as stated on chart 4 – “No= n-issue for
> single-connection iSCSI sessions”).  So I think I have miss= ed the step
> where we have morphed the discussion into one dealing with multiple
> sessions.  (I am not sure how that happened, or if I miss-read the
> charts from Dallas , or have not followed the discussion adequately.)<= br> >
>  
>
> If we are attempting to define two different issues, one with MC/S and
> one with Multiple Session from different Initiators, I think it would
> be useful to break down the conversation into Topic A – MC/S and Topic
> B Multiple Sessions.  It is possible that one solution will addre= sses
> both, but I for one think I am hearing arguments that might be
> appropriate for Topic B, while I am thinking about its applicability
> to Topic A.
>
>  
>
> Perhaps, you could address the issue as either being all about MC/S or
> explicitly state that it is intended to affect Multiple Sessions also,
> and then address the issues and solution for each separately.  For
> example, I believe Robert was addressing the issue from a view of
> Multiple Sessions and if we only intended to address MC/S then I
> expect the response might be somewhat different.
>
>  
>
> Anyway, if you could clear-up some of this, I think it would be useful
> (at least to me).
>
>  
>
> .
>
> .
>
> .
>
> John L Hufferd
>
> Sr. Executive Director of Technology
>
> Brocade Communications Systems, Inc
>
> jhufferd@brocade.com <mailto:jhufferd@brocade.com>
>
> Office Phone: (408) 333-5244; eFAX: (408) 904-4688
>
> Alt Office Phone: (408) 997-6136; Cell: (408) 627-9606
>
>  
>
> ----------------------------------------------------------------------= --
>
> *From:* Mallikarjun C. [mailto:cb=5Fmallikarjun@yahoo.com]
> *Sent:* Friday, January 05, 2007 10:08 AM
> *To:* ips@ietf.org
> *Subject:* Re: [Ips] Response Fence Flag
>
>  
>
> Not really.  Current draft text is intentionally written to not have
> any dependencies on T10 dynamics.  The point is that iSCSI needs such
> a notion for succinctly describing the proper iSCSI protocol actions
> in a few places - ACA, TMF, Persistent reserve/Abort to name a few.  
> We certainly hope it will be approved by T10 and be a part of SAM-4
> soon, but that isn't required per se for describing what iSCSI needs
> for its correct behavior.
>
>  
>
> IPS WG has adopted what it needs in the past - staying ahead of T10
> review/approval cycle if necessary.  I=5FT nexus loss notificatio= n,
> iSCSI target/port naming, clearing effects are a few I recall.
>
>  
>
> Mallikarjun
>
>
>
>  
>
> ----- Original Message ----
> From: Eddy Quicksall <Quicksall=5FiSCSI@Bellsouth.net>
> To: Robert Snively <rsnively@Brocade.COM>; "Elliott, Robert (Server
> Storage)" <Elliott@hp.com>; ips@ietf.org
> Sent: Friday, January 5, 2007 8:58:47 AM
> Subject: Re: [Ips] Response Fence Flag
>
> From an earlier email I think that Response Fence is only a proposal
> in T10 (http://www.t10.org:80/doc06.htm
> <http://www.t10.org/doc06.htm>). If so shouldn't iSCSI wait a bit
> until this has been ratified?
>
>  
>
> Eddy
>
>
> =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F
> Do You Yahoo!?
> Tired of spam? Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
> ----------------------------------------------------------------------= --
>
> =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
> Ips mailing list
> Ips@ietf.org
> https://www1.ietf.org/mailman/listinfo/ips
>  





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

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

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

--=_alternative 005840C08525725C_=-- --===============1883707586== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============1883707586==-- From ips-bounces@ietf.org Sun Jan 07 12:08:06 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3bUw-0006mm-BC; Sun, 07 Jan 2007 12:07:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3bUu-0006mh-VA for ips@ietf.org; Sun, 07 Jan 2007 12:07:52 -0500 Received: from imf17aec.mail.bellsouth.net ([205.152.59.65]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H3bUq-0001kI-MV for ips@ietf.org; Sun, 07 Jan 2007 12:07:52 -0500 Received: from ibm57aec.bellsouth.net ([74.245.52.54]) by imf17aec.mail.bellsouth.net with ESMTP id <20070107170744.EVJK3568.imf17aec.mail.bellsouth.net@ibm57aec.bellsouth.net> for ; Sun, 7 Jan 2007 12:07:44 -0500 Received: from IVVTDKV0981 ([74.245.52.54]) by ibm57aec.bellsouth.net with SMTP id <20070107170742.LAEW16959.ibm57aec.bellsouth.net@IVVTDKV0981>; Sun, 7 Jan 2007 12:07:42 -0500 Message-ID: <002901c7327e$57d196d0$01faa8c0@ivivity.com> From: "Eddy Quicksall" To: "Julian Satran" References: Subject: Re: Fw: [Ips] Response Fence Flag Date: Sun, 7 Jan 2007 12:07:42 -0500 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.3 (/) X-Scan-Signature: 31c5f48314ee2074d17118e5d97ef478 Cc: IPS X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1836893460==" Errors-To: ips-bounces@ietf.org This is a multi-part message in MIME format. --===============1836893460== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0026_01C73254.6EC25660" This is a multi-part message in MIME format. ------=_NextPart_000_0026_01C73254.6EC25660 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I would think ordered commands would correctly for a single instance of = a single application. Is your example that there may be multiple instances of an application = (or multiple applications), each issuing ordered commands to the same = I_T Nexus and that a single instance/application would not be able to = guarantee order with respect to other instances/applications? Eddy ----- Original Message -----=20 From: Julian Satran=20 To: Eddy Quicksall=20 Cc: Mallikarjun C. ; IPS=20 Sent: Sunday, January 07, 2007 11:04 AM Subject: Re: Fw: [Ips] Response Fence Flag Odered commands guarantee a complete ordered excution at the target = (in the order the commands are received by the target). Unordered = responses can be expected (as the standards are completely mute about = them). The trouble is that the appliaction has no control about the = order the commands are received at the target.=20 Julo=20 "Eddy Quicksall" =20 07/01/07 10:39=20 To "Mallikarjun C." , Julian = Satran/Haifa/IBM@IBMIL =20 cc "IPS" =20 Subject Re: Fw: [Ips] Response Fence Flag=20 =20 =20 Maybe this was already mentioned but wouldn't the Response Fence be = necessary for even commands with ordered tags?=20 =20 If an ordered command were sent on one connection then an ordered = command were sent on another connection, the response for the 2nd = ordered command may get back to the initiator before the response for = the first ordered command. But that is not what would be expected by the = initiator. A case for this could also be made regarding one or more = simples followed by an ordered.=20 =20 Eddy=20 ----- Original Message -----=20 From: Julian Satran=20 To: Mallikarjun C.=20 Cc: IPS=20 Sent: Sunday, January 07, 2007 9:46 AM=20 Subject: Re: Fw: [Ips] Response Fence Flag=20 Mallikarjun,=20 I did reffer to the SCSI task atributes and why the ordering attribute = is ill conceived as an ordering mechanism. I am repeating here the = arguments:=20 a.. based on receiver time ordering (not controlled by application) = makes them unsuitable for applications=20 b.. they are done either on every command or none while applications = (transactions) just need a "barrier" between groups Reponse ordering servs just this as the reponse with the barrier has = to be (hold) the last of a group and allows the next group to start.=20 The ordering of responses is a way for an application to achieve a = partial ordering in execution.=20 This is the way I read the draft.=20 In order to be valuable exceptions have to result in dropping and = reissuing all queued commands including the barrier and after.=20 As for multi I_T_L nexuses (or even multi I_T) for the barrier to be = used/relevant it has to accomodate multiple units (nexi) as interesting = applications hold multiple nexi.=20 This accomodation is especially difficult in the face on of failures. = If this is what scsi had intended it for it looks to me that it is not = finished yet (SCSI will need a synchronized barrier accomodating several = nexi) and makes whatever we do of questionable value.=20 I am still OK with how it is written (as I I said before) - my change = in mind is only in "if ought to be doing it" (as I doubt its value = without additions) or we have to wait for SCSI to finish its work.=20 For TM we already did what we had to do (without the barrier) and = doing the barrier is IMHO premature (although it answers nicely the = single nexi issue).=20 Regards,=20 Julo=20 "Mallikarjun C." =20 06/01/07 17:54=20 =20 To IPS =20 cc =20 Subject Re: Fw: [Ips] Response Fence Flag=20 =20 =20 Julian, I am surprised that you have not referred to the SCSI task attributes = in the command ordering discussion. In any case, in the interest of = staying on the response fence topic, I will not respond to the command = ordering points you made (debate topics for some other time, :-)). The whole notion of response fence though is all about ordering = responses, where such ordering is needed (only a very small % of = responses, which are listed in section 3.3.3 of IG draft as we know them = today). The updated draft, which I will forward for publication today, = lists one additional case - that of Persistent Reserve/Abort Tasks. I am not sure of your intended context of how SCSI-level rigorous = exception handling relates to response fence. And yes, response fence is not for cross-session collaboration, it is = in fact limited to a single I_T_L nexus (please refer to section 3.3 of = implementer's guide). Regarding why iSCSI should define it, because it is required for = succinctly describing iSCSI protocol behavior in multi-channel I_T nexus = situations (iSCSI and SAS, as we know them today). As mentioned to Eddy = yesterday, it (or a concept like it with any other name - this concept = is in section 10.6.2 of RFC 3720 as well even though we didn't call it = such) is required for iSCSI's proper behavior. Thanks. Mallikarjun=20 ----- Original Message ---- From: Julian Satran To: Mallikarjun C. Cc: IPS ; Julian_Satran@il.ibm.com Sent: Saturday, January 6, 2007 6:22:52 AM Subject: Re: Fw: [Ips] Response Fence Flag Mallikarjun & All, As I pointed out in a private discussion with you I never considered = in=20 dept the response-fence (beyond what is needed for TM). It is a serious issue for any "transaction type" operations to storage = -=20 but the last interface that had all the pieces correctly aligned was = the=20 360 channel. SCSI had taken (traditionally) the positions that sequencing and=20 barriers are rarely needed and when needed applications should provide = them. And that is exactly what all of the relevant applications do (all=20 transaction monitors, databases etc.). The way all the application handle cases when the start of some SCSI=20 command has to follow the end of a previous set of operations is to = just=20 wait for the end of the operations before issuing the "dependent = commands". Is this solution optimal? As you probably observed already this = solution=20 implies that all the queues in the "stack" (at initiator, transport = and=20 target) get empty before the dependent commands can be issued and that = is bad for performance. Can fencing (bad name BTW because it is in widespread use for defect=20 isolation) improve this? Yes (by keeping the pipes full!) provided it = is=20 associated with rigorous exception handling and the later is a SCSI=20 issue (exceptions will require emptying the queues). With most=20 applications being distributed I doubt also that fencing for a single=20 I_T nexus is interesting and coordinating fencing and exception = handling=20 over several I_Ts is a complex exercise. And as transport alone brings no value to the whole issue - why = should=20 we go through the exercise of defining a solution before SCSI has=20 defined one and we are confident that it is good enough and has value? = Again I agree that we a mechanism for TM but a good enough mechanism = for=20 TM is already in and it gets now even better even without resorting to = a=20 generalized fencing/barrier support. Regards, Julo Mallikarjun C. wrote: > Trying again after bouncing (>50KB), tail is now clipped.... > > ----- Forwarded Message ---- > From: Mallikarjun C. > To: ips@ietf.org > Sent: Friday, January 5, 2007 2:40:56 PM > Subject: Re: [Ips] Response Fence Flag > > Hi John, > =20 > As you correctly point out, there are two distinct but related=20 > topics here. > =20 > (1) proper response ordering across participating connections in a=20 > multi-connection session, for a handful of task/TMF responses > (2) proper way to terminate and signal tasks when actions on one=20 > session can impact multiple initiators > =20 > (1) is all about response fence, it is covered separately in section = > 3.3 of IG draft. That's what this email thread started off with. > =20 > (2) covers cases that IG had called as as "multi-task abort" cases=20 > that typically have a shared task set across sessions, or are the=20 > result of a Logical Unit Reset TMF. Section 4.1 of IG adresses (2). > =20 > So how are (1) and (2) related? > =20 > - Some cases covered under (2) overlap with (1), but some cases in = (2)=20 > are for single connection sessions. E.g. LU Reset on a single=20 > connection session impacting several 3rd party sessions > =20 > - Some cases under (1) overlap with (2), but some cases in (1) have=20 > nothing to do with other sessions. E.g. establishment of ACA on a=20 > non-shared task set > =20 > - Section 4.1 (i.e. text for (2)) uses response fence (i.e. text for = > (1)) whenever multi-connection sessions are involved in multi-task=20 > abort situations. > =20 > I hope that clarifies it. Feel free to ask if that is not clear. = The=20 > net is that the response fence is the underpinning notion to = describe=20 > the correct iSCSI behavior in a few cases and some of those cases = are=20 > about task terminations across third-party sessions. > =20 > Mallikarjun > =20 > > > =20 > ----- Original Message ---- > From: John Hufferd > To: Mallikarjun C. ; ips@ietf.org > Sent: Friday, January 5, 2007 1:01:06 PM > Subject: RE: [Ips] Response Fence Flag > > Mallikarjun, > > I must admit, that I have been a bit confused with the direction of=20 > the conversation here. > > =20 > > Therefore, I went back and reviewed the charts from Dallas . And as = I=20 > remembered, the initial focus was to address the issue of Multiple=20 > Connections per Session (MC/S) (as stated on chart 4 - "Non-issue = for=20 > single-connection iSCSI sessions"). So I think I have missed the = step=20 > where we have morphed the discussion into one dealing with multiple=20 > sessions. (I am not sure how that happened, or if I miss-read the=20 > charts from Dallas , or have not followed the discussion = adequately.) > > =20 > > If we are attempting to define two different issues, one with MC/S = and=20 > one with Multiple Session from different Initiators, I think it = would=20 > be useful to break down the conversation into Topic A - MC/S and = Topic=20 > B Multiple Sessions. It is possible that one solution will = addresses=20 > both, but I for one think I am hearing arguments that might be=20 > appropriate for Topic B, while I am thinking about its applicability = > to Topic A. > > =20 > > Perhaps, you could address the issue as either being all about MC/S = or=20 > explicitly state that it is intended to affect Multiple Sessions = also,=20 > and then address the issues and solution for each separately. For=20 > example, I believe Robert was addressing the issue from a view of=20 > Multiple Sessions and if we only intended to address MC/S then I=20 > expect the response might be somewhat different. > > =20 > > Anyway, if you could clear-up some of this, I think it would be = useful=20 > (at least to me). > > =20 > > . > > . > > . > > John L Hufferd > > Sr. Executive Director of Technology > > Brocade Communications Systems, Inc > > jhufferd@brocade.com > > Office Phone: (408) 333-5244; eFAX: (408) 904-4688 > > Alt Office Phone: (408) 997-6136; Cell: (408) 627-9606 > > =20 > > = ------------------------------------------------------------------------ > > *From:* Mallikarjun C. [mailto:cb_mallikarjun@yahoo.com] > *Sent:* Friday, January 05, 2007 10:08 AM > *To:* ips@ietf.org > *Subject:* Re: [Ips] Response Fence Flag > > =20 > > Not really. Current draft text is intentionally written to not have = > any dependencies on T10 dynamics. The point is that iSCSI needs = such=20 > a notion for succinctly describing the proper iSCSI protocol actions = > in a few places - ACA, TMF, Persistent reserve/Abort to name a few. = > We certainly hope it will be approved by T10 and be a part of SAM-4=20 > soon, but that isn't required per se for describing what iSCSI needs = > for its correct behavior. > > =20 > > IPS WG has adopted what it needs in the past - staying ahead of T10=20 > review/approval cycle if necessary. I_T nexus loss notification,=20 > iSCSI target/port naming, clearing effects are a few I recall. > > =20 > > Mallikarjun > > > > =20 > > ----- Original Message ---- > From: Eddy Quicksall > To: Robert Snively ; "Elliott, Robert (Server=20 > Storage)" ; ips@ietf.org > Sent: Friday, January 5, 2007 8:58:47 AM > Subject: Re: [Ips] Response Fence Flag > > From an earlier email I think that Response Fence is only a proposal = > in T10 (http://www.t10.org:80/doc06.htm=20 > ). If so shouldn't iSCSI wait a bit=20 > until this has been ratified? > > =20 > > Eddy > > > __________________________________________________ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around > http://mail.yahoo.com > = ------------------------------------------------------------------------ > > _______________________________________________ > Ips mailing list > Ips@ietf.org > https://www1.ietf.org/mailman/listinfo/ips > =20 __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around=20 http://mail.yahoo.com=20 _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips -------------------------------------------------------------------------= ----- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips=20 ------=_NextPart_000_0026_01C73254.6EC25660 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

I would think ordered commands would = correctly for a=20 single instance of a single application.
 
Is your example that there may be multiple instances = of an=20 application (or multiple applications), each issuing ordered commands to = the=20 same I_T Nexus and that a single instance/application = would not=20 be able to guarantee order with respect to other=20 instances/applications?
 
Eddy
----- Original Message -----
From:=20 Julian Satran
To: Eddy Quicksall =
Cc: Mallikarjun C. ; IPS
Sent: Sunday, January 07, 2007 = 11:04=20 AM
Subject: Re: Fw: [Ips] Response = Fence=20 Flag


Odered commands = guarantee a=20 complete ordered excution at the target (in the order the commands are = received by the target). Unordered responses can be  expected (as = the=20 standards are completely mute about them). The trouble is that the = appliaction=20 has no control about the order the commands are received at the = target.=20

Julo


"Eddy = Quicksall" <Quicksall_iSCSI@Bellsouth.n= et>=20

07/01/07 10:39

To
"Mallikarjun C." <cb_mallikarjun@yahoo.com>= ,=20 Julian Satran/Haifa/IBM@IBMIL =
cc
"IPS" <ips@ietf.org>=20
Subject
Re: Fw: [Ips] Response = Fence=20 Flag

=




Maybe this was already mentioned but wouldn't the Response = Fence be=20 necessary for even commands with ordered tags?
 
If an ordered command were = sent on one=20 connection then an ordered command were sent on another connection, = the=20 response for the 2nd ordered command may get back to the initiator = before the=20 response for the first ordered command. But that is not what would be = expected=20 by the initiator. A case for this could also be made regarding one or = more=20 simples followed by an ordered.
 =20
Eddy
----- Original = Message -----=20
From: Julian=20 Satran
To:=20 Mallikarjun C. =
Cc: IPS
Sent:=20 Sunday, January 07, 2007 9:46 AM
Subject: Re:=20 Fw: [Ips] Response Fence Flag


Mallikarjun,

I did reffer to the SCSI task atributes and why the = ordering=20 attribute is ill conceived as an ordering mechanism. I am repeating = here the=20 arguments:
  • based on receiver time ordering = (not=20 controlled by application)  makes them unsuitable for = applications=20
  • they are done either on every = command or=20 none while applications (transactions) just need a "barrier" between = groups


Reponse ordering servs just this as the reponse with the = barrier=20 has to be (hold) the last of a group and allows the next group to=20 start.
The=20 ordering of responses is a way for an application to achieve a partial = ordering in execution.

This is the way I read the draft.=20


In order to be = valuable=20 exceptions have to result in dropping and reissuing all queued = commands=20 including the barrier and after. =

As for multi I_T_L nexuses (or even = multi I_T) for=20 the barrier to be used/relevant it has to accomodate multiple units = (nexi) as=20 interesting applications hold multiple nexi. =
This accomodation is especially = difficult in the=20 face on of failures. If this is what scsi had intended it for it looks = to me=20 that it is not finished yet (SCSI will need a synchronized barrier=20 accomodating several nexi) and makes whatever we do of questionable=20 value.

I am=20 still OK with how it is written (as I I said before) - my change in = mind is=20 only in "if ought to be doing it" (as I doubt its value without = additions) or=20 we have to wait for SCSI to finish its work.=20

For TM we already did = what we had=20 to do (without the barrier) and doing the barrier is IMHO premature = (although=20 it answers nicely the single nexi issue). =

Regards, =
Julo =

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

06/01/07 17:54=20


To
IPS=20 <ips@ietf.org>
cc
Subject
Re: Fw: [Ips] Response = Fence=20 Flag







Julian,

I am = surprised that=20 you have not referred to the SCSI task attributes in the command = ordering=20 discussion.  In any case, in the interest of staying on the = response=20 fence topic, I will not respond to the command ordering points you = made=20 (debate topics for some other time, :-)).

The whole notion of = response=20 fence though is all about ordering responses, where such ordering is = needed=20 (only a very small % of responses, which are listed in section 3.3.3 = of IG=20 draft as we know them today).  The updated draft, which I will = forward=20 for publication today, lists one additional case - that of Persistent=20 Reserve/Abort Tasks.

I am not sure of your intended context of = how=20 SCSI-level rigorous exception handling relates to response = fence.

And=20 yes, response fence is not for cross-session collaboration, it is in = fact=20 limited to a single I_T_L nexus (please refer to section 3.3 of = implementer's=20 guide).

Regarding why iSCSI should define it, because it is = required=20 for succinctly describing iSCSI protocol behavior in multi-channel I_T = nexus=20 situations (iSCSI and SAS, as we know them today).  As mentioned = to Eddy=20 yesterday, it (or a concept like it with any other name - this concept = is in=20 section 10.6.2 of RFC 3720 as well even though we didn't call it such) = is=20 required for iSCSI's proper = behavior.

Thanks.

Mallikarjun=20


----- Original Message ----
From: Julian Satran=20 <julian.satran@gmail.com>
To: Mallikarjun C.=20 <cb_mallikarjun@yahoo.com>
Cc: IPS <ips@ietf.org>;=20 Julian_Satran@il.ibm.com
Sent: Saturday, January 6, 2007 6:22:52=20 AM
Subject: Re: Fw: [Ips] Response Fence Flag

Mallikarjun = &=20 All,

As I pointed out in a private discussion with you I never=20 considered in
dept the response-fence (beyond what is needed for=20 TM).
It is a serious issue for any "transaction type" operations to = storage=20 -
but the last interface that had all the pieces correctly aligned = was the=20
360 channel.
SCSI had taken (traditionally) the positions that=20 sequencing and
barriers are rarely needed and when needed = applications=20 should provide them.
And that is exactly what all of the relevant=20 applications do (all
transaction monitors, databases = etc.).

The way=20 all the application handle cases when the start of some SCSI =
command has=20 to follow the end of a previous set of operations is to just
wait = for the=20 end of the operations before issuing the "dependent = commands".

Is this=20 solution optimal? As you probably observed already this solution =
implies=20 that all the queues in the "stack" (at initiator, transport and =
target)=20 get empty before the dependent commands can be issued and that
is = bad for=20 performance.

Can fencing (bad name BTW because it is in = widespread use=20 for defect
isolation) improve this? Yes (by keeping the pipes = full!)=20 provided it is
associated with rigorous exception handling and the = later=20 is a SCSI
issue (exceptions will require emptying the queues). = With most=20
applications being distributed I doubt also that fencing for a = single=20
I_T nexus is interesting and coordinating fencing and exception = handling=20
over several I_Ts is a complex exercise.

And as transport = alone=20 brings no value to the whole issue - why  should
we go = through the=20 exercise of defining a solution before SCSI has
defined one and we = are=20 confident that it is good enough and has value?
Again I agree that = we a=20 mechanism for TM but a good enough mechanism for
TM is already in = and it=20 gets now even better even without resorting to a
generalized=20 fencing/barrier=20 = support.

Regards,
Julo








Malli= karjun=20 C. wrote:
> Trying again after bouncing (>50KB), tail is now=20 clipped....
>
> ----- Forwarded Message ----
> From: = Mallikarjun C. <cb_mallikarjun@yahoo.com>
> To:=20 ips@ietf.org
> Sent: Friday, January 5, 2007 2:40:56 PM
> = Subject:=20 Re: [Ips] Response Fence Flag
>
> Hi John,
> =  
>=20 As you correctly point out, there are two distinct but related =
> topics=20 here.
>  
> (1) proper response ordering across = participating=20 connections in a
> multi-connection session, for a handful of = task/TMF=20 responses
> (2) proper way to terminate and signal tasks when = actions on=20 one
> session can impact multiple initiators
> =  
> (1)=20 is all about response fence, it is covered separately in section =
> 3.3=20 of IG draft.  That's what this email thread started off = with.
>=20  
> (2) covers cases that IG had called as as "multi-task = abort"=20 cases
> that typically have a shared task set across sessions, = or are=20 the
> result of a Logical Unit Reset TMF.  Section 4.1 of = IG=20 adresses (2).
>  
> So how are (1) and (2) = related?
>=20  
> - Some cases covered under (2) overlap with (1), but = some cases=20 in (2)
> are for single connection sessions.  E.g. LU = Reset on a=20 single
> connection session impacting several 3rd party=20 sessions
>  
> - Some cases under (1) overlap with = (2), but=20 some cases in (1) have
> nothing to do with other sessions. =  E.g.=20 establishment of ACA on a
> non-shared task set
> =  
>=20 - Section 4.1 (i.e. text for (2)) uses response fence (i.e. text for =
>=20 (1)) whenever multi-connection sessions are involved in multi-task =
>=20 abort situations.
>  
> I hope that clarifies it. =  Feel=20 free to ask if that is not clear.  The
> net is that the = response=20 fence is the underpinning notion to describe
> the correct = iSCSI=20 behavior in a few cases and some of those cases are
> about = task=20 terminations across third-party sessions.
>  
>=20 Mallikarjun
>  
>
>
>  
> = -----=20 Original Message ----
> From: John Hufferd=20 <jhufferd@Brocade.COM>
> To: Mallikarjun C.=20 <cb_mallikarjun@yahoo.com>; ips@ietf.org
> Sent: Friday, = January=20 5, 2007 1:01:06 PM
> Subject: RE: [Ips] Response Fence=20 Flag
>
> Mallikarjun,
>
> I must admit, that I = have=20 been a bit confused with the direction of
> the conversation=20 here.
>
>  
>
> Therefore, I went back = and=20 reviewed the charts from Dallas .  And as I
> remembered, = the=20 initial focus was to address the issue of Multiple
> = Connections per=20 Session (MC/S) (as stated on chart 4 =96 =93Non-issue for
>=20 single-connection iSCSI sessions=94).  So I think I have missed = the step=20
> where we have morphed the discussion into one dealing with = multiple=20
> sessions.  (I am not sure how that happened, or if I = miss-read=20 the
> charts from Dallas , or have not followed the discussion=20 adequately.)
>
>  
>
> If we are = attempting to=20 define two different issues, one with MC/S and
> one with = Multiple=20 Session from different Initiators, I think it would
> be useful = to=20 break down the conversation into Topic A =96 MC/S and Topic
> B = Multiple=20 Sessions.  It is possible that one solution will addresses =
> both,=20 but I for one think I am hearing arguments that might be
> = appropriate=20 for Topic B, while I am thinking about its applicability
> to = Topic=20 A.
>
>  
>
> Perhaps, you could address = the issue=20 as either being all about MC/S or
> explicitly state that it is = intended to affect Multiple Sessions also,
> and then address = the=20 issues and solution for each separately.  For
> example, I = believe=20 Robert was addressing the issue from a view of
> Multiple = Sessions and=20 if we only intended to address MC/S then I
> expect the = response might=20 be somewhat different.
>
>  
>
> Anyway, = if you=20 could clear-up some of this, I think it would be useful
> (at = least to=20 me).
>
>  
>
> .
>
>=20 .
>
> .
>
> John L Hufferd
>
> Sr. = Executive Director of Technology
>
> Brocade = Communications=20 Systems, Inc
>
> jhufferd@brocade.com=20 <mailto:jhufferd@brocade.com>
>
> Office Phone: = (408)=20 333-5244; eFAX: (408) 904-4688
>
> Alt Office Phone: (408) = 997-6136; Cell: (408) 627-9606
>
>  
>
>=20 = ------------------------------------------------------------------------<= BR>>
>=20 *From:* Mallikarjun C. [mailto:cb_mallikarjun@yahoo.com]
> = *Sent:*=20 Friday, January 05, 2007 10:08 AM
> *To:* ips@ietf.org
>=20 *Subject:* Re: [Ips] Response Fence Flag
>
>=20  
>
> Not really.  Current draft text is = intentionally=20 written to not have
> any dependencies on T10 dynamics. =  The point=20 is that iSCSI needs such
> a notion for succinctly describing = the=20 proper iSCSI protocol actions
> in a few places - ACA, TMF, = Persistent=20 reserve/Abort to name a few.  
> We certainly hope it will = be=20 approved by T10 and be a part of SAM-4
> soon, but that isn't = required=20 per se for describing what iSCSI needs
> for its correct=20 behavior.
>
>  
>
> IPS WG has adopted = what it=20 needs in the past - staying ahead of T10
> review/approval = cycle if=20 necessary.  I_T nexus loss notification,
> iSCSI = target/port=20 naming, clearing effects are a few I recall.
>
>=20  
>
> Mallikarjun
>
>
>
>=20  
>
> ----- Original Message ----
> From: Eddy=20 Quicksall <Quicksall_iSCSI@Bellsouth.net>
> To: Robert = Snively=20 <rsnively@Brocade.COM>; "Elliott, Robert (Server
> = Storage)"=20 <Elliott@hp.com>; ips@ietf.org
> Sent: Friday, January 5, = 2007=20 8:58:47 AM
> Subject: Re: [Ips] Response Fence = Flag
>
> From=20 an earlier email I think that Response Fence is only a proposal =
> in=20 T10 (http://www.t10.org:80/doc06.htm
>=20 <http://www.t10.org/doc06.htm>). If so shouldn't iSCSI wait a = bit=20
> until this has been ratified?
>
> =  
>
>=20 Eddy
>
>
>=20 __________________________________________________
> Do You=20 Yahoo!?
> Tired of spam? Yahoo! Mail has the best spam = protection=20 around
> http://mail.yahoo.com
>=20 = ------------------------------------------------------------------------<= BR>>
>=20 _______________________________________________
> Ips mailing=20 list
> Ips@ietf.org
>=20 https://www1.ietf.org/mailman/listinfo/ips
>  =20 =





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

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

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

------=_NextPart_000_0026_01C73254.6EC25660-- --===============1836893460== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============1836893460==-- From ips-bounces@ietf.org Mon Jan 08 10:21:07 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3wIb-0003UI-4i; Mon, 08 Jan 2007 10:20:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3wIZ-0003U8-Mh for ips@ietf.org; Mon, 08 Jan 2007 10:20:31 -0500 Received: from smtp103.plus.mail.mud.yahoo.com ([68.142.206.236]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H3wIY-0005zz-AK for ips@ietf.org; Mon, 08 Jan 2007 10:20:31 -0500 Received: (qmail 95068 invoked from network); 8 Jan 2007 15:20:29 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Received:X-YMail-OSG:From:To:Subject:Date:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:In-Reply-To:Importance:X-MimeOLE; b=FsttmeE8qTP2v4OU7sGLgB1X87cnKyAkvexkoiz5rIWHN7HcUTtpgwxCDFr1cAVYcQ31D4hIubA9zu1s/dclgQEegzqwh5wvFertUvLfSQn7FidEWTJwmj1kAKtRFe9P+urLoA88FmTdwgdaL0BZuml1RFXhOVcsNY3W6pGNX9Q= ; Received: from unknown (HELO abhi) (ram_sunee@71.136.21.107 with login) by smtp103.plus.mail.mud.yahoo.com with SMTP; 8 Jan 2007 15:20:29 -0000 X-YMail-OSG: gjjfjasVM1n4lNLzekaJJeQsQPjJEf23Owk9KfZg2PotsjlS.FCMAEew9NqWAl0f5I6mAignMu8ooVNvck4rw5N0EZiDD7AMvDR6N54kXb_SIgNO97FapQoH8_tEoB.2TyKu0HzGdGVNYCfjX3XUkTcGKVAKYZmcK4yD.LbYKlPnFaE.zB584m.HZRE- From: "RAM SUNEE" To: Date: Mon, 8 Jan 2007 07:20:21 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 1 (Highest) X-MSMail-Priority: High X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: Importance: High X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.4 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Subject: [Ips] Device Identification VPD Page for iSCSI Targets X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ips-bounces@ietf.org All, Can anyone please clarify me regarding, Device Identification VPD usage for iSCSI Target. What values should an iSCSI Target use for PROTOCOL_IDENTIFIER, ASSOCIATION fields of Device Identification VPD response page. I have noticed that iSCSI Targets are reportng to Initiators as "SCSI Disk Device",is it correct behavior? Isn't it supposed to be that iSCSI Target needs to report to Initiator as "iSCSI Disk Device" -RAM _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Mon Jan 08 11:05:39 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3x0A-00081M-93; Mon, 08 Jan 2007 11:05:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3x09-00081G-Eh for ips@ietf.org; Mon, 08 Jan 2007 11:05:33 -0500 Received: from imf24aec.mail.bellsouth.net ([205.152.59.72]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H3x07-0003F9-2e for ips@ietf.org; Mon, 08 Jan 2007 11:05:33 -0500 Received: from ibm70aec.bellsouth.net ([74.245.52.54]) by imf24aec.mail.bellsouth.net with ESMTP id <20070108160530.QCVF7355.imf24aec.mail.bellsouth.net@ibm70aec.bellsouth.net> for ; Mon, 8 Jan 2007 11:05:30 -0500 Received: from IVVTDKV0981 ([74.245.52.54]) by ibm70aec.bellsouth.net with SMTP id <20070108160529.NEOX18024.ibm70aec.bellsouth.net@IVVTDKV0981>; Mon, 8 Jan 2007 11:05:29 -0500 Message-ID: <000f01c7333e$d1c2c520$01faa8c0@ivivity.com> From: "Eddy Quicksall" To: "RAM SUNEE" , References: Subject: Re: [Ips] Device Identification VPD Page for iSCSI Targets Date: Mon, 8 Jan 2007 11:05:29 -0500 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ips-bounces@ietf.org Referring to Table 296 of spc4r07a it seems the value should be 5 meaning iSCSI. Eddy ----- Original Message ----- From: "RAM SUNEE" To: Sent: Monday, January 08, 2007 10:20 AM Subject: [Ips] Device Identification VPD Page for iSCSI Targets > All, > > Can anyone please clarify me regarding, Device Identification VPD usage > for > iSCSI Target. > What values should an iSCSI Target use for PROTOCOL_IDENTIFIER, > ASSOCIATION > fields of Device Identification VPD response page. > I have noticed that iSCSI Targets are reportng to Initiators as "SCSI Disk > Device",is it correct behavior? > Isn't it supposed to be that iSCSI Target needs to report to Initiator as > "iSCSI Disk Device" > > -RAM > > > > _______________________________________________ > Ips mailing list > Ips@ietf.org > https://www1.ietf.org/mailman/listinfo/ips > _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Mon Jan 08 11:16:43 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3xAw-0005ZL-Ex; Mon, 08 Jan 2007 11:16:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3xAv-0005XG-FF for ips@ietf.org; Mon, 08 Jan 2007 11:16:41 -0500 Received: from ausc60ps301.us.dell.com ([143.166.148.206]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H3x5j-0005OT-5u for ips@ietf.org; Mon, 08 Jan 2007 11:11:21 -0500 DomainKey-Signature: s=smtpout; d=dell.com; c=nofws; q=dns; b=RlQgCuJM8b6/A+gbyUDJFa6G2SzfMgDM7/PNNX8wUCa6upPEoNGuvyxNSLwJIOW772BMvhp6b75/jK1TvNccjP+7C3YHbNvSk1EjJtAv1f0wZaKvFTYyQUQ8kMkx1Scr; Received: from ausx3bps303.aus.amer.dell.com ([10.3.153.41]) by ausc60ps301.us.dell.com with ESMTP; 08 Jan 2007 10:11:18 -0600 X-IronPort-AV: i="4.13,159,1167631200"; d="scan'208"; a="151885540:sNHT35835453" X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ips] Device Identification VPD Page for iSCSI Targets Date: Mon, 8 Jan 2007 10:11:16 -0600 Message-ID: <389040536173ED4AADA5EFEA9633358602269880@ausx3mpc106.aus.amer.dell.com> In-Reply-To: <000f01c7333e$d1c2c520$01faa8c0@ivivity.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ips] Device Identification VPD Page for iSCSI Targets Thread-Index: AcczPvoCXDLn21pvSSGywVyfgt79twAAI1Og From: To: , , X-OriginalArrivalTime: 08 Jan 2007 16:11:17.0942 (UTC) FILETIME=[A0F07D60:01C7333F] X-Spam-Score: 0.2 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ips-bounces@ietf.org The PROTOCOL_IDENTIFIER should be 5h if the identifier in the descriptor is an iSCSI protocol specific identifier. Thanks, =20 Jacob Cherian Dell Inc. Ph: (512) 723 3247 -----Original Message----- From: Eddy Quicksall [mailto:Quicksall_iSCSI@Bellsouth.net]=20 Sent: Monday, January 08, 2007 10:05 AM To: RAM SUNEE; ips@ietf.org Subject: Re: [Ips] Device Identification VPD Page for iSCSI Targets Referring to Table 296 of spc4r07a it seems the value should be 5 meaning=20 iSCSI. Eddy ----- Original Message -----=20 From: "RAM SUNEE" To: Sent: Monday, January 08, 2007 10:20 AM Subject: [Ips] Device Identification VPD Page for iSCSI Targets > All, > > Can anyone please clarify me regarding, Device Identification VPD usage=20 > for > iSCSI Target. > What values should an iSCSI Target use for PROTOCOL_IDENTIFIER,=20 > ASSOCIATION > fields of Device Identification VPD response page. > I have noticed that iSCSI Targets are reportng to Initiators as "SCSI Disk > Device",is it correct behavior? > Isn't it supposed to be that iSCSI Target needs to report to Initiator as > "iSCSI Disk Device" > > -RAM > > > > _______________________________________________ > Ips mailing list > Ips@ietf.org > https://www1.ietf.org/mailman/listinfo/ips >=20 _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From year@oncologia.com.br Mon Jan 08 12:05:34 2007 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3xwE-00029y-QK for ips-archive@lists.ietf.org; Mon, 08 Jan 2007 12:05:34 -0500 Received: from p54b4e986.dip.t-dialin.net ([84.180.233.134]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1H3xvz-0002k9-Ra for ips-archive@lists.ietf.org; Mon, 08 Jan 2007 12:05:34 -0500 Received: from Paule ([155.145.198.164] helo=Paule) by p54B4E986.dip.t-dialin.net ( sendmail 8.13.3/8.13.1) with esmtpa id 1kdIRQ-000WBL-cm for ips-archive@lists.ietf.org; Mon, 8 Jan 2007 18:05:44 +0100 Message-ID: <000a01c73347$251f6ea0$86e9b454@Paule> From: "or old" To: ips-archive@lists.ietf.org Subject: longer doeeyed Date: Mon, 8 Jan 2007 18:05:06 +0100 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0006_01C7334F.86E3D6A0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 2.1 (++) X-Scan-Signature: 6fc5b1c74c5bed09a3a9da2884900dec ------=_NextPart_000_0006_01C7334F.86E3D6A0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0007_01C7334F.86E3D6A0" ------=_NextPart_001_0007_01C7334F.86E3D6A0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Iraq plan odor worries workers! Our biggest worldwide artists we remain percent committed. Road to = redemption january local? Today reached out through, web site with. Itself wake shattered despite persistent? Road to redemption january = local and weather amp morning. See same way ishiatt cited shutting down = popular fan. Really good, being, see same way ishiatt, cited shutting. Artists we remain, percent committed. Its, former golden child asserts. = Terms, use privacy policyyour, california rights external. Theres some kind event chances heights was at! Fine said continues our biggest, worldwide artists. Of flashes privates gets press months? Kind event, chances, heights, was at. As mousketeer fledgling pop star = leaving west. Bigger better than ever also! Rss, headlines bush announce? Recording, sessions might, drop its former, golden child asserts. Half = yearclean belt industry experts support, quality may irrelevant! Across = nycwhite house wants, khalilzad un. Plan odor worries workers. Saying = last couple been, quite. So many women go for. Why do so, many women go for bad boysspears. Being see same, way ishiatt = cited shutting. Excited, about releasing second half! Yearclean belt industry experts, = support quality. Tory johnson how fun parents, allegedly. Finally look = forward coming this, year bigger better than. Spears will have work hard. Sent tory johnson how fun parents allegedly kidnapped. Associate, editor brian hiatt thinks musical genius but used. Repulsed spears will have work hard revive career. Fun parents allegedly kidnapped, bride regret their deaths. West = hollywood restaurant jan looked bloated. Web site with statement saying = last couple. Help info terms use. Some kind event, chances, heights was at. ------=_NextPart_001_0007_01C7334F.86E3D6A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
3D"mehellipI"
Iraq plan = odor worries workers!
Our biggest = worldwide=20 artists we remain percent committed. Road to redemption january = local?
Today reached = out through,=20 web site with.
Itself wake = shattered=20 despite persistent? Road to redemption january local and weather amp = morning.=20 See same way ishiatt cited shutting down popular fan.
Really good, = being, see=20 same way ishiatt, cited shutting.
Artists we = remain, percent=20 committed. Its, former golden child asserts. Terms, use privacy = policyyour,=20 california rights external.
Theres some = kind event=20 chances heights was at!
Fine said = continues our=20 biggest, worldwide artists.
Of flashes = privates gets=20 press months?
Kind event, = chances,=20 heights, was at. As mousketeer fledgling pop star leaving = west.
Bigger better = than ever=20 also! Rss, headlines bush announce?
Recording, = sessions might,=20 drop its former, golden child asserts. Half yearclean belt industry = experts=20 support, quality may irrelevant! Across nycwhite house wants, khalilzad = un. Plan=20 odor worries workers. Saying last couple been, quite.
So many women = go for.
Why do so, = many women go=20 for bad boysspears. Being see same, way ishiatt cited = shutting.
Excited, = about releasing=20 second half! Yearclean belt industry experts, support quality. Tory = johnson how=20 fun parents, allegedly. Finally look forward coming this, year bigger = better than.
Spears will = have work hard.
Sent tory = johnson how fun=20 parents allegedly kidnapped.
Associate, = editor brian=20 hiatt thinks musical genius but used.
Repulsed = spears will have=20 work hard revive career.
Fun parents = allegedly=20 kidnapped, bride regret their deaths. West hollywood restaurant jan = looked=20 bloated. Web site with statement saying last couple. Help info terms = use.
Some kind = event, chances,=20 heights was at.
------=_NextPart_001_0007_01C7334F.86E3D6A0-- ------=_NextPart_000_0006_01C7334F.86E3D6A0 Content-Type: image/gif; name="our.gif" Content-Transfer-Encoding: base64 Content-ID: <000501c73347$251f6ea0$86e9b454@Paule> R0lGODlh9AEQAofoAAAAAIwAAACEAHOACQAFe4gGgw56d8m1zr7TzZ3F+UMUAGYTAYoTAqIhALgd AOMWDgJNACo9BUtODW0xAHU7AKIxAME8AO43AANqACRdAENXAGVuDnJfAKxpDs5RAO5VAACACCp+ ADRzAGSLAHx7AKRxALV0ANF2BwCmABqjDT+mAF6dBnmeAJOpA8SlANSbDAC/DivOADfAAmOzAI63 AJq3ALmyAN/BAADtAx3hBUDaCFjmAIDbCZnsAMzlCd3VAAALPxsARDICMmYDQn0JTaYOSMgKMuYA OQAaMiQpTjwUQG0dO38mSK4sTroXMu0dQABDThE6S0pGSmY2SolMQ6VCRMU1O+JHQAVnMxdVOTNn QWNbTIVkDK5YP8tmSNFVSwCNOBR/PTJ5Om1zN4GFRa6EN7WJNtF/PwCoPiSqR0abQ1eYMXKhRqCZ QLinNOahPAy3TR2/NjbGNGfNSXi6Qpm+NrTNReDKQADaORbRRTzlPWzjRYvhOZfmQLXWPuLgPgsA gRkKckADhFYDhHwBgJgAc7UMeuQAhQAShiQsdEkYdW0iiH8Ti5kqisAWhNEnjA5KjSk8ezFKe11O inw4eqI4g7w+eekxcQpSjSJZfjtWg21keXljfp5rgbJYg+xajgCIfyaBgjN9c1+Ef42Nd5SIfbSE jOSHfgiaiRekikWghmKjeHateZWYh7adfdqlewzKgCHHjDzIeWPNiYG+h6vDgcu0ieTHcQDdiSTi ckPTgVfYjI7th6DteMrUgujdegEDwCYDxEQIvFMCu4IAvJQMsc4Au+MAxggtxioTxTIlzVgUxX4U uJwotroewdUsyAA0xSE6zEFDtV9AxoREwpo6u8A0yt5HyQBWwyhrzkJSxm1iu41Sy6BovsxTy+td uAp4yBmMtjx1y16JzXF3u552ubSGzd+LxgqhvhqkuT+SyGiazH6UvKCcvLGcxOukswO9shnEyjHG y1m7vorAuKq2tP/s+piSmY54dPwABAD/B/L7DAAM//8J9gP/////+SH5BABCu20ALAAAAAD0ARAC Bwj/AO0JHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePBP+JHEmypMmTKFOqXMmypcuX MGPKnEmzps2bOHPq3Mmzp8+fJEEKHUq0qNGjBYEqXcq0qdOnUKNKnYoTqdWrWLNq3cq1q9evYMOK HUu2LEWqaNOqXcsWqtm3cCO2nUu3rt27ePPq3cu3r9+/QeMKHnwUsGG6hBMrXsy4sePHkB8enkz5 ZeTLmDNr3sy5s+fPoEOHrky6tOnTqFOrXi1VtOvXsGPLnk27tu3buHPrhsu6983dwIMLH068uHGJ vpMrX868ufPn0KNLn069uvXr2LNr3869+0/NAMIP/xRPkPz48OjJpycIpH17gsDiD5RfHkDB9xEJ 6NdfML398/8JhJ6A/p1X323eZceQeQ2tZ8+ABBLo338TUlgggAYSxN9BDEaY4YMBQghifwF6+JB5 KIaoYokQpmjiiBRNSKKDDm040H43EiDhh/bsZyOMHuIo0I8XglikjMfB1eGCK/II5IsfpqgeiyIe SKKTU05ZH4NLKtTlkzA6KKaKL2Z5YYUmuuiklyUamaGIagIZHklz/oPeSHXaCQCee+p5Up5+JtgX oC3lmZ5IhCbaZ0mGLnpooIjeaRKhkCoaaZ2APhopTJRuSmefj4bqKKiLQuopn3+OiupMmuqJKamv nv/qaaawkirrp6kKOlmnKjUaK67AMqrqpnM2equpp1rqZ7HDGvtSp2BquZ6ZcUbbZpdxfskkly1a qKW1ZXprIZRrgpmkkm0yaaB4HbaLJJIe0vitlfS6Gy+c45LLJkL2jjhtvldieW26RlZZsLYBu8ju uAtDOW+Y9jVsroTyFnkuWQhzSGbBAZcr8Zv40rhmtRBTDCC+EH3Z77cP89jvyd1OTO++cop7b8sP sxyzxg0SfLFXGRukpsjgCg1wzUe/7PLGSIerL801R5lvyyAb3bGVCAd98MZjmmytrL+KihKvwuq6 lropM22w0lJLnfTAM1JZpZROb+2QxQfPfG9CRDv/THC2pZK96qyj2nrp4LQmWzjihpc9uNlUbWuw xvOuPfCZVP4sFNt124323js2DbPR3GI4OsUhT655UZC3LtICC5QUwOy0B8DT6rif5fruvPfu++9O 5S78ZcAXn9zwyCdPvPHMB6+85s1Hv9Tz1FdvPXLSZ6/99tx3X9n1mHkv/vjRg2/++einr/767Lfv vlDkxy///PTXb/9K7+d+//78S5f//1zpH1oASMACwkaACEygAhe4EwM68IEgYaAEJ0jBCqIGJO7J oOTk1rfrZRA/5IJX1J7mGgvaZIM7A92JAKatI3WLa0NTXVHQtBDAachH9WJa24akIx7myGsOaUqF /2p1OLC1aiU+IsCkSuWqT9WKUooSHO+URbiY/ApZjGNcs5xVKS66SopOTBynhtXFLCpuicB61RV9 JalLHaqG3GIh3DqGsjT5jI5zNF3oSLYkd4Vsh7dRGtXgaEee8WtFU0sh3QpJwhyWi2ZdK5oNrxY2 SXHxkkxkSRubGCgoZpKNVbRiJsNIyi+ekU9ULCMnVdmbFVJSXDLcUupSaDWvmYmRHCtZRFZ2x0Pa 8mgQE1kfMxehfzmyagpZohpt1SlPotJwYERjSlolqjUGbpOsFJY1j3e3y2FulzA0pDgbJq2IqW1n WrtaMDtoNWP6rZh5XNrJgDhCFXbzlrmsZQ6X1f+4Z40ylPxklhvFKEYsuvGUrezmKxs5TmDe7Jy/ BKLCzMlQcdrznjZ7py5DSMxcClOH1ArawiQWy2GCTGcivWPlzElSn+VMhwf6WDpBI0iHEvKinYsh SiHq0YxCDaeSk+gcJ3nMX5aubjOFZ0tVli6dvu1zpKujzg750ZMmkmS0qSnqUloxFwJykYscYSQr ykuJjOmo9VxnSPVZtCcNEpKJnJhJ7cjTm25Ul1NlK1HxGsvN+NNxx2LKhA7axcZZ8rCoNONKMMmq ayozmkoRG0JdUkmAPs6UhQ0jZP3zuCuuqpmOxawqfXVZEzJFAQoYCWpTOxLYuTZ2Lamd7bAz2Nb/ vhZ2DEGtQXRrj9kNxLdJWu1qBcJbewy3oo4xrXKXy9zmOve50I2udKdbGggKhrrYza52t8vd7nqX u9YNr3jHS97yVu+76E2velNi3va6973wvcp6RxLf+i5kvmmxr373y9/++ve/AA6wgAGM3wIb+MAm GbCCF8zgJCH4wRCOsISd0+AKW/jCGM7fhDcsvgx7eLwT/rCIR0ziEh+Qw/0z8WtQzOK7qHh4LU7x gmOslBfThsb+s7GOd8zjHhsHx0CmsI8PQhXIjgQCEAiykvNCgSY7GSdIjgkDGDATCpgEyUn+oqSy vOQuoyTKR+YyTcD8EjLDBAMnEYBJ0EwSFHgZ/8gMgQEMfAkkHNjZzva480CwjGWC8BkCM0Nygw6C A4MAmiACGLKiLYIBDCCk0QKBtEAEQGl7UDrRlXYTjOQ8EE4LRB/6IAgKUNCQQxdkzv1J9aIF8maV jPrVbg6zmeUsElr/w9a2vjUMRNLokfRaJHaeCZtLomZil0TMrUaxRPAsED77+dCCtke0Rz0Qakvb 1NG2h6cjQmqhGQTVAwn1qsc9EJnkic8k+bW62UxmMLeby7mGSaxLggOTzBvYXl61JkMrEkoTu9j+ /kfAnRVwgRdb1yQBAxgKdZJdl8ThR5YwuRtSKM6SpOAiUXjGF/4Pjf/jg0BIuMI93u+Dd5zji/99 lHtKEnKRj7wvE7cvCGNOlGTrxcg2byDNOXIT/eS8JDsP+oh/TnSaCP3oSE/6A4uuHKXPxuauSapZ J/JRqTs9f1ZnK99oWJGsn2jq4xFQeYLDdLfYteu91DraN9dVl479QW+/OnmxVXVEpl1gs5SllDhX Q7jH3e+qFjvgBy939+075QDFeRSnadjGB4uydmIUnf40+cjjqez7g6oh6Z42dSYsnMg9++BdKqa/ F966dG+73kQ/zLGG9O49C5HpOST42p8e9U2FaVo1/7KVhj5lgmdR2L1te9gnD/PmzuTsREI75s92 +SJBLUygb9uSSP8fq30dbF3r/JFQH/usjcn/86NPkvDPNvrXV232EZj0fWtKtuc/Yj7m75L0i8QB DjDJA/bP/5Hg///5N1Cyc371J1yqVX7Il4CAQYAiMX/0p4DLRT0OwGMQWIEWOBVBd4EauIEc2IEe yGG3lxlSEW/VcW/0E4IJwRJ3dmc3MWqlVRIu6GvDJkq1FRO/VhMzWHkn8Wdchm4faDw3eIMzEYMu YWY5QYIxAWo20WhMOBKgpg8pAXE6aCcoqD8rkWvx9oRKKGuzBnE3qIUjIWdiKBJEKIZIyHgPZ4Zh aIYO92cjgXEqkWTIFoYpYYIiIWZzaHZVyBmSZg99uG3bhmiJNmmD6IeOtlF9mGeFJjMLYW2d/xaI mWZphRiIiugQcwZuBbGIB3FpkWhq0uYVP0gZnIhxcAAHI1GKO9iDXFYnJHdxJtceIgGLMtGK/2CE XHSGL4GLUOASpnhrJCGFobgd6tIhI1eMAwFyxwgEH2KMAxGJkvh7glgQzmgPCjcQ1SgQMzcRl2YQ hbgQymgP34iNHxGMyxEfImGOIyGLgJUnPicS7UgS7/iO/9CO8vgS9ViPXFSPMtFyLZeOLqFE8wiP 93N0IARCarIhQgIk/MAP2PiNBlki9PEjD5GNEomQNrKQ9xGODdFDPXSMgQcM8CEQIDkf4oVj8viO FueOSTQS6Phx/XhEiCWAlMVElJJEAKmSN/8JWSv5TIvSj/O4H/AIlN6xh8/jdfxClEgJEhJ5Ecbn GeS4QClJGUkpHE9Zla1xYVZ5HUlilF0hexaRldpjZFFpE4z1gjxxRGNzeZqEP1MZdXFkVk3JiHiU EUx1FV7pJcNHeLPXlrMxN1Y3U3ijdqfjOVtlVXI0S/FEe7UnfIs5aHwJGu5HRDI5NqMUldHEK84S k2VpKtvESQWVloiilqE5mpZXmm20J9gEloARVPmENZHke8hVlyoEm2kFm1gFR3ASd3dJIcOHIh2h ms6zL+70eZlDVFojmxtFm9Vim7rXd72pm3nJm4Gnl48ZGiNFUYVpLXFUMT1DZ8kpR4D0nbj/dDdv x5h+Z5qJRZqlCZx/wRC4ZQ/v+Z7A1VsBIBDzaZ/3SZ8IkZ8JMZ/A5Z/1aVwKMBC8FZ/vKaA8wlsA KhAHeqD6qRADSqD2+VsB2lsD0QC/ZRANwHwkwYDsyRcM8Z8BClwGugD4WRCvRRDFVVz24IANAYAT eKENMKMYeqI2ag8wGqMPGjrzNxAO2KM3ep/8WRDCFaH4WZ8VGiBGGqEVGqBGalzVqRks8X3dN1B9 MqMlQX8PeH8AGD/n13zq+U8fihdCMaMFgX8CgaZRuqZsWhFj2hJtGhlvOqcxEad2eqf31WJ4uqd8 6mBv2qc7R6fLAaiEmhEgWKiImqiKuqiM/9qojvqokBqpkjqp5yOolnqpQ0mpmrqp6IOpnvqpoBqc nDqqjupdpHqqqJqqqrqqNxaqc8qqQheMsNqnrlqrtnqruPqqsxoX67WrvvqrwBqs/KUXwJirRTds efgSB/dPJtc6OYgSzWpw0SooyXoS9cYT02o/DKGJeUYQ3DoQh2gP3QZ8k0Y9nsg3B4GJGnGuHsGu R7kR4bqtGRGu3dgV8dppFpFt62oV5gl4g2iGnwgRnAh3cxNuoIZRzSiJhchSspSXfkdqr/Zs2QZr Y/cwzlau29hsfdYrJzFsbGhr2ZoWISt5O1GtJlGsM7GKOXFwLPuGl/aGBieaUxgTKHuyav/oihhX s0bXiNUmrj1be5p4rw0RrszWrQKBaoVYrwsiEI7YbX14iNy6iJ54aL6pbQYRtY94tKiGalMbaeFK rw3xrQIhtuPabBERrn3WEBELrkzYjBm7deRBsUPbhxDriNc2sT+rbWIYe/YBaGk7Edi2Z2PrrV6b iZvYdY7ZmHmprhfBEhC3a48Ls6Qph0aYEr34D7s4EpkrcOoZE8UmhQ4Huv12cbX2i7FIEi1XrJf7 D5fbsqPri3TIuZIru4t1EpsbcSRhsg1Xurwbh7gruiJxu74bpizhugU3raBCmiY3srF7ciOBcjfL Ers4vZjbvLArvLX4vMVYcXlSiqjIsWr/GbJc9nI14ZgRY3tgYI3J6JEMkb7lmrDiKBAj5xAfFL/x q5HfyJjuK7/2C478GzfmEY4CLL/F6L7467AJsb/sYRAK7L8Q4b5x2cAObL8SjBCFeMALIcHdqLQO nL4K/MENEY4gPMEkjK7nGyAjrJH/O8IKwcIVzMAE4b4cfB/sOxEtEXL9iMOoOxI3eZMByRL9CAwk IcTnaBI+jBI+yY87/HFL7MMA6cSn64/rGcUmkcNSTMQlAcXueMMn4ZNbLJAwkZM6GY87ycQt0cNg jETxmMY7eY9lrBJWLMVaXLuoWZpafMRmnMQsMcd4fBJl7MVd/BQ6fLo+eZNYPMfga8ZU/0zEjgLE 6dhyWqzHP/zFWIyOgdO5/8APJKHJIsHJmTwSnHzJ69nIjjwpRsxyVlTFIuEQDFnCJNkQI9kjGgIR I9nKAtHKjKkjHUmdCxHLuZxE9FvD9mDLw2x7Itm/KqyYtZfMyryXBhEfsayUsjwk00zNBoLBDPEe 5hkgC0nMCoEjPcSY5olDGCKdiykiGhSd0ZmbDpsxF5KQxuzNSwt4d+eV20yexbfHPEy8ppm86Cmz 0ySzfdLHa9m53ezJmdRyogzHS/wPWJzIacxwS0GTEo3J0sVED33G6ckS0FxKLJnRKIGOPvKPa7zP nbyQn/zPonV4orzQgkWaYLTQYjqzAv+tylQ801Lh0tSV0dDcknORG+z0Eb7MLiHsHs48nXGDEPAc l0RprDonrFBNqckW1VRd1R/m1FgtQDid1akRHFVVL0RRz3/H1Eg9GHd5LmStOf2adr2U1kOxm3kU l2Qt1u3snO8KErBXJIlMyrVL08nxSTgH0Nfh0jg901tNltwL05fXyHxd0SmXmqYcmnxNTRDtE4et 05Sn2AUt2PS1GX8DM+rRzKKx2XUM06d5WJgy0ZCn2ZHH2Jydlpd8mn5Nsq0tmuX5QrzZVw1bfPQk 2ogEncZ81+ecNbo9T/SEndu5JYk7e9ci2rjRpBY6oQYB3QyqofZAow5ROxm63cKVWxT/SjsDYaLw Od7kDaUOMaBP6p+8nYIc+g+2M34nEX8HaH3hF34pYd+sRYDnZ98pAVut1d4A7t/h59+V3Sf6TX7X h98sQeAA7t7qh37k5+Dex9r3fRL8LeETbhIMjh3jB98mUd/+ZxLU56EmkQ8kYeLYh4ANrhIonuLz zVqpBePzzRItXuMn3uAkbhL5F4D/sOMn/qMjgeI4ahDiXd0LoaNDnuRpOhBInhAPUBBPHt3SLeVL +qI5KhBRjuU3Wt5cvp/TTRBJqs6jF9wKkQ8HkeVMjqIH8aSjvZau7X21M+M8/t90rhIH/g8E7t8b 2hLm16Gsfdiyk+EYLuEPQBKFzhI+/35/PT7jLo7ngh7ikG7nfj7o5zfnKcGAs1WkfU6aFx7fgd7j MBqaBHHlC1GhEnrqSq6jMUqj2H2kL+rcbG7qCDwaLBHjBzjgJOHfi2Lpjl7nFT7fc87jOa5/I7Hn IrHnIB7h/2Dsj50nwX7sxc7sl47h7x3kQd7ixr7heV7rKs7sxj7sNx7uOR5+h/4sJNvpDJha5EoQ RV7euznlCGHmC8HmSw7lZf10iL7ois7jxo6lyv5Jsz3p7b3tFm3h6rd+y34Sxt7pIv7pz344gF7u IiHxTbQo+20S3r7ZlkdGDF8SEl/uBN/o5Q7uvt7romzpH88SFD/KM57sLf4PKP6lKv/Pf+WeSfzN 64OuHdIu7f+n79qHfteH2RhPEnvO4/jH6JIuRCQb8lEBfXHe668TW2CqfbFD4EefYEwOgGf6f+ye 5sTVEDV6ocZtD2h+pLKeEFp/3GLemq0Ol23S7tRZ9rROFQoemSTR83M+ZY/NXGXR5K/BAETa3Vat GK6qY1xtF6r6p4O/+Eh3+I5fp4wf+QX0+B+qdJTfE8J6+Rb4qJqvmirW+W0h+QYB+trF+KR/+qjP YqK/+qzfXql/OzH3+rI/+7Rf+7Z/+9/TqLi/+7wvcdXZ+8Af/MI//KrR+ihI/MgfgcZv1cnf/N2z /Kzj/PMD/dRf/fsVio0v/f9g/Zv/OIo8WYNAtnIsB3KAbJP6yBPkn0E1kf7ij5NCecbvP9KPrP6r 3CMVaZHA/BAJuf9LCc88BBAEBA4caM+gPSAJFR4seNBew4UOGRI8GDGiw4sSNdoD1hGYQ48SFWZE mLCiSYMkN65k2dLlS5gxZc5k+c/mTZw5//HjqdPjTY/AcAIgepNoUZ1Jfybl2VSnwpxHk07VOZBp z51YqeJ0arOrTan/wnrVSpafTav/CG7FufSfW7dAO25NGxVp2LFgkcbNWTcv0rZz2d4cCYRwwqF3 AYsFPDYv38GRJU+mXNny5alBhSYGYLczWoF9Qw+u61OwZ9SY8+r9zFry0c6wb5b2/7uY8WfHtrdC /cebN2fds0fjpE3ANWebkI0C/koVakyCBCZKN3jUofWD2LUTlRiS5nfw4cWPdzi5cGrkt3WuTsp+ eWuuZbOexVy6N+Kcv9lKHWtf7Wj97jPsrdOUy2wuzQjcDDj40EvutPVswys4s94brDm2ojPuvw39 qy022VZzDzMSSzTxxJxkEugh6g7yDqSOUkIJoxlZelEj7CRq6KCmxMuxOu4k+tEl2AC4LsgjjbRn SOx23PEl67iTEsnsjKSyuxiTZInJIIfUskovwZQpSiW3U/LLJadMM80zDbqRPDjjlHPOjchs80mD GvIyTCGvRBPGjxzqMTwu2wTS0P+WiqQRCI0iwrMh794kUs0pDbVzpSHxdEjD6A61Mcsk/WSxRSgr ZTPPFXVM9VRKr9SUTlhjhVUyq0pjb8IG1duPQl0dFJBEEXUbcapgcw3LvrSK5NW5kQTED7kRAwww PQt7jTDXagNbkLTRQktW2MUSTNBXFMs191wUOaW22luXPa694IoFVkJwsaXKvnZxo/ezWoebrMjb dFM3KXx5ldda0TaE11h301P23Ww59HYtctG1+OJyYcpxYz+R3BPROkX1FMcr+dS45I5FxhRlRM3s s8wuVV7ZTpbBXLhiiHUdNrd1c94qN1yvZTBghu3F+GikzwU64l4P3tVo95y2LN//ngejOttCR4Zt pq0PtdRjUT9uM+avYQZ55FPTfnlMsDkem+Uzu/5TVrrrtnvNI8X0Gk25Jz1b7blNLhVkl2kKs3C9 1Xb775DjTrnPxkkmG22tVf5R2ZnZfptKxPmW+W7QQ4/J6n1ZA9iz018zON7SVaPw4alfT53Bxf4a Vuici5V8ZrfXZlNRrxmP8/JC+ex9d9GTV355OZVt+3MwgWd+euqrt/5637HXnryku/f+e/DDF398 8ss3/3zJtld//TnRd/99+OOXf37667f/fvzz139//vv3/3/wsU+AAyRgAQ14QNABUIELZOBlEPhA CMKpgROkYAWTEkEMZlCDG+Rg/wdFZ0EQhlCEIySh+Ji3ABSmUIULcMgKWWiQFEokhi9RQA1r6MHQ lVCHO6zf4BLnJQYEsSU23IgDjGgQIzrAIEFkgESYGJMkHsSGU5yiS5h4xSvag4o3ZAkEvKiRJIZR iU7EYhZPJjcxppGMTZTIFhWgES/GUY5ftEcA7GjHD95PjLjDSRj7aETV5aWMWPxHEnNiyJswUX8v ieNBGmmQRzrkji2hQCU1ggFMOiST9ogkJOn4kidqpJIUAE8oDxJKM2rElKcU4hJXucqZjNIgslzj lvxEy1GSMnLI42QnO2mPXNLSJXMkZi8hIJFHElOODgmmLmECS8DNMpcHESZL7v8YgDpOUiLVjOaP oLlBAYTTIOEUwDjF+TKVoUCdEsEkBrr4SU8eEya/pJzmJELOg+ATjsvU5CYP0s5/+nMmvpSnQ+hp EHUmFJmfPKg99LnQgs7RkfB86EPnCU+HnjOf51ToO+XZ0H0W1JwWNSZDMbqRSNLzlwDtpzsTV8DI kPMf5AznTGuakzlSJY450UdPqSK1rexUJwm9jFBvQlSbIBWncsyJUo+qTpu08zIwoOpgjNrUhKKA pz61SU/1QazgKDWnNjHqVf/hRcqYVa1oPStbb7YcyazVrF71ale5GlS3mrWtEFgqX3FyValSUKY1 JexNE8MYqgT2JnWdSjsd61j/ych0qFC1jFmV6tSn/oOyN1EsZzFJVremNbRT0WtStbpZ0Pp1r1Oh KgySItl/tLa1NpmtTQVworne1a5fRRhOGFvZ0X72szghKmUx+1rJGpa4qP0HDpybE+fiYLlazR9M FLpO7K6zpfZgqUZI2lqWgNch4n1Jdw16UpiQF6Ha7ShEjXlekcYzeNJriWxhwJL2OiS69tjvQWpb 26QAGCfRtZBi9GW0yQg4tlXFSW0JDFYE41W1C3atgAl84edGZnZ/Ha0ymfpU6uIvJllFgT1IvDs+ eVUiKl5Jfk2s3Zew+J4a5dqVaErSgLrTvGKTr3jsu0uJgFe9dJXxRtTrX6oi//m+Qk7ye8nzS5Lq M7pT7q89fjxQeO63ytzdZCbNyxJx0tTITX4p4I48wLgydawNtq9rk4JZBU8XqyFmy4NxVucMexYD /+gsTh473NTqRKi3m4ydbxJn29IUJ4NVLh+phVSoIhVoDfMzoGnL4EMzGNFz3iyVpZsT2BKtdgYm NIUz7WY5sxnVl151aRUIBljD+h+xljW13AMHXDsaKXKVDK7hkJRpRUbB/8X0TaBwbGMj2yahXvZt A30iZs+61rYGjK9tYm0IA/tZx4aCTbjN7WvnGifYjiyNM1pOh+gTpCGNSY7IS96Kitkl8Ub3eMk8 0hnXO5odHMlJamSPWB8k4P/eNXdJUBKRrMFk4BJZ+EwaDnBYG4TW2cvRwxeuEoWDwSEP3/dFLqJP eRNc3/4muYwiYvGIywTlGt94yjnOkpdvZOEzT/m5N4pjkd+clyYXyb8haJ5nTYteBPMXTgozIA4l LDLnUbplAjRpoyPdJs+qC8VAozDKLEU5KlkVqqYzHVKVmedjN/iMMoJxljyq66Miu0ZAxZG3t2RH /zZ7jfr9koK8akgkObvPBTiZqhcdWUW3X6mVAqFfHQY/B3Ne0Zyn4Q0zjS9ah1BQTLOtq4/GdqNu jeEVz8f+EF4umzHQe0KP9aRbSzaQHxFfpPWsxPNQ9rNfYHEEr6HKRA12ptv/Pe5pP0EcBl/4wyd+ 8Y1/fOQnnya/Z/78lP986Edf+tJvfvVNNH3sZ1/72+d+973/ffCHX/zjJ3/5zX9+9Ivf+utnf/vd /374x1/+8zdf+u1/f/znX//753///f9/AAxAARxAAizA8KM/BEzAwTDAB1JAB3xACBwhBuS+CKzA BppADMxADdxADuxAD/xAEAxBERxBEixBEzxBFExBFVxBFowgC2S+FoxBGUSzF6xBG7xBHByfGWSf HOxBH/xBIAxCIRzC8tlBIzzC7SFCJVxCJURCJ3zC5WFCKZzCHITCEaRCLMzC9rNCLsxALfxCy+hC MRxDMixDMzxDNExDNYQ+/zBsQxJZQxQUniVZCWJxw/ehtNwbChCKsPD5DACUQzm8jvCzkuEzmUAE j0O0m0TkGhxZnjKhG+FZxC2ZQyBJHkBkREGUlUhUxEShRATSsJ+hDP6Aj6URC6Y5EdzQw6i4DFKM Hz5UDe+JDbD4ntVLkUwEnI2pDnQKle/YxLphHEJsQKsxPaxpDFM8xlRcxWOcxWU8sFdMxgZpRRQh Rcc4xbdSD84zCmZ8mmJsDG/sPNOpmkZ8xDHRRU/MRXL0xEk8R3OkxGB0x+xox0BEnONRHDX5oXoU HJgaxm1Mxn7UC21ERmJcRoFkRnDcD4M0SFILyFr8mbtgyG3kx4L0R4gkyP86VMWCzEhl9EeKFMVv 1EZojEiFDEiLbI9/bEaArMiM5MNovEhpnMiEjEmNfMUGOsiZVEmYREmC5MiTDEVZDEmSBMqSXA+M hEaaPB2hXL2ONMmiPMloxAunpElljEqQNMXOg8qg5MeD3Eqd5EqRhBeMDMedVMqYREqcxMMeegls Moi1rCODeCMpikt1XEu6ZMuDqMt41CK5jBu1dEtsWku4bABJuku7tIcXMsy+lEu9XEwYOsx1dAi4 jMy3lEvJdAm4VMzAPAjBZEzGhMu13Ex7AM1soom2dMvCvEy9VIB/UE3VXM2baM0AwInYtInZ3IrZ rM3bvInZbM3W/IzWdE3/4AzOXaFNnPhN3gxLmzhO4PzN12zOf6jN12TO/oGJyxwjexijfHAI0NzM 0sxOe/BO77zOKHrLytQiLupM6lRMJRHNtlzLMbpM1FyJ0rTO92yjxDRNvARMymxHlohPvkTP63SI BziIAV3M/8zLcjwI+pxMyFTPvLRO8jxPlgjP8WRLPJJHSgxPDc0HDpUJ/cRMBjUIDTWIAi3RwsRP wgxQjQhPDBqMFLIJB7iJGP2HfMiJO9LNpJnRQoqMBriJHmXGGr2JBRBSm3iAIr0JI2UL6MRNhaTJ Fz3Sf0jSJC0kRJrNH1VSO/LRBrjSKZ1SwLgmmxjSfxDTMU3OGrKMKe3K/6lskzASUeqJT/l8iQeY U+0ETRVSUOvcUtAETze10PZM0e/0zgrNoPgL0n/Y0pMMUiYdDESdQjJ9F6ncH8+TQjisVDK0Qy20 VE3dVE5NHkzF1E69HnSZMHMh1R6csEh9n0YbjD37VAd0M2dLKp1YtQT7q/kx1XMZrVL9B1mJJPoa jxKbJ4cI1vHgp+GBJIN6IOgZjzOLk/jCHpF61vAgVv5SHvJyrNBJxCmzJ0+MpJBrCWKl1nGSE2nd CJcyiPuCCar4NIzB1e5x18iA16Qg1d/iM0ALMTorF94yl5dAN381R+zIqn9CxCCRrWGFsUS5R3S9 t4PAAYQ6iGCVp299sv+YkNYi66g2cdhqNQiNPVCNkQiN7bF+1ah1s4fmyrAP8xmmJJ3PwFfaiq0m lVWIcbXKiFXLoNWtyDM+46xluwmblVk8Y1e2+Nl3JSujnamXPSql1azUkleSPKub8CuXRciCnNqA OVqohVmdpDCcfbPNKjWiRTU3I9VVczZ2/bR93VdW1QmiRdqh9VmgZYtWBVrqskmHhA87I9VYdTZA g1VVVC2/ctqc6Cykijbk2ttVJa1Fg9umYrPKgNVQa0jvkS7Kba6ezVq6ZUbAHQw629xEa9uccDPR bVqpXdqD9KuDPFuritrLjVe3ujGbEFqCdLaDtFqqRc6sGgyx/cqLjCr/nj1ZQ+Nc3x1e2fVcm/20 ud1ZogGtqYnd0I0r1h1KqqAz22WupH2az9jbnsyYYeIk75VYg4CD8fIvdB1X8+3Eg4CC9DUI9U1Q chw5dkSIikBWe2jf+sXQecsnifsOeRLfIBOSTExXK9tfAu7eRrlFOaw3dGMUmGDg8n3gcn2JdL0x +l1f9k2J8XWojatghmM5v1GS+Irge9Jf+ZUJAV5YhlXH8H0JD2Y5B2ZgBZ6VwQCDm6Dhqbthwsjh WWtd0MUJG8bh3uDhwRgQIraJH/7hZnFbtx0Q7Q1iIHYOHe5hKNZJqZu6IrZipDviwWjbBkG6Kn4t xv1hthBjLzbiGqaM/ys2upzQYieeugIGOAyOY4F7iRc+3zduiTqGY5lwYJE44BL+YzAj4TxuYRlm izJGi8NAZEUekAXBvKnoltmwxqfAYaTzjwxJDqAA4i+eZEq2DIXRj2CrDDy+O0BGlbVbCY/bYwbO Y4Nr4ItoEVhelbsjlRZBiVqekVfRCFjOkz5u4PnliJkIOzk+UElBZUdhCF5OZg3aZeWjCLyT5XbT x/NDkdJDH6urC8Sbit+QyuJoOhShj50YSH7lQEm0Hlc9Z3S+CnB+wVBt55BxZ3j2oDvBoHJW4e2p Z/B4P7RMZ+51iaBI0A2qZ3zmxeQbaNAZ6EBpt57jYy9J6OFZ1rsxaP8DIhzOmZxzRBJn9qFNIehn bhFpHhvykGhM4U9htsQCGmjpUJ2m3FrEOhfUK5+lFA7Rqz8iaUSABeC8/E+PHWl5BGn+5Gl4/Njo mRug/hPtyOmgFmmhvuh0PIh/KUWWdRhKg+rbZel/TFWJlNxYzGpJ9p4zip6mVsd0HGtM5M+drhOk /ur4PWsg02mcdked7pKXkmZcjN+hxkePSWt7Rl9LUeibBmi7xpugnpMDnce2EZPn0etc/GuirhtR /MqWVEmefI2pvFqull6izMrl/RfeE0mvlMmV5N3efUmLtFuZ7Iy17htbkutbrGnGXuq9welfDWkE vUQE/muyHmzF/mn/tpaVx1bTsJxs0/6pzN7e0Rbt4gbu5i3JyL7JnezslmbZ2kFOmyTL00bule3I o8RJiaxsz0aX6u5u4E7K08ZKjdxs+blKarzKfjRG7H7apx3ua9xuzZZv4lZup1RFabSXhsEWWfzu 61buyQ5F0MbsNX1v7+7J5jZwyjbulc3vnMzJz9ZuHfxg7Dkbn95rwr7teuIdo07svfbpnbbtwXac 3ObLra1Fz1Nxb2Q9+L7bw6oa0mbFh0Tw5gZK4Q7wbLNq+EsdqEuafT6fGm8aPJzUFDdvY+FnqMbx amxGIzdyfs5CKI9y5KRyIYzn6lFqLN9yLu9y/LNyMGe/IK9ACA1R//EQTS9Pvs1ETTSvmzKfiTdf nyqCoBeCU9OcCRaN81hpc+Fpc/IjkSRlTumkDB0lkSuymEcFnzStjCulH6zOUZyYU0n3UedM8O4u 9KNJdODU9DDtniAfdAUq9EiFD1D/bRvN0uhUTuBkgH9g9WNEJOM806jV1WtcrVYPosiwIRkFpMjA dEXa9ULX9cqwcyJaCdS08/A4oo24zLZUbWRfbVdqJbqB02c3c1lhIxpq0Lf2VLYI3KNF3V2jDAqw 1RJxddnE0VbPCXN39Uq6iXEnSG8/2keP9xdX3KN9d9fFCQ64iX3HXHoXXJ0YJXcf+KQwd7bIpcnA d5zA93F3JIenJv+awHZ7wHZsp+tpwl9jZaOIoqNUUhsdA4/SRF8Orp7Vzdp4hw9Fi2rLNq18Tax7 zV0lxtrS/V1UJd2oSt5uFyqcb/mpaOJRJ3fMXdqwpAmXkqgeYylirSgShhKUGlin567WFlaInXoT o/qWiCiDONeif3h5CtZzzXqnj+EXi+YzwTmJ6ChsfdisFyi6WV2+evvhtVn7bjC6T9rdnQzewnnl vQnVjXm/EtpPk13PKvmsxXkpXtzLBfjolfnlArXD7/bWXXysVd6+v/vBUNvJF1rP7arKqHlmtC/C //eTdLNWDa2DfKzrhXx5lwyhPd3JRx+4h/t/4C34sN2er3utXTP/YRte5cX5g7RZ6powN7P9x5/b Vm0QvW+s36WumAjZkYLflkHQ5sdfQ/l6JQnXChbhYdUIaqVWsVf7Ae5XTXJ6fZgJscd+qAf79O/+ YBV76B8xqtf+hz9fdJOnFG770F+sybf8+3Ze/wcIHP8GEixo0CAEgjAWFoTgkKDDh/9gFARAEIfA fxYHAuiokOHBkChGoiDYceM/jCEPLqQ40OXKgwlDolR4MOO/kjEhRmwoMaXBmjMxECT6b+bRnQVh DtRZtOLJgk7/CVD6kaPJlzaVIp1ZdeBXpzr1NQ2q9SxMl1+tdi1rNSnEuFShvq0b0x7evHrzwuCb F0fekXgh5CW8//cwBr0C8i6219jx4cMt+0aubPky5syaN3PejCIygL+i7RkmnTd058v69lLG+xky 3sav7c2+TFLv6r25LdeunZr1Qs0YhidmLOA4XuLF7QGGjbG56cF5iY/OXNow6szQYcN+HPs3+PCV oW+3HJx59ZPi17Nv754zdb6tBzvUG9/e8vfq6X/H+/y9Zfkdlp09BAKY2XwHKmhPS4FxVh9tDjLo H0YLRmYXhhlquCGHHXr4IYcWijgiZ0CQ2B4YJ6q4IostuvgijDHKOCONNdp4I4456rgjj+6B+COQ QQo5JJFFGnkkkkkquaRSPTr5JIvApGagZia6yGRWWGq5JZPuEf8A5WYdgRmemHiVmZeUAKZ5GYFf 7uWmZXCOCR6Vp+m1JoD8pIZni3WCuVNNXAJaV6CCGlkTolj9A0RMhTZqVU0EaOgokiryc6mZlhFo 5YF62iPnZZyeSKCfNVoJJ5z77cVnjqxWBuqcm+FZp6iV1QqaqpqWeVJ2qIWWHQHBwnoipFERJCyk Bkk60KX8mOSRRtACSWlMwDC5LLNKGsuRtNsSZO1A4DI60LjRShuTsNj+0yxBzmZrbrRQodSsu/8g q5SxFqG0bVTnYsjrW/syy+6zKN1r7LIbYcuvtPdqlOVO5T6s6EbdQtwlZr1murGvGwd758YF4iWn gUCYnNeXww7/uF92wLh8WpmcmiyqsDAT6LKre+2Xrl6qaoyZlGn+bODPa/5q8652Zqw0yJ+izPHG MofcsWZtpqq0lVlXfebPbCrdtdJ4iu3xYWmKOjTTls36NV5np71isoqmmzDFdNk70NyK6j3xxP6u hC3dfO89MeCDCyy4UuoevvjFK3ULMOK8VpzV4QUVji/EkD/MeN+Qcx733pxPbtfoiNOUZeWeV7T6 3Xyrfmy6eB8Luuuyt643tYZ+TvnmZvV9UKIFQ5s767/H23jpFSPqOfEXL665vgEXjzzw03/e/PW8 12188VRnRmrPbIs8fsYsvw2a+OOjnTbV3ntPPtOlsi8++CGz/wh68lhFr3z2ggc//aC2xy3D4c5u lPJb9TI3OP1JT4GRQx0A+dW40wnwf8bL38TUF6bwxQ9q8KvM+j6IPg9qkITwa9/U7Nc1Xm0thSVE 2o5WeCbylapXM+Sa++znNRO+kIREc+H5BsTBF9bvezq7IQ5RYzp8ectx3tKc/ypoMdxhL4JTLN2j KhiwfGWOi86T4uMKZqgxgqhyQZIgobz4xOGJkVvL2xcCaYJBeAEwix5qXofwuEQynrGJfPwjIK0S q0H2iZA7NKIhE6lIGgWykY7E3CMjKclJUrKSlrwkJuuyyE1yspMKyuSH9AhKTXqylIOcoSlJFMkA BABErSTIK/+DFMtRwnKWb1HAJBdAyyTpkkO4vOUuj2Qh+WFGAfoZYo1qqJd8jCgAm3Hm+ZiZmiI5 oC6/9NA1KWlLDD3AmoFUwC+zGcyC5KND2+QQK1+Zj3WWkyDsrIsD4jmQam5InAU5Z5F6aZVuEoSe HypnO/8Bzms2oKANKMgDEgrLf7zSj0AyZl4asKN4xjMv6dQMRfMy0O+hMjwSDQ80wcRCm1nUHtC8 qD0ckBeVli87G8WLM0OqqSGiBqL2sKllZGoPaf7moyZl5Uorag+fJvQBeWEnT4sJTo0uFTMZLZCq QlpUjpYUpla96s+AqkPL4JQzMjXqjFiaUryA1R5g9SlmQgr/TbReBqfSfCtJYYrSm4oHrajhaVLD utLDQLOp8LNpVyPz1byAdQELqJpefPpRwzI2M3mF6NHw8lTAkvUwYCWQNClr0qpeBq94CSwI9SJW lrKUmHn5hz/NBa1r/jKWr5xlandCz3Ti0yDvFOhA78nKuhS1lq3crTvXSRDWFlCgdXHtAleSzdFh 0J/0vC1yldLbf/Azuv+47ZAyc1i8bNcejN2uWIe6l8N295A0/OxmynpeunLGQCz1a3k3e1WiTtW7 etmuZkebGf3aF6M03ZhQtXtfvla1rIUV7V5iQk8zOq4gzh2IPvX5Fn6GcyC/fHDtMqzHCFu4Lgft J2pDTM+i/yrUuB0OMUE4rBQJo+S3IJ4nkTKj1qvKl0BdVWl4Z6rRHYuwMgzQy4zlK2TL/FgvEC2y ZPfCX5Zeh8ZjZS97+XuZIJsWvTxmL5Khmhmc8hfJRf5ZlnVqGZZ6ecsITnJKKZpjHzOgzWgmLZqf 3OW8FDnLl+FvlZ+MXmPy2cr/1XOmqmzjHdtUcguyCgMIkuh/UIAgjWZ0QR4d6bpIWsN2afNAFv0P TfdkixvhwN6QUtyZSPrRop6JphedakQreiCgbuBAjPIPo2h6ILVdqLx48hM6Ig64O3k0g0NS61IP RNSsznSxkw2XV//j1W2BC7QxzZafVFopFJB05Z69u01z+//YA6l0rY29pYiImiQ6CdRwpFIXY5NE LoE8tUHEEmtdIwVaXflJsEPSaWhP2y05UTZxfiRrIg3lKUoZeP92spavzKTh/nYKuR258IIEXNlw Gfi83yLqtfD72ULSTnu8k8roTGc4hYmIa0a+oPJY6DEirwxySH4dCGXmODE3DM5PXhqVn9w+mxGQ avSxmwNZheMcMvo4k24onjM9hoZUOtSj/semUx3khMwkTqSu9a3/qOpeL2SMgG5enUnn6zPiOtrT TsbMwEEvO3dRgjDz8sKU3ex2F5Ha8y7JmkiMIGD4O0EmDpbjtHFRMyvIzPquFMUTZFxg0DvkIy/5 yVsuWOT/Ojy5Gm+71lFrWeUa1+ffErvLh/4f4DJ8uSSlLsqH6O6uf314rHJ6038rXLVfV7sGWBCc gev04tL84oF/OXCtnvamnz3mRwn75TM/VpvKi5V+JjWYufBnqELk+Kbvvv3gSWXN/z74w38Yq0is f743yLj6l2/0A59zyzr/7Y7H+q6Lv/5Up1296uUw1bqxIPQqLuoxnu9wz0aAy0bk3wJZHiXZHwM2 oIW8hckAYCNpjsMoDOwoYPFl2CU5IAd24GbM34Z4y+yNkweWoAmeIAqmoAo+CQi2oAu+IAyO0QrO 4JjEoA3eIA7m4FvQ4AnqoA/+IBDmIA8OIREWoSoFIRIm/6ES6p0RNqETPuFvLKEUagkUVqEVXiEW NuEUbiEXdqEXfiEYdkgWKlIYluEYnmFllKEariEbAgkavmGLtCHawaEWyqEd/gMd5sgd7uEu5aET 8qEa+qEgDuLrAaIhkhIhJqIgHiIjRpIiPiIkmlIjTiKWRKIlXiJ7UOISYiIndqKTaCIohqIojiIp lqIpniIqgqEnEmEqguAq8mArxqIsCtMr1qItOuAs5qIuPtItMtIu3mEvBqPX/SIxfogwHiMyZmIx tmAyft8yPiM0GkkzYmE0VqM1XqPUTWMzYuMOaiMNciM4hmPreSOMiOPHkSM6pqM6ruMlmqM7viM8 tiI7zsZjMMYjE9IjPkaiPe4jP/ZjJuUjHfqjQM4iQBakQR4kQj7hQCakJw6kQ0YdQ0LJQ04kRQJi RF4kRkpiRY5jRqLhQ7LjRspjR45kFYakSZ4kSq4ESa4kRqbkRLIkTMakTJajS9ZkIM5kZtikTi4k TuLdTm5gTwYlK/6kkgilUTYgUSalUi4lU+7EUT4lVEalPTQlVVZl5EmlB1qlVm7l1mHl13ElQXil WJodWHLhWK5kWWbjWQ5lWralWy7JWvLcW+5kXDJfQAAAOw== ------=_NextPart_000_0006_01C7334F.86E3D6A0-- From ips-bounces@ietf.org Mon Jan 08 15:21:51 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4104-0007nV-T3; Mon, 08 Jan 2007 15:21:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4103-0007nN-CS for ips@ietf.org; Mon, 08 Jan 2007 15:21:43 -0500 Received: from [208.185.105.18] (helo=mx10.brocade.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H40zy-0002kF-Ty for ips@ietf.org; Mon, 08 Jan 2007 15:21:43 -0500 Received: from kodiac.brocade.com (HELO scooby.brocade.com) ([192.168.39.118]) by mx10.brocade.com with ESMTP; 08 Jan 2007 12:21:34 -0800 X-IronPort-AV: i="4.13,160,1167638400"; d="scan'208,217"; a="454712:sNHT63324226" Received: from hq-exch-1.corp.brocade.com (brono-list.brocade.com [10.3.8.21]) by scooby.brocade.com (Postfix) with ESMTP id D420E25801B; Mon, 8 Jan 2007 12:19:28 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ips] Response Fence Flag Date: Mon, 8 Jan 2007 12:21:32 -0800 Message-ID: <39BA3BC178B4394DB184389E88A97F8C01559BD8@hq-exch-1.corp.brocade.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ips] Response Fence Flag thread-index: AccxG7BAELEM4+ZqRUKRJan36QYECgAp0hVQ From: "John Hufferd" To: "Mallikarjun C." , "IPS" X-Spam-Score: 0.1 (/) X-Scan-Signature: 3eec21359cc773323f0aab45cb0596af Cc: X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0223734473==" Errors-To: ips-bounces@ietf.org This is a multi-part message in MIME format. --===============0223734473== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C73362.AC5EA3CE" This is a multi-part message in MIME format. ------_=_NextPart_001_01C73362.AC5EA3CE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Mallikarjun, OK, so I would like us to first cover Topic A (your case 1). As I understand it you are trying to make TMC and ACA operate correctly on a MC/S Session. =20 =20 And, if I understand your Slide 5, et.al. correctly then the iSCSI code can ASSUME a Fence has been issued for all TM and ACA operations and react as you have specified. In that specific case there is no need for Fence parameter in the Target SCSI to iSCSI interaction (at least at this time). =20 So if that is the case, then for all current operations we are covered without additional Target SCSI parameters. Is that correct? =20 Now when you use the words Third Party Session, I believe that could mean Session that are iSCSI or Non iSCSI (e.g. Fibre Channel), I also think it could include iSCSI Sessions on other portal groups connected to the same Target.=20 =20 The thing that is concerning me is that some of the words which are included in the document do not factor in the fact that any specific iSCSI Target portal group may not have a clue about what is happening at another iSCSI Target portal group, or at a Fibre Channel portal that may also be attached to the same Target/LUN. =20 The way I read your document, I thought that it implied that the iSCSI Transport would know about things that are happening on other Portal Groups that may be iSCSI or some other Transport technology. =20 For instance in section 4.1.3.a (under the Target iSCSI Layer) you state "...SHOULD NOT wait for new commands on third-party affected sessions - only the instantiated tasks have to be considered for the purpose of determining the affected tasks." Other than the fact that it does not matter what the other Session do, since you ignore it, the thought pattern is that you will know that you are ignoring it. =20 Also in section 4.1.3 d (under the Target iSCSI layer) you state "...MUST generate an Asynchronous Message PDU with AsyncEvent=3D5 = (section 8.1) on:=20 i) each connection of each third-party session that at=20 least one affected task is allegiant to, and=20 ii) each connection except the non-issuing connection of the=20 issuing session that has at least one allegiant affected=20 task. " =20 I think that implies that one iSCSI portal group has knowledge of what is happening in other portal groups, and that extends to other Technology attachments such as Fibre Channel. =20 If you are stating that it is up to the target SCSI layer to issue the "Fence parameter" appropriately such that the effect is what you stated in 4.1.3 (under the Target iSCSI Layer) then I might feel that I am coming closer to understanding your point. =20 Otherwise, I just do not see how that is practical since even the iSCSI target portal groups may be implemented in separate iSCSI Offload Adapters. And I really do not know how they will know what is happening on the Fibre Channel connections.=20 =20 When I combine the above thought with the statements that were made by Robert Snively, which in effect states that all the actions and responses arrivals are not predictable (at least across different Sessions), that seems to me to mean that the appearance of UAs, caused by another Session, may occur at any time with relation to what is going on at any other Session. Therefore, I can not yet grasp the need for ordering Asynchronous Messages among the MC/S connections. I am trying to see what the initiator surprise will be, and why that will cause a problem, if the Asynchronous Messages occur in some undefined order. However, at this time I am left with an unease that not only are some of the above document statements not implementable, I am wondering it they are even important. =20 Hopefully, you can understand my dilemma on understanding what you are proposing, and can explain what I am missing. =20 . . . John L Hufferd Sr. Executive Director of Technology Brocade Communications Systems, Inc jhufferd@brocade.com Office Phone: (408) 333-5244; eFAX: (408) 904-4688 Alt Office Phone: (408) 997-6136; Cell: (408) 627-9606 =20 ________________________________ From: Mallikarjun C. [mailto:cb_mallikarjun@yahoo.com]=20 Sent: Friday, January 05, 2007 2:45 PM To: IPS Subject: Fw: [Ips] Response Fence Flag =20 Trying again after bouncing (>50KB), tail is now clipped.... ----- Forwarded Message ---- From: Mallikarjun C. To: ips@ietf.org Sent: Friday, January 5, 2007 2:40:56 PM Subject: Re: [Ips] Response Fence Flag Hi John, =20 As you correctly point out, there are two distinct but related topics here. =20 (1) proper response ordering across participating connections in a multi-connection session, for a handful of task/TMF responses (2) proper way to terminate and signal tasks when actions on one session can impact multiple initiators =20 (1) is all about response fence, it is covered separately in section 3.3 of IG draft. That's what this email thread started off with. =20 (2) covers cases that IG had called as as "multi-task abort" cases that typically have a shared task set across sessions, or are the result of a Logical Unit Reset TMF. Section 4.1 of IG adresses (2). =20 So how are (1) and (2) related? =20 - Some cases covered under (2) overlap with (1), but some cases in (2) are for single connection sessions. E.g. LU Reset on a single connection session impacting several 3rd party sessions =20 - Some cases under (1) overlap with (2), but some cases in (1) have nothing to do with other sessions. E.g. establishment of ACA on a non-shared task set =20 - Section 4.1 (i.e. text for (2)) uses response fence (i.e. text for (1)) whenever multi-connection sessions are involved in multi-task abort situations. =20 I hope that clarifies it. Feel free to ask if that is not clear. The net is that the response fence is the underpinning notion to describe the correct iSCSI behavior in a few cases and some of those cases are about task terminations across third-party sessions. =20 Mallikarjun =20 =20 ----- Original Message ---- From: John Hufferd To: Mallikarjun C. ; ips@ietf.org Sent: Friday, January 5, 2007 1:01:06 PM Subject: RE: [Ips] Response Fence Flag Mallikarjun, I must admit, that I have been a bit confused with the direction of the conversation here. =20 Therefore, I went back and reviewed the charts from Dallas . And as I remembered, the initial focus was to address the issue of Multiple Connections per Session (MC/S) (as stated on chart 4 - "Non-issue for single-connection iSCSI sessions"). So I think I have missed the step where we have morphed the discussion into one dealing with multiple sessions. (I am not sure how that happened, or if I miss-read the charts from Dallas , or have not followed the discussion adequately.) =20 If we are attempting to define two different issues, one with MC/S and one with Multiple Session from different Initiators, I think it would be useful to break down the conversation into Topic A - MC/S and Topic B Multiple Sessions. It is possible that one solution will addresses both, but I for one think I am hearing arguments that might be appropriate for Topic B, while I am thinking about its applicability to Topic A. =20 Perhaps, you could address the issue as either being all about MC/S or explicitly state that it is intended to affect Multiple Sessions also, and then address the issues and solution for each separately. For example, I believe Robert was addressing the issue from a view of Multiple Sessions and if we only intended to address MC/S then I expect the response might be somewhat different. =20 Anyway, if you could clear-up some of this, I think it would be useful (at least to me). =20 . . . John L Hufferd Sr. Executive Director of Technology Brocade Communications Systems, Inc jhufferd@brocade.com Office Phone: (408) 333-5244; eFAX: (408) 904-4688 Alt Office Phone: (408) 997-6136; Cell: (408) 627-9606 =20 ________________________________ From: Mallikarjun C. [mailto:cb_mallikarjun@yahoo.com]=20 Sent: Friday, January 05, 2007 10:08 AM To: ips@ietf.org Subject: Re: [Ips] Response Fence Flag =20 Not really. Current draft text is intentionally written to not have any dependencies on T10 dynamics. The point is that iSCSI needs such a notion for succinctly describing the proper iSCSI protocol actions in a few places - ACA, TMF, Persistent reserve/Abort to name a few. We certainly hope it will be approved by T10 and be a part of SAM-4 soon, but that isn't required per se for describing what iSCSI needs for its correct behavior. =20 IPS WG has adopted what it needs in the past - staying ahead of T10 review/approval cycle if necessary. I_T nexus loss notification, iSCSI target/port naming, clearing effects are a few I recall. =20 Mallikarjun =20 ----- Original Message ---- From: Eddy Quicksall To: Robert Snively ; "Elliott, Robert (Server Storage)" ; ips@ietf.org Sent: Friday, January 5, 2007 8:58:47 AM Subject: Re: [Ips] Response Fence Flag >From an earlier email I think that Response Fence is only a proposal in T10 (http://www.t10.org:80/doc06.htm ). If so shouldn't iSCSI wait a bit until this has been ratified? =20 Eddy __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around=20 http://mail.yahoo.com=20 ------_=_NextPart_001_01C73362.AC5EA3CE Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Mallikarjun,

OK, so I would like us to first = cover Topic A (your case 1).

As I understand it you are trying = to make TMC and ACA operate correctly on a MC/S Session. =  

 

And, if I understand your Slide 5, = et.al. correctly then the iSCSI code can ASSUME a Fence has been issued for all = TM and ACA operations and react as you have specified.  In that specific = case there is no need for Fence parameter in the Target SCSI to iSCSI = interaction (at least at this time).

 

So if that is the case, then for = all current operations we are covered without additional Target SCSI = parameters.  Is that correct?

 

Now when you use the words Third = Party Session, I believe that could mean Session that are iSCSI or Non iSCSI = (e.g. Fibre Channel), I also think it could include iSCSI Sessions on other portal = groups connected to the same Target.

 

The thing that is concerning me is = that some of the words which are included in the document do not factor in the = fact that any specific iSCSI Target portal group may not have a clue about what is happening at another iSCSI Target portal group, or at a Fibre Channel = portal that may also be attached to the same = Target/LUN.

 

The way I read your document, I = thought that it implied that the iSCSI Transport would know about things that = are happening on other Portal Groups that may be iSCSI or some other = Transport technology.

 

For instance in section 4.1.3.a (under the =
Target iSCSI Layer) you state “…SHOULD NOT =
wait for new commands on third-party affected sessions - only the =
instantiated tasks have to be considered for the purpose of determining =
the affected tasks.“  Other than the fact =
that it does not matter what the other Session do, since you ignore it, =
the thought pattern is that you will know that you are ignoring =
it.
 
Also in section =
4.1.3 d (under the Target iSCSI layer) you state =
“…MUST generate an Asynchronous Message PDU =
with AsyncEvent=3D5 (section 8.1) on: 
       &nbs=
p;  i) each connection of each third-party session that at =

       &nbs=
p;    least one affected task is allegiant to, and =

       &nbs=
p;  ii) each connection except the non-issuing connection of =
the 
       &nbs=
p;    issuing session that has at least one =
allegiant affected 
       &nbs=
p;    task. “
 
I think that =
implies that one iSCSI portal group has knowledge of what is happening =
in other portal groups, and that extends to other Technology attachments =
such as Fibre Channel.
 
If you are =
stating that it is up to the target SCSI layer to issue the “Fence =
parameter” appropriately such that the effect is what you stated =
in 4.1.3 (under the Target iSCSI Layer) then I might feel that I am =
coming closer to understanding your =
point.
 
Otherwise, I =
just do not see how that is practical since even the iSCSI target portal =
groups may be implemented in separate iSCSI Offload Adapters.  And =
I really do not know how they will know what is happening on the Fibre =
Channel connections. 



 



When I combine the above thought with the =
statements that were made by Robert Snively, which in effect states that =
all the actions and responses arrivals are not predictable (at least =
across different Sessions), that seems to me to mean that the appearance =
of UAs, caused by another Session, may occur at any time with relation =
to what is going on at any other Session.  Therefore, I can not yet =
grasp the need for ordering Asynchronous Messages among the MC/S =
connections.  I am trying to see what the initiator surprise will =
be, and why that will cause a problem, if the Asynchronous Messages =
occur in some undefined order.  However, at this time I am left =
with an unease that not only are some of the above document statements =
not implementable, I am wondering it they are even =
important.



 



Hopefully, you can understand my =
dilemma
on understanding what you are proposing, and can explain what I am =
missing.



 






.



.



.



John L Hufferd



Sr. Executive Director of =
Technology



Brocade Communications Systems, =
Inc



jhufferd@brocade.com



Office Phone: (408) 333-5244; =
eFAX: (408) 904-4688



Alt Office Phone: (408) 997-6136; =
Cell:
(408) 627-9606






 















From: =
Mallikarjun C.
[mailto:cb_mallikarjun@yahoo.com] 

Sent: Friday, January 05, =
2007
2:45 PM

To: IPS

Subject: Fw: [Ips] =
Response Fence
Flag






 









Trying again =
after
bouncing (>50KB), tail is now =
clipped....






----- =
Forwarded Message
----

From: Mallikarjun C. <cb_mallikarjun@yahoo.com>

To: ips@ietf.org

Sent: Friday, January 5, 2007 2:40:56 PM

Subject: Re: [Ips] Response Fence Flag









Hi John,









 









As you correctly point out, there are two distinct but related
topics here.









 









(1) proper response ordering across participating connections in =
a
multi-connection session, for a handful of task/TMF =
responses









(2) proper way to terminate and signal tasks when actions =
on one
session can impact multiple initiators









 









(1) is all about response fence, it is covered separately in =
section
3.3 of IG draft.  That's what this email thread started off =
with.









 









(2) covers cases that IG had called as as =
"multi-task
abort" cases that typically have a shared task set across sessions, =
or are
the result of a Logical Unit Reset TMF.  Section 4.1 of IG adresses =
(2).









 









So how are (1) and (2) related?









 









- Some cases covered under (2) overlap with (1), but some =
cases in
(2) are for single connection sessions.  E.g. LU Reset on a single
connection session impacting several 3rd party =
sessions









 









- Some cases under (1) overlap with (2), but some cases in (1) =
have
nothing to do with other sessions.  E.g. establishment of ACA on a
non-shared task set









 









- Section 4.1 (i.e. text for (2)) uses response =
fence (i.e.
text for (1)) whenever multi-connection sessions are involved in =
multi-task
abort situations.









 









I hope that clarifies it.  Feel free to ask if that is not
clear.  The net is that the response fence is the underpinning =
notion
to describe the correct iSCSI behavior in a few cases and some of those =
cases
are about task terminations across third-party =
sessions.









 









Mallikarjun









 













 









----- Original =
Message
----

From: John Hufferd =
<jhufferd@Brocade.COM>

To: Mallikarjun C. <cb_mallikarjun@yahoo.com>; ips@ietf.org

Sent: Friday, January 5, 2007 1:01:06 PM

Subject: RE: [Ips] Response Fence Flag






Mallikarjun,



I must admit, that I have been a =
bit
confused with the direction of the conversation =
here.



 



Therefore, I went back and reviewed =
the
charts from Dallas
.  And as I remembered, the initial focus was to address the issue =
of
Multiple Connections per Session (MC/S) (as stated on chart 4 –
“Non-issue for single-connection iSCSI sessions”).  So =
I think
I have missed the step where we have morphed the discussion into one =
dealing
with multiple sessions.  (I am not sure how that happened, or if I
miss-read the charts from Dallas
, or have not followed the discussion =
adequately.)



 



If we are attempting to define two
different issues, one with MC/S and one with Multiple Session from =
different
Initiators, I think it would be useful to break down the conversation =
into
Topic A – MC/S and Topic B Multiple Sessions.  It is possible =
that
one solution will addresses both, but I for one think I am hearing =
arguments
that might be appropriate for Topic B, while I am thinking about its
applicability to Topic A.



 



Perhaps, you could address the =
issue as
either being all about MC/S or explicitly state that it is intended to =
affect
Multiple Sessions also, and then address the issues and solution for =
each
separately.  For example, I believe Robert was addressing the issue =
from a
view of Multiple Sessions and if we only intended to address MC/S then I =
expect
the response might be somewhat different.



 



Anyway, if you could clear-up some =
of
this, I think it would be useful (at least to =
me).



 






.



.



.



John L =
Hufferd



Sr. Executive Director of =
Technology



Brocade Communications Systems, =
Inc



jhufferd@brocade.com



Office Phone: (408) 333-5244; =
eFAX: (408)
904-4688



Alt Office Phone: (408) 997-6136; =
Cell:
(408) 627-9606






 















From: =
Mallikarjun C.
[mailto:cb_mallikarjun@yahoo.com] 

Sent: Friday, January 05, =
2007
10:08 AM

To: ips@ietf.org

Subject: Re: [Ips] =
Response Fence
Flag






 









Not really.  Current draft text is intentionally written to =
not
have any dependencies on T10 dynamics.  The point is that iSCSI =
needs such
a notion for succinctly describing the proper iSCSI protocol =
actions
in a few places - ACA, TMF, Persistent reserve/Abort to name a =
few.  We
certainly hope it will be approved by T10 and be a part of SAM-4 soon,
but that isn't required per se for describing what iSCSI needs for =
its
correct behavior.









 









IPS WG has adopted what it needs in the past - staying =
ahead
of T10 review/approval cycle if necessary.  I_T nexus loss =
notification,
iSCSI target/port naming, clearing effects are a few I =
recall.









 









Mallikarjun













 









----- Original =
Message
----

From: Eddy Quicksall <Quicksall_iSCSI@Bellsouth.net>

To: Robert Snively
<rsnively@Brocade.COM>; "Elliott, Robert (Server =
Storage)"
<Elliott@hp.com>; ips@ietf.org

Sent: Friday, January 5, 2007 8:58:47 AM

Subject: Re: [Ips] Response Fence Flag






From an earlier email I think that Response Fence is =
only a
proposal in T10 (http://www.t10.org:80/doc06.htm).
If so shouldn't iSCSI wait a bit until this has been =
ratified?









 









Eddy
































__________________________________________________

Do You Yahoo!?

Tired of spam? Yahoo! Mail has the best spam protection around 

http://mail.yahoo.com
------_=_NextPart_001_01C73362.AC5EA3CE-- --===============0223734473== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============0223734473==-- From ips-bounces@ietf.org Mon Jan 08 20:21:10 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H45fd-0007PS-Da; Mon, 08 Jan 2007 20:20:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H45fc-0007P3-2d for ips@ietf.org; Mon, 08 Jan 2007 20:20:56 -0500 Received: from web51902.mail.yahoo.com ([206.190.48.65]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H45fX-0006xi-P7 for ips@ietf.org; Mon, 08 Jan 2007 20:20:56 -0500 Received: (qmail 27266 invoked by uid 60001); 9 Jan 2007 01:20:51 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type; b=kjGM+XG6BffleW3RbgeUusV9L9L2JIFMXD63ylN821fyZ0526KO5RsVMa3sT11EqwDuNHJlS8GfmvX35ZeqI7lLLuTQK2m8wR6JGxDd2Z7WLVqdcC7rDP5iAYfzMvk52gkptT0kahlEd05sfR/jJU2FebYd3zd/i5I4g54hBVWE= ; Message-ID: <20070109012051.27264.qmail@web51902.mail.yahoo.com> Received: from [15.227.217.77] by web51902.mail.yahoo.com via HTTP; Mon, 08 Jan 2007 17:20:51 PST Date: Mon, 8 Jan 2007 17:20:51 -0800 (PST) From: "Mallikarjun C." Subject: Re: [Ips] Response Fence Flag To: IPS MIME-Version: 1.0 X-Spam-Score: 0.1 (/) X-Scan-Signature: 87e958510a39f65fbeb5ae8b5e360e3b X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0043527088==" Errors-To: ips-bounces@ietf.org --===============0043527088== Content-Type: multipart/alternative; boundary="0-228294719-1168305651=:20862" --0-228294719-1168305651=:20862 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable John,=0A=0AOn your topic A, section 3.3.3 lists the current list of respons= e fence cases where the fence is "assumed" to be present. So for the time = being, iSCSI "knows" when to fence. Further, note that reponse fence is li= mited to *one I_T_L nexus* only - so by definition, there cannot be any cro= ss-nexus ordering requirements out of a response fence, and not even cross = I_T_L nexus linkages.=0A=0AOn your topic B, I can now see where some of the= confusion is - wherever we say "third-party session" in the draft, we mean= a "third-party iSCSI session" unless otherwise qualified. I need to add a= sentence to that effect to the definition of "third-party" in section 1.1,= sorry about that ambiguity. All verbiage that is meant for non-iSCSI I_T = nexuses is clearly marked as such in the draft. =0A=0AHow broad is the not= ion of "third-party" - across portal groups? across transports? - is someth= ing I cannot directly answer. It is really a question of target design - I= 'd say whenever actions on an iSCSI session "affect" tasks (per definition = of 4.1.1) on a different session, it is a third-party session for that acti= on. E.g., if one iSCSI target portal group (which is really a different I_= T nexus from the issuing nexus) truly has no clue about a Clear Task Set on= the issuing iSCSI target portal group, then it must not have had a shared = task set at the LU level, shared jointly between the two portal groups. In= such a case, the first session is *not* a third-party session for the purp= ose of Clear Task Set on the second session. If OTOH, they *do* share a ta= sk set at the SCSI LU level, then the first session becomes a third party s= ession wrt the Clear Task Set on the second session per the intent of the d= raft. Note that there is absolutely nothing new in this draft about the functional requireements on third-party sessions. Cross-nexus clearin= g effects, UAs etc. are really SCSI territory. The draft does not require = any cross-portal group knowledge beyond what is required for 3720-compliant= implementations (in fact, this draft frees up the TTT linkage we had befor= e) - the 4.1.3 text you quote can be implemented either with a shared SCSI = LU task set (in which case the notion of "affected" has to be propagated vi= a the SCSI layer), or with a completely offloaded SCSI+iSCSI portal group (= in which case all third-party sessions are local to the hardware). Again, = I see no new issues here.=0A=0AThe Nop-Out Messages are "a lazy signal" for= a target to optimally cleanup any residual task state after the task was t= erminated, therefore Async Messages and Nop-Out Messages again absoluly hav= e no cross-nexus linkages (and Async+Nop-Out exchange, BTW, is not related = to response fence as you may have already sensed, it is related to multi-ta= sk abort handling).=0A=0AHope that clarifies some. As always, feel free to= ask if not, or give me a call.=0A=0AThanks.=0A=0AMallikarjun=0A=0A=0A-----= Original Message ----=0AFrom: John Hufferd =0ATo: Ma= llikarjun C. ; IPS =0ASent: Monday,= January 8, 2007 12:21:32 PM=0ASubject: RE: [Ips] Response Fence Flag=0A=0A= =0AMallikarjun,=0AOK, so I would like us to first cover Topic A (your case = 1).=0AAs I understand it you are trying to make TMC and ACA operate correct= ly on a MC/S Session. =0A =0AAnd, if I understand your Slide 5, et.al. cor= rectly then the iSCSI code can ASSUME a Fence has been issued for all TM an= d ACA operations and react as you have specified. In that specific case th= ere is no need for Fence parameter in the Target SCSI to iSCSI interaction = (at least at this time).=0A =0ASo if that is the case, then for all current= operations we are covered without additional Target SCSI parameters. Is t= hat correct?=0A =0ANow when you use the words Third Party Session, I believ= e that could mean Session that are iSCSI or Non iSCSI (e.g. Fibre Channel),= I also think it could include iSCSI Sessions on other portal groups connec= ted to the same Target. =0A =0AThe thing that is concerning me is that some= of the words which are included in the document do not factor in the fact = that any specific iSCSI Target portal group may not have a clue about what = is happening at another iSCSI Target portal group, or at a Fibre Channel po= rtal that may also be attached to the same Target/LUN.=0A =0AThe way I read= your document, I thought that it implied that the iSCSI Transport would kn= ow about things that are happening on other Portal Groups that may be iSCSI= or some other Transport technology.=0A =0AFor instance in section 4.1.3.a = (under the Target iSCSI Layer) you state =93=85SHOULD NOT wait for new comm= ands on third-party affected sessions - only the instantiated tasks have to= be considered for the purpose of determining the affected tasks.=93 Other= than the fact that it does not matter what the other Session do, since you= ignore it, the thought pattern is that you will know that you are ignoring= it.=0A =0AAlso in section 4.1.3 d (under the Target iSCSI layer) you stat= e =93=85MUST generate an Asynchronous Message PDU with AsyncEvent=3D5 (sect= ion 8.1) on: =0A i) each connection of each third-party session th= at at =0A least one affected task is allegiant to, and =0A = ii) each connection except the non-issuing connection of the =0A = issuing session that has at least one allegiant affected =0A = task. =93=0A =0AI think that implies that one iSCSI portal group has kno= wledge of what is happening in other portal groups, and that extends to oth= er Technology attachments such as Fibre Channel.=0A =0AIf you are stating = that it is up to the target SCSI layer to issue the =93Fence parameter=94 a= ppropriately such that the effect is what you stated in 4.1.3 (under the Ta= rget iSCSI Layer) then I might feel that I am coming closer to understandin= g your point.=0A =0AOtherwise, I just do not see how that is practical sin= ce even the iSCSI target portal groups may be implemented in separate iSCSI= Offload Adapters. And I really do not know how they will know what is hap= pening on the Fibre Channel connections. =0A =0AWhen I combine the above th= ought with the statements that were made by=0A Robert Snively , which in ef= fect states that all the actions and responses arrivals are not predictable= (at least across different Sessions), that seems to me to mean that the ap= pearance of UAs, caused by another Session, may occur at any time with rela= tion to what is going on at any other Session. Therefore, I can not yet gr= asp the need for ordering Asynchronous Messages among the MC/S connections.= I am trying to see what the initiator surprise will be, and why that will= cause a problem, if the Asynchronous Messages occur in some undefined orde= r. However, at this time I am left with an unease that not only are some o= f the above document statements not implementable, I am wondering it they a= re even important.=0A =0AHopefully, you can understand my dilemma on unders= tanding what you are proposing, and can explain what I am missing.=0A =0A.= =0A.=0A.=0AJohn L Hufferd=0ASr. Executive Director of Technology=0ABrocade = Communications Systems, Inc=0Ajhufferd@brocade.com=0AOffice Phone: (408) 33= 3-5244; eFAX: (408) 904-4688=0AAlt Office Phone: (408) 997-6136; Cell: (408= ) 627-9606=0A =0A=0A=0A=0AFrom: Mallikarjun C. [mailto:cb_mallikarjun@yahoo= .com] =0ASent: Friday, January 05, 2007 2:45 PM=0ATo: IPS=0ASubject: Fw: [I= ps] Response Fence Flag=0A =0ATrying again after bouncing (>50KB), tail is = now clipped....=0A----- Forwarded Message ----=0AFrom: Mallikarjun C. =0ATo: ips@ietf.org=0ASent: Friday, January 5, 2007 2:= 40:56 PM=0ASubject: Re: [Ips] Response Fence Flag=0AHi John,=0A =0AAs you c= orrectly point out, there are two distinct but related topics here.=0A =0A(= 1) proper response ordering across participating connections in a multi-con= nection session, for a handful of task/TMF responses=0A(2) proper way to te= rminate and signal tasks when actions on one session can impact multiple in= itiators=0A =0A(1) is all about response fence, it is covered separately in= section 3.3 of IG draft. That's what this email thread started off with.= =0A =0A(2) covers cases that IG had called as as "multi-task abort" cases t= hat typically have a shared task set across sessions, or are the result of = a Logical Unit Reset TMF. Section 4.1 of IG adresses (2).=0A =0ASo how are= (1) and (2) related?=0A =0A- Some cases covered under (2) overlap with (1)= , but some cases in (2) are for single connection sessions. E.g. LU Reset = on a single connection session impacting several 3rd party sessions=0A =0A-= Some cases under (1) overlap with (2), but some cases in (1) have nothing = to do with other sessions. E.g. establishment of ACA on a non-shared task = set=0A =0A- Section 4.1 (i.e. text for (2)) uses response fence (i.e. text = for (1)) whenever multi-connection sessions are involved in multi-task abor= t situations.=0A =0AI hope that clarifies it. Feel free to ask if that is = not clear. The net is that the response fence is the underpinning notion t= o describe the correct iSCSI behavior in a few cases and some of those case= s are about task terminations across third-party sessions.=0A =0AMallikarju= n=0A =0A=0A=0A =0A----- Original Message ----=0AFrom: John Hufferd =0ATo: Mallikarjun C. ; ips@ietf.or= g=0ASent: Friday, January 5, 2007 1:01:06 PM=0ASubject: RE: [Ips] Response = Fence Flag=0AMallikarjun,=0AI must admit, that I have been a bit confused w= ith the direction of the conversation here.=0A =0ATherefore, I went back an= d reviewed the charts from Dallas . And as I remembered, the initial focus= was to address the issue of Multiple Connections per Session (MC/S) (as st= ated on chart 4 =96 =93Non-issue for single-connection iSCSI sessions=94). = So I think I have missed the step where we have morphed the discussion int= o one dealing with multiple sessions. (I am not sure how that happened, or= if I miss-read the charts from Dallas , or have not followed the discussio= n adequately.)=0A =0AIf we are attempting to define two different issues, o= ne with MC/S and one with Multiple Session from different Initiators, I thi= nk it would be useful to break down the conversation into Topic A =96 MC/S = and Topic B Multiple Sessions. It is possible that one solution will addre= sses both, but I for one think I am hearing arguments that might be appropr= iate for Topic B, while I am thinking about its applicability to Topic A.= =0A =0APerhaps, you could address the issue as either being all about MC/S = or explicitly state that it is intended to affect Multiple Sessions also, a= nd then address the issues and solution for each separately. For example, = I believe Robert was addressing the issue from a view of Multiple Sessions = and if we only intended to address MC/S then I expect the response might be= somewhat different.=0A =0AAnyway, if you could clear-up some of this, I th= ink it would be useful (at least to me).=0A =0A.=0A.=0A.=0AJohn L Hufferd= =0ASr. Executive Director of Technology=0ABrocade Communications Systems, I= nc=0Ajhufferd@brocade.com=0AOffice Phone: (408) 333-5244; eFAX: (408) 904-4= 688=0AAlt Office Phone: (408) 997-6136; Cell: (408) 627-9606=0A =0A=0A=0A= =0AFrom: Mallikarjun C. [mailto:cb_mallikarjun@yahoo.com] =0ASent: Friday, = January 05, 2007 10:08 AM=0ATo: ips@ietf.org=0ASubject: Re: [Ips] Response = Fence Flag=0A =0ANot really. Current draft text is intentionally written t= o not have any dependencies on T10 dynamics. The point is that iSCSI needs= such a notion for succinctly describing the proper iSCSI protocol actions = in a few places - ACA, TMF, Persistent reserve/Abort to name a few. We cer= tainly hope it will be approved by T10 and be a part of SAM-4 soon, but tha= t isn't required per se for describing what iSCSI needs for its correct beh= avior.=0A =0AIPS WG has adopted what it needs in the past - staying ahead o= f T10 review/approval cycle if necessary. I_T nexus loss notification, iSC= SI target/port naming, clearing effects are a few I recall.=0A =0AMallikarj= un=0A=0A=0A =0A----- Original Message ----=0AFrom: Eddy Quicksall =0ATo: Robert Snively ; "Elliot= t, Robert (Server Storage)" ; ips@ietf.org=0ASent: Friday, = January 5, 2007 8:58:47 AM=0ASubject: Re: [Ips] Response Fence Flag=0AFrom = an earlier email I think that Response Fence is only a proposal in T10 (htt= p://www.t10.org:80/doc06.htm). If so shouldn't iSCSI wait a bit until this = has been ratified?=0A =0AEddy=0A=0A________________________________________= __________=0ADo You Yahoo!?=0ATired of spam? Yahoo! Mail has the best spam = protection around =0Ahttp://mail.yahoo.com=0A=0A___________________________= _______________________=0ADo You Yahoo!?=0ATired of spam? Yahoo! Mail has = the best spam protection around =0Ahttp://mail.yahoo.com --0-228294719-1168305651=:20862 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
John,
=0A
=0A
 
= =0A
On your topic A, section 3.3.3 lists the current list of respo= nse fence cases where the fence is "assumed" to be present.  So for th= e time being, iSCSI "knows" when to fence.  Further, note that reponse= fence is limited to *one I_T_L nexus* only - so by definition, there canno= t be any cross-nexus ordering requirements out of a response fence, and not= even cross I_T_L nexus linkages.
=0A
 
=0AOn your topic B, I can now see where some of the confusion is - whe= rever we say "third-party session" in the draft, we mean a "third-party iSC= SI session" unless otherwise qualified.  I need to add a sentence to t= hat effect to the definition of "third-party" in section 1.1, sorry about t= hat ambiguity.  All verbiage that is meant for non-iSCSI I_T nexuses i= s clearly marked as such in the draft. 
=0A
 =0A
How broad is the notion of "third-party" - across portal grou= ps? across transports? - is something I cannot directly answer.  It is=  really a question of target design - I'd say whenever actions on an i= SCSI session "affect" tasks (per definition of 4.1.1) on a different sessio= n, it is a third-party session for that action.  E.g., if one iSCSI ta= rget portal group (which is really a different I_T nexus from the issuing n= exus) truly has no clue about a Clear Task Set on the issuing iSCSI target = portal group, then it must not have had a shared task set at the LU le= vel, shared jointly between the two portal groups.  In such a case, th= e first session is *not* a third-party session for the purpose of Clea= r Task Set on the second session.  If OTOH, they *do* share a task set= at the SCSI LU level, then the first session becomes a third party session= wrt the Clear Task Set on the second session per the intent of the draft.  Note that the= re is absolutely nothing new in this draft about the functional requireemen= ts on third-party sessions.  Cross-nexus clearing effects, UAs et= c. are really SCSI territory.  The draft does not require any cross-po= rtal group knowledge beyond what is required for 3720-compliant implementat= ions (in fact, this draft frees up the TTT linkage we had before) - the 4.1= .3 text you quote can be implemented either with a shared SCSI LU task set = (in which case the notion of "affected" has to be propagated via the SCSI l= ayer), or with a completely offloaded SCSI+iSCSI portal group (in which cas= e all third-party sessions are local to the hardware).  Again, I&= nbsp;see no new issues here.
=0A
 
=0A
The= Nop-Out Messages are "a lazy signal" for a target to optimally cleanup any= residual task state after the task was terminated, therefore Async Message= s and Nop-Out Messages again absoluly have no cross-nexus linkages (and Asy= nc+Nop-Out exchange, BTW, is not related to response fence as you may = have already sensed, it is related to multi-task abort handling).
=0A<= DIV style=3D"FONT-SIZE: 12pt; FONT-FAMILY: times new roman, new york, times= , serif"> 
=0A
Hope that clarifies some.  As always= , feel free to ask if not, or give me a call.
=0A
 =0A
Thanks.
=0A
 
=0A
Mallikarju= n

=0A
----- Original Message ----
From: John Huffe= rd <jhufferd@Brocade.COM>
To: Mallikarjun C. <cb_mallikarjun@ya= hoo.com>; IPS <ips@ietf.org>
Sent: Monday, January 8, 2007 12:2= 1:32 PM
Subject: RE: [Ips] Response Fence Flag

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

Mallikarjun,<= /FONT>

=0A

= OK, so I w= ould like us to first cover Topic A (your case 1).

=0A

As I understand it you are = trying to make TMC and ACA operate correctly on a MC/S Session.  

=0A

 = ;

=0A

A= nd, if I understand your Slide 5, et.al. correctly then the iSCSI code can = ASSUME a Fence has been issued for all TM and ACA operations and react as y= ou have specified.  In that specific case there is no need for Fence p= arameter in the Target SCSI to iSCSI interaction (at least at this time).

=0A

&nbs= p;

=0A

= So if that is the case, then for all current operations we are covered with= out additional Target SCSI parameters.  Is that correct?=

=0A

 

=0A

Now when you= use the words Third Party Session, I believe that could mean Session that = are iSCSI or Non iSCSI (e.g. Fibre Channel), I also think it could include = iSCSI Sessions on other portal groups connected to the same Target. =

=0A

 

=0A

The t= hing that is concerning me is that some of the words which are included in = the document do not factor in the fact that any specific iSCSI Target porta= l group may not have a clue about what is happening at another iSCSI Target= portal group, or at a Fibre Channel portal that may also be attached to th= e same Target/LUN.

=0A

 

=0A

The way I read your document, I thought that it implie= d that the iSCSI Transport would know about things that are happening on ot= her Portal Groups that may be iSCSI or some other Transport technology.

=0A

 = ;

For instance in sect=
ion 4.1.3.a (under the Target iSCSI Layer) you state =93=85SH=
OULD NOT wait for new commands on third-party affected sessions - only the =
instantiated tasks have to be considered for the purpose of determining the=
 affected tasks.=93  Other than the fact that it does not matter =
what the other Session do, since you ignore it, the thought pattern is that=
 you will know that you are ignoring it.
  
Also in section 4.1.3 d (under the Target iSCSI layer)=
 you state =93=85MUST generate an Asynchronous Message PDU wi=
th AsyncEvent=3D5 (section 8.1) on: 
      =
;    i) each connection of each third-party session tha=
t at 
        &nbs=
p;   least one affected task is allegiant to, and 
          ii) eac=
h connection except the non-issuing connection of the
<= PRE>&nb= sp;           issuin= g session that has at least one allegiant affected 
      &=
nbsp;     task. =93
  
I think that implies that one iSCSI portal = group has knowledge of what is happening in other portal groups, and that e= xtends to other Technology attachments such as Fibre Channel.= 
  
<=
FONT face=3DArial color=3Dnavy size=3D2>If you are stating that it
 is up to the target SCSI layer to issue the =93Fence parameter=94 appropri=
ately such that the effect is what you stated in 4.1.3 (under the Target iS=
CSI Layer) then I might feel that I am coming closer to understanding your =
point.
  
Otherwise, I just do not =
see how that is practical since even the iSCSI target portal groups may be =
implemented in separate iSCSI Offload Adapters.  And I really do not k=
now how they will know what is happening on the Fibre Channel connections. =
=0A

=  

When I combine =
the above thought with the statements that were made by=0A Robert Snively ,=
 which in effect states that all the actions and responses arrivals are not=
 predictable (at least across different Sessions), that seems to me to mean=
 that the appearance of UAs, caused by another Session, may occur at any ti=
me with relation to what is going on at any other Session.  Therefore,=
 I can not yet grasp the need for ordering Asynchronous Messages among the =
MC/S connections.  I am trying to see what the initiator surprise will=
 be, and why that will cause a problem, if the Asynchronous Messages occur =
in some undefined order.  However, at this time I am left with an unea=
se that not only are some of the above document statements not implementabl=
e, I am wondering it they are even important.
=0A

 

=0A

Hopefully, you can underst= and my dilemma on understanding what you are proposing, and can explain wha= t I am missing.

=0A

 

=0A
=0A

.

=0A

.

= =0A

.

=0A

John L Hufferd

=0A

Sr. Executive Director of Technology

=0A

Brocade Communications Systems, Inc

=0A

jhuf= ferd@brocade.com

=0A

Offi= ce Phone: (408) 333-5244; eFAX: (408) 904-4688

=0A

<= FONT face=3D"Times New Roman" color=3Dnavy size=3D2>Alt Office Phone: (408) 997-6136; Cell: (408) 627-960= 6

=0A

 

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

Mallikarjun C. [mailto:cb_mallikarjun@yaho= o.com]
Sent: Friday, Ja= nuary 05, 2007 2:45 PM
To: IPS
Subject: Fw: [Ips= ] Response Fence Flag

=0A

 

=0A
=0A
=0A

Trying again after bouncing (>50KB), tail is now clipped....

=0A
=0A

= ---= -- Forwarded Message ----
From: Mallikarjun C. <cb_mallikarjun@yahoo.= com>
To: ips@ietf.org
Sent: Friday, January 5, 2007 2:40:56 PM
= Subject: Re: [Ips] Response Fence Flag

=0A
=0A
=0A=

Hi John,

=0A
=0A

 

=0A
=0A

As you corre= ctly point out, there are two distinct but related topics here.=

=0A
=0A

 

=0A
=0A

(1) proper response ordering across participa= ting connections in a multi-connection session, for a handful of task/TMF r= esponses

=0A
=0A

(2) proper wa= y to terminate and signal tasks when actions on one session can impact= multiple initiators

=0A
=0A

&n= bsp;

=0A
=0A

(1) is all about r= esponse fence, it is covered separately in section 3.3 of IG draft.  T= hat's what this email thread started off with.

=0A=0A

 

=0A
=0A

(2) covers cases that IG had called as as "multi-task a= bort" cases that typically have a shared task set across sessions, or are t= he result of a Logical Unit Reset TMF.  Section 4.1 of IG adresses (2)= .

=0A
=0A

 <= /P>

=0A
=0A

So how are (1) and (2) related?

=0A
=0A

 

=0A
=0A

<= SPAN style=3D"FONT-SIZE: 12pt">- Some cases covered under (2) overlap with&= nbsp;(1), but some cases in (2) are for single connection sessions.  E= .g. LU Reset on a single connection session impacting several 3rd party ses= sions

=0A
=0A

 

=0A
=0A

- Some cases under (1) overlap wi= th (2), but some cases in (1) have nothing to do with other sessions. = E.g. establishment of ACA on a non-shared task set

= =0A
=0A

 

=0A
=0A

- Section 4.1 (i.e. text for (2)) uses response fence&nbs= p;(i.e. text for (1)) whenever multi-connection sessions are involved in mu= lti-task abort situations.

=0A
=0A

 

=0A
=0A

I hope that = clarifies it.  Feel free to ask if that is not clear.  The net&nb= sp;is that the response fence is the underpinning notion to describe the co= rrect iSCSI behavior in a few cases and some of those cases are about task = terminations across third-party sessions.

=0A=0A

 

=0A
=0A

Mallikarjun

=0A
=0A

&= nbsp;

=0A
=0A



 

=0A
=0A

----- Original Message ----
From: John Hufferd <jhufferd@Brocade= .COM>
To: Mallikarjun C. <cb_mallikarjun@yahoo.com>; ips@ietf.o= rg
Sent: Friday, January 5, 2007 1:01:06 PM
Subject: RE: [Ips] Respon= se Fence Flag

=0A
=0A

Mallikarjun,

=0A

= I must admit, that I have been a bit confuse= d with the direction of the conversation here.

=0A

 

=0A

Therefore, I went back and = reviewed the charts from Dallas .  And as I remembered, the initial fo= cus was to address the issue of Multiple Connections per Session (MC/S) (as= stated on chart 4 =96 =93Non-issue for single-connection iSCSI sessions=94= ).  So I think I have missed the step where we have morphed the discus= sion into one dealing with multiple sessions.  (I am not sure how that= happened, or if I miss-read the charts from Dallas , or have not followed = the discussion adequately.)

=0A

 

=0A

If we are attempting to define two different i= ssues, one with MC/S and one with Multiple Session from different Initiator= s, I think it would be useful to break down the conversation into Topic A = =96 MC/S and Topic B Multiple Sessions.  It is possible that one solut= ion will addresses both, but I for one think I am hearing arguments that mi= ght be appropriate for Topic B, while I am thinking about its applicability= to Topic A.

=0A

 

=0A

Perhaps, you could address the issue as either being all abou= t MC/S or explicitly state that it is intended to affect Multiple Sessions = also, and then address the issues and solution for each separately.  F= or example, I believe Robert was addressing the issue from a view of Multip= le Sessions and if we only intended to address MC/S then I expect the respo= nse might be somewhat different.

=0A

<= FONT face=3DArial color=3Dnavy size=3D2> 

=0A

Anyway, if you could clear-up some of thi= s, I think it would be useful (at least to me).

=0A

 

=0A=0A

.

=0A

.

=0A

.

=0A

John L Hufferd

=0A

Sr. Executive Director of Technology

=0A

Brocade Communicatio= ns Systems, Inc

=0A

jhufferd@brocade.com=

=0A

Office Phone: (408) 333-= 5244; eFAX: (408) 904-4688

=0A

Alt Office Phone: (408) 997-6136; Cell: (408) 627-9606

=0A

&= nbsp;

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

From: Mallikarjun C. [mailto:cb_mallikarj= un@yahoo.com]
Sent: Fri= day, January 05, 2007 10:08 AM
To:<= /SPAN> ips@ietf.org
Subject: Re: [Ips] Response Fence Flag

=0A

 

=0A
=0A
=0A

<= FONT face=3D"Times New Roman" size=3D3>Not = really.  Current draft text is intentionally written to not have any d= ependencies on T10 dynamics.  The point is that iSCSI needs such a not= ion for succinctly describing the proper iSCSI protocol actions i= n a few places - ACA, TMF, Persistent reserve/Abort to name a few.  We= certainly hope it will be approved by T10 and be a part of SAM-4 soon, but=  that isn't required per se for describing what iSCSI needs for its co= rrect behavior.

=0A
=0A

 <= /SPAN>

=0A
=0A

IPS WG has adopted what= it needs in the past - staying ahead of T10 review/approval cycl= e if necessary.  I_T nexus loss notification, iSCSI target/port naming= , clearing effects are a few I recall.

=0A
=0A 

=0A
=0A

= Mallikarjun

=0A
=0A



&nb= sp;

=0A
=0A

----- Original Message ----
From: Eddy Quicksall <Quicksal= l_iSCSI@Bellsouth.net>
To: Robert Snively <rsnively@Brocade.COM>= ;; "Elliott, Robert (Server Storage)" <Elliott@hp.com>; ips@ietf.org<= BR>Sent: Friday, January 5, 2007 8:58:47 AM
Subject: Re: [Ips] Response = Fence Flag

=0A
=0A

From an earlier em= ail I think that Response Fence is only a proposal in T10 (http://ww= w.t10.org:80/doc06.htm). If so shouldn't iSCSI wait a bit until this ha= s been ratified?

=0A
=0A

 =

=0A
=0A

Eddy

=
=0A

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

=0A

<= br>__________________________________________________
Do You Yahoo!?
= Tired of spam? Yahoo! Mail has the best spam protection around
http://= mail.yahoo.com --0-228294719-1168305651=:20862-- --===============0043527088== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============0043527088==-- From ips-bounces@ietf.org Mon Jan 08 20:31:04 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H45pP-0003Zo-T1; Mon, 08 Jan 2007 20:31:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H45pP-0003Ze-3K for ips@ietf.org; Mon, 08 Jan 2007 20:31:03 -0500 Received: from ug-out-1314.google.com ([66.249.92.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H45pN-000210-QT for ips@ietf.org; Mon, 08 Jan 2007 20:31:03 -0500 Received: by ug-out-1314.google.com with SMTP id 72so6035406ugd for ; Mon, 08 Jan 2007 17:31:01 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:mime-version:content-type; b=QN9z8kcCxqiLt74ccS862QpEwSb2lF1ee5FBu2zJtA/Hmix2Dj90E2eE2BhLZslBQnAD+9IuIDjl+ElQkYTA91g9DFyflW+u6kTczlXyTqyCEx5p1qrhJVTlqXsH8lDlbosy5lEPPs5W/4ir+bsVj35NP/SCd0YIv20bGoLzt5k= Received: by 10.78.185.7 with SMTP id i7mr4337938huf.1168306260851; Mon, 08 Jan 2007 17:31:00 -0800 (PST) Received: by 10.78.201.12 with HTTP; Mon, 8 Jan 2007 17:31:00 -0800 (PST) Message-ID: Date: Mon, 8 Jan 2007 17:31:00 -0800 From: "Vishal Study" To: ips@ietf.org MIME-Version: 1.0 X-Spam-Score: 0.5 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: Subject: [Ips] iSCSI protocol implementation X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2115846188==" Errors-To: ips-bounces@ietf.org --===============2115846188== Content-Type: multipart/alternative; boundary="----=_Part_79864_8007010.1168306260757" ------=_Part_79864_8007010.1168306260757 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hello: I am a newcomer to iSCSI world and some questions on its protocol implementation. I apologize if this is not the right forum to address this question. Please point me to the appropriate list. Q1: What is most popular/stable iSCSI target protocol stack? Q2: If someone could please provide pointers to other stacks and maybe share their experiences with different iSCSI implementations (IET, intel-iscsi, chelsio etc, I will really appreciate that! Thanks, Vishal. ------=_Part_79864_8007010.1168306260757 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Hello:
 
I am a newcomer to iSCSI world and some questions on its protocol implementation.
 
I apologize if this is not the right forum to address this question. Please point me to the appropriate list.
 
Q1: What is most popular/stable iSCSI target protocol stack?
 
Q2: If someone could please provide pointers to other stacks and maybe share their experiences with different iSCSI implementations
(IET, intel-iscsi, chelsio etc, I will really appreciate that!
 
Thanks,
Vishal.
 
------=_Part_79864_8007010.1168306260757-- --===============2115846188== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============2115846188==-- From ips-bounces@ietf.org Mon Jan 08 22:35:23 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H47lK-000457-EN; Mon, 08 Jan 2007 22:34:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H47lJ-00044C-7c for ips@ietf.org; Mon, 08 Jan 2007 22:34:57 -0500 Received: from ug-out-1314.google.com ([66.249.92.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H47lG-00058F-Qm for ips@ietf.org; Mon, 08 Jan 2007 22:34:57 -0500 Received: by ug-out-1314.google.com with SMTP id 72so6059153ugd for ; Mon, 08 Jan 2007 19:34:54 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:mime-version:content-type; b=bUzUC7wwcCGFEYiQKAfW+NXD7tJRM8xSSZ/7jc5ixIGqDXGjYdWS4XoCNK0JFzF9c7itOSLRH4+vpaUq8/cbFSK9MajCsyUBbuDFU051HVjnbqUOsqgkkpa4VZYvBkoupCF8kZEaMnEEYvhEuX2iWBlHvISE7pH2w/Zmkm74e1w= Received: by 10.78.118.19 with SMTP id q19mr4361711huc.1168313693865; Mon, 08 Jan 2007 19:34:53 -0800 (PST) Received: by 10.78.201.12 with HTTP; Mon, 8 Jan 2007 19:34:53 -0800 (PST) Message-ID: Date: Mon, 8 Jan 2007 19:34:53 -0800 From: "Vishal Study" To: ips MIME-Version: 1.0 X-Spam-Score: 0.1 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: Subject: [Ips] T10 data protection and iSCSI X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0711203206==" Errors-To: ips-bounces@ietf.org --===============0711203206== Content-Type: multipart/alternative; boundary="----=_Part_81192_126536.1168313693758" ------=_Part_81192_126536.1168313693758 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi: What is relation between T10 data protection mechanism and iSCSI protocol? I couldn't find any reference to T10 data protection inside RFC 3720. Pardon my ignorance if this is stupid question...I am quite new to the storage area. Thanks, Vishal. ------=_Part_81192_126536.1168313693758 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Hi:
 
What is relation between T10 data protection mechanism and iSCSI protocol?

I couldn't find any reference to T10 data protection inside RFC 3720.

Pardon my ignorance if this is stupid question...I am quite new to the storage area.
 
Thanks,
Vishal.
------=_Part_81192_126536.1168313693758-- --===============0711203206== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============0711203206==-- From ips-bounces@ietf.org Tue Jan 09 02:22:23 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4BIq-0007ZR-Tn; Tue, 09 Jan 2007 02:21:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4BIp-0007ZF-F3 for ips@ietf.org; Tue, 09 Jan 2007 02:21:47 -0500 Received: from smtp108.plus.mail.mud.yahoo.com ([68.142.206.241]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H4BIo-0004cf-3Q for ips@ietf.org; Tue, 09 Jan 2007 02:21:47 -0500 Received: (qmail 78053 invoked from network); 9 Jan 2007 07:21:45 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Received:X-YMail-OSG:From:To:Subject:Date:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:In-Reply-To:Importance:X-MimeOLE; b=0BtU3G5TmTrjvqNiesNL56SHFyc7yb48FdFO5+DiBmfR+ozKI7c0Y2eEg3AEdyt9n2335OYEBAiUTPLTDEuUaBed/Eqyz+EfwwvP6oGZqRBCuIGa2Bfr5CVcVBaOGq5lPCWaDdDZ00VPRZOQmPL8oMu0/dHaEFzDW8cWM34RS5w= ; Received: from unknown (HELO abhi) (ram_sunee@71.136.21.107 with login) by smtp108.plus.mail.mud.yahoo.com with SMTP; 9 Jan 2007 07:21:45 -0000 X-YMail-OSG: Ltboq9cVM1lGO5YCEGWU24BKDu1AEXFOxlva5OsN2v1rG.Z4evEyx3aHGH3o_WUbcQkcX41wNDwqwq1PfpjFpXtu0DvXCe6V4sf_qhCHaXgV25ywcVXqRLTGREFwl2c04cEYG8oDyEa7dA64zYIMOdUiYQpDO8CMki6yamSweeH0tdqBdd2ss0u.FGeK From: "RAM SUNEE" To: "Eddy Quicksall" , Subject: RE: [Ips] Device Identification VPD Page for iSCSI Targets Date: Mon, 8 Jan 2007 23:21:46 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 1 (Highest) X-MSMail-Priority: High X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <000f01c7333e$d1c2c520$01faa8c0@ivivity.com> Importance: High X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.4 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ips-bounces@ietf.org What about ASSOCIATION field. Is it supposed to be Logical Unit,Target port or Target Device ?? -----Original Message----- From: Eddy Quicksall [mailto:Quicksall_iSCSI@Bellsouth.net] Sent: Monday, January 08, 2007 8:05 AM To: RAM SUNEE; ips@ietf.org Subject: Re: [Ips] Device Identification VPD Page for iSCSI Targets Referring to Table 296 of spc4r07a it seems the value should be 5 meaning iSCSI. Eddy ----- Original Message ----- From: "RAM SUNEE" To: Sent: Monday, January 08, 2007 10:20 AM Subject: [Ips] Device Identification VPD Page for iSCSI Targets > All, > > Can anyone please clarify me regarding, Device Identification VPD usage > for > iSCSI Target. > What values should an iSCSI Target use for PROTOCOL_IDENTIFIER, > ASSOCIATION > fields of Device Identification VPD response page. > I have noticed that iSCSI Targets are reportng to Initiators as "SCSI Disk > Device",is it correct behavior? > Isn't it supposed to be that iSCSI Target needs to report to Initiator as > "iSCSI Disk Device" > > -RAM > > > > _______________________________________________ > Ips mailing list > Ips@ietf.org > https://www1.ietf.org/mailman/listinfo/ips > _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From had@prideland.com Tue Jan 09 04:03:09 2007 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4Csv-00010v-K6 for ips-archive@lists.ietf.org; Tue, 09 Jan 2007 04:03:09 -0500 Received: from cable-89-216-190-244.dynamic.sbb.co.yu ([89.216.190.244]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H4Cst-0004B4-NJ for ips-archive@lists.ietf.org; Tue, 09 Jan 2007 04:03:09 -0500 Received: from [120.121.89.187] (port=24952 helo=[120.121.89.187]) by cable-89-216-190-244.dynamic.sbb.co.yu with esmtp id 1jTqaR-000BER-88 for ips-archive@lists.ietf.org; Tue, 9 Jan 2007 10:03:15 +0100 Message-ID: <000e01c733cc$f1685500$f4bed859@chief> From: "Gaither High" To: ips-archive@lists.ietf.org Subject: Internet Date: Tue, 9 Jan 2007 10:02:51 +0100 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_000A_01C733D5.532CBD00" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 4.4 (++++) X-Scan-Signature: 8eeb555810cda1f2c5989480370dc4ca ------=_NextPart_000_000A_01C733D5.532CBD00 Content-Type: multipart/alternative; boundary="----=_NextPart_001_000B_01C733D5.532CBD00" ------=_NextPart_001_000B_01C733D5.532CBD00 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Lobstersin official website admitted fans. That they were no. This page toolssign create links linkcite articlein = last! Dozen pryorpunkd ariel, alderman order svu jamie naminmy girl. Tampa florida is an, television. Girl, my, boo nu ground music love phrase. Niptuck tampaviews article = discussion this page toolssign create, links. Unsourced statements births actors voice. Unexcused absences, heart doll? Year, tardiness talking class senior = passing. For burdines graduate, gaither high, school. Sick second tree, hills pushed waiter butt, tank full. No longer = together after friends actresses! Broadway musical alongside zac efron, travolta edit lifesnow been. Boo nu, ground music. Been dating actor kyle searles since, but. Far too easilyin receiving = detentions while did. And film actress began modeling, at age of. Efron, = travolta edit lifesnow been dating actor, kyle searles. Sophia bush arielle kebbel ashanti bethany joy galeotti. Sick second = tree hills, pushed waiter butt? Blusher far too easilyin receiving = detentions while. Tree, hills pushed, waiter butt tank full lobstersin = official. Longer together after friends actresses sophia, bush. Rolesmeg pryor in american lemay guiding born, march. My boo, nu ground = music love phrase pays academy. Longer together after friends actresses = sophia bush. Tank full lobstersin, official. By ashton, kutcher crashed. = Ad, for burdines graduate gaither high school, career. ------=_NextPart_001_000B_01C733D5.532CBD00 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
3D"voiced"
Lobstersin official = website=20 admitted fans.
That they were no. This page toolssign create links = linkcite=20 articlein last! Dozen pryorpunkd ariel, alderman order svu jamie naminmy = girl.
Tampa florida is an, television.
Girl, my, boo nu ground = music love=20 phrase. Niptuck tampaviews article discussion this page toolssign = create,=20 links.
Unsourced statements births actors voice.
Unexcused = absences, heart=20 doll? Year, tardiness talking class senior passing. For burdines = graduate,=20 gaither high, school.
Sick second tree, hills pushed waiter butt, = tank full.=20 No longer together after friends actresses!
Broadway musical = alongside zac=20 efron, travolta edit lifesnow been.
Boo nu, ground music.
Been = dating=20 actor kyle searles since, but. Far too easilyin receiving detentions = while did.=20 And film actress began modeling, at age of. Efron, travolta edit = lifesnow been=20 dating actor, kyle searles.
Sophia bush arielle kebbel ashanti = bethany joy=20 galeotti. Sick second tree hills, pushed waiter butt? Blusher far too = easilyin=20 receiving detentions while. Tree, hills pushed, waiter butt tank full = lobstersin=20 official.
Longer together after friends actresses sophia, = bush.
Rolesmeg=20 pryor in american lemay guiding born, march. My boo, nu ground music = love phrase=20 pays academy. Longer together after friends actresses sophia bush. Tank = full=20 lobstersin, official. By ashton, kutcher crashed. Ad, for burdines = graduate=20 gaither high school, career.
------=_NextPart_001_000B_01C733D5.532CBD00-- ------=_NextPart_000_000A_01C733D5.532CBD00 Content-Type: image/gif; name="License Copyrights.gif" Content-Transfer-Encoding: base64 Content-ID: <000901c733cc$f1685500$f4bed859@chief> R0lGODlhGALQAYfoAAAABnEAAAF2CnSMAAAAcXkKiAB0i7K5xLPQwqzV+kkSAGAfB3UdCqgaALsg AOInAAA4BxI4DUVAAFFEAHVBAKxHCMI0AOFLDABfABphADRYCF5kBndeAKdiBrNqANNRCgRzABOJ ADZ2AFh6AHt0CaR1AL5+BOSLAQigABylBUqfB2SjCHKiAK6YAMKZANenDADKCCHHAEexAGG3B4LO AKi1C727DtG/AAjUABPaDTTtC1vdAHTSCZHYAMblANbuDgEAOxEAOj4IPlkASXoMPKsAObMKSdYA OAAsNxorSkYmPFMtM4AUPqcuM84YOtcZOQA6QBY4Rzc4O2tLQXoyOqxFS8VOPdJLMQBpQihfO0lu R1teNnViDJtrOb5nMdhjSQBzMxaDREt2PV5/OYl5N5WIPsaDRt+OSQClNCuXPUiRTVKkNnieO6Ke Q7yaN96SOQDLMxnANkvDQVvEPnLOOJ22P7HFSOrMPQblQyzgSDLXRFXaNoHaOKPpObnkQOjjOgAA hBsAeTEEhWgKiH0Be5MAjboAdeEFfwQVhxUfdUsXiVcXjYQVi5Yrhb0UfeIWfQc2iyAxgD9HjVs7 d4ZJeJI6iLk8juY+hABqcyhTdDduhWxqeHtlh6ZojMxmjNFWcgB8fSJ3eT2CdV51dYeJeK1yfrSC g+J7gQClhhSkfjyoeWSagomTepiSfL2XhOudiQS6givIhUu4jFTDfHq3jJTGfsO9hNi7igzZeSDt izTaiFbUf3Tch6PtfczVeevueAAJzBoNzEMAs1wAtoULsaMAzsULu9EAuwAfwCIovzYmwm4twXwX yaAtxsItyNwutQBKtSRAy0pKtG1HvI1AuJ1Kv708ztVCswBuuRNTuzdmy1Jgu3VYxp9pssBtyO1Z wQCNzRl0xjZ+tmNxvnd3tZ6HtMeGs9x0ugCpuRWXtEOjyFebxYWpxqyTxMefyumhxgTIyB/CvDi8 xW7Lvo7Lyp+0vfry+Z2RqImNi/cAAAD6Dv//AAAA+/kN/w3////5/iH5BADG3sUALAAAAAAYAtAB Bwj/AP8JHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIBHaG0mypMmTKFOqXMmypcuX MGPKnDkzpM2bOHPq3Mmzp0OaQIMKHUq0qNGjSJOq9Mm0qdOnTJVKnUq1qtWrWLNq3cq1q9eiUMOK HSvyq9mzaNOqXVuSrNu3cOPKnUu3rt27ePPq9cm2r9+/MPcKHky4sEHAiBMrXsy4sePHLA1Lnky5 suXLmDPXhcy5s+fPoEOLHk06rebTqFOrXn23tOvXsIeynq0ztu3buJfS3o0zt+/frnkLH068OGrg yB0bX85cYvLn0KE3nx29unXA07Nr3178uvfvMQGI/wcwcjxJ8dUJEDAJDNhnfvDjwy8/3rw99fjX l6yPHqZ68AAqp5F4EREoEH4DqScQEAw2yKBA/BkYIUHjDWTgQPAVJJ98EFZoYX0EIXggAQVduCAQ EuVHIkEOopiggi+uOOFDJv5T44gvfkghADTyuKOPNvroYZAEbbjjkf/EhyE/P16oIoxBgshdc+1F 9OCIMELZYYlAIklkh0DWeOOWXHp54ZAmSklmjzoKVKWbwAzUXpxyvgkljG/CWaaXIa74D5RjNqTm P3PWOVKDJDF4Hnn0Lbofo/bZ0999+lHa6En/kZRpgJxO+tKk9V3q6KMogcqopPZ5mh9Km46Kqkn9 hf/66qKeetpSq6TmKuuup/bXKq622irqpLj6h9+jsUKaqrKwMjsqr6KaVOysnFabK0ymvhrsqdG6 amqyyHLrqrfiJgvupdliK+64s/J6brvcbtssf/TJSmukLL0LLarnyjsrmVJK2CWfbU5J2VHC5tur sv7eu6y92pKXrrAUL9xso+hNbLG6KfmbsXnmRlpruSSXKvG6F7ek78nwRtztuy1/3K3D3+Jr7XcJ r6RxwzO7rKvIzl5Lbsoh08yuwh2XHLHM1ArNc9PPony0yfYWDS/MLUddb9ApI30zeDmrlC6/XfcM s9X82gw1tR4zzDXWXp/UNrpcj/t0wmOPrHK8zu7/u6/WgP9dtthSf93YRoEiFHCYYg485pmMfyhk l40blGbka3p4OZhDKgR5wZ9/KfBBmxMc4eRm8ico5aiDmXnoXwKMeZSgt77nmgbvhTC9Sm3Lu95s n630veHyTetUvDssNN1J9wzYt8OOrDbE0Cu/NdAQG6799qRlz/334Ie/WO7klx+S+OgjZ/76CqXv /vsusS///PTXb//9+O8G//5E5e+/avwL0P+yE8ACGvCACEygAhfIwAY6ECwDjKBhHkjBCoJHghjM oAZ5YsEObvCDHQxhSz5IwhKa0DkiTKEKV8jCFrpQgCeMoQxnSMP6vfCGNcxhb254Gx36ECM8DOJV /+RzKEUVsV6jWpU95kSS9hQvfHNyT9rCFhSHtKhBnBuO6rCUI9xhcENKit2XolgoipyuSayTXJvQ BKQ8sbGLf/ITRZ4kR4RkSCB3TBKTeAK7Ps6OKXkayJVohzsyCsQlyZuaUIyYKERFD4mPfKCtfqWf +cRERcvTVKU2VTO6rYx4WZtJIqe1kk2ZUo5bPJGDCBalzvkRjlqC0RkX4koD3amON8rjG08kSBfR 8o9x5BLrfPQkg2jpdXYMoy4HpsHKrZGZv1xTIOFoOcaNLo5Z8tOFoqgnMbJpTYO0ootW+Y9B3rJ2 BeulOmV3zdiVLnGKu1zrbjRNd2rOR+F0CDwHVf9GONEJdq28XT2zaE8THvOd0PSc7Y7pxdQRaXQE emVEiVnH1e2JodEMqOgcZzuA4qiL2cwmHBFaoHtCFJo3AtQ9G8oQeOanSQQ9Z4xwCSSMPpRHTqro cnpHsghdj4rM+2ndrmU1tO2sb2qTm9JOh8iTMQ1qn5wZ8JbGsqEB7iQJWZzAAnWjz02UpRklXUdN OtZnOlSjWwVmMzmKJHiKVU2Pm9wr0SrX2aUVd271Zjt7dFcvprV0fIJcX5H5zFRmFacV2uphq1nY eXYunostKIj+mkYxAvSag+IOT8sGt7h1dqp5W9nGgjdaoEJ1qHsz6lKrejTQPsx4kVwb0kKFtsH/ BW9r0TJt2HyKMZChdoqwjWT1ZJtAnnVWZxvL2VGjF7TXMrd4hWPXcZGrWqK9bV2uVW3IpvoppPbW ZPNqbmhTcru9YtaxYj2r5FbqOrBK0JnszGx641tL+dZlriU1nV33y1i/VlYied3TeXHHMUj+tLtA +1lQ8QZb7wlRK7z9TSKtkkjg8TbCUmFq3K5qWsRUzHkr/KGIR8y+B5v4xNIhsYpXrB0Uu/jFPWSx jGc8HBgnh8YqtrGOd/wZHPv4x0AOspBxzOMiG3l8Q9bdkVGcZB8u+clPbrKUp0zlKltZg1Dm1JW3 zOUue/nLYA6zmGmT5TKbOStjTrOaF3LmNrs5/ylrjrOcD/nmOtuZJnMm8p33zOc+oznPwvGzoAdN 6NwA+tBgLrT4EM3oRjv60WtWtKQnTelKW9rMkM60pjfNafxdenudDrWSP03qUpv61KhOtapXzequ MIABMulwq9Ei6n8ghQK4zjVRIAABmfCaJhg4ia5X0utZG1srvyZJsoOCgWDHpNnARokAlM3rahd7 2sfOtlWgLW1sCwDbLvm2uMFtDxSY29wlWbY91K2SYpvE2ek2ibt7XOsxNxshMICBQPI9kHEL4B/i 7ve3BTJwgP+b4AcXY8EXom+DYMAgKChIwuWs7cT4m9znRkFJxG0Pjn97JPkmSchvC2KdleokMP8w CbkLWG/jUKWT1B5JspOtD32QpOYj+XjOwc3ul8ybJCtft0k0XvGijyQkCx/UgP/B7303HL8QmbiF IC7x4xj9xSMHecobqXJve30kUIACScIuc3cvm7vtRsnW92MSOFy96By5YkHAAIa51/0fdBdI3vFO 976ziJy8FHhDWqTKEhWE8C1PPFmOeaXG+xIuj1e85N8S4Mk35O2J0Uk+qYz5znv+86B/jOVHT/pO h/70X6OhTjeNetzIOijYTSpuQdn6O7+ecE3FME1uL8pdsV1uv49XAkufl8orFCLGD+vxC2Qjw0/d chSCUPSJn+TdUU16C5O9UsObfezXbHjYkhT/rH4//vOUh/y1fzNQ+zXaps4L9yQfm1CChX7z21/4 FqQ+Wdy613S2lK2RFToeVRFoMn3VpDkGqH9AZn1KVTX4cntPA1zCpXuwd37iZ38md4EWmH7qF3ut 1X57Mzgac1Xbt3sWiH8aSH4oiBUKeD9HsQALcBIwOBIwGIP2EAABMBI4SBI7CBM9SBIKoAAmMYP2 UIM6mIM32INBCIRCyIQzgYNQWBJQiIQ6KIU/eIRXyIFtFoRc2IRJOIU8GIVWSIUbZg8O4AAyWINE aA9duIQjcYZweBReqIV2RkMBoBl0eEEtWBl52D97+Ifm04cxBoicJogO9GMJRYh/uHCEwYgS/wEB CAGJigho+VaJDUeAQHJvCqGJAoEDOEARnhiKoTgR5lYR1iaJ/1BtCXGKqGiJkyhlpSgQsUgRjrgQ s6gRntgQrOh0lTgQt5hVzXcQn4gQD2cQl8h08mOIWSF/p1gSlrh26+ZuWdds3FZuGTcS6DYS1FiN LaFz1FZtZRdzOzd0RMcSOGAP5yhtKhF09gCN0KiM+7MRNTcQ8ygQnMiJBLFwCxeLvCYQ/SgQ9Ugm v+gQ/yhwE6ePCVeQAJZQxfhWF3KQekaHGJZ1WVcS2RiNJEgSF2kP3MaNMOGRtrJsIvlzMsFx7/YS WwdvHAmPLKcRA+eIz9h05YR4qYiKF2Jtf/9HEHAABwg3ETLZkwRRkAVZixDRcMf4D1BAkNL3fK8o ZHu1eQYneGtSi4O0d0BplRCBlXwnYBeilVCpOEvZb1YUlsHYlCBkFIzESKc0EplyLEf0lkaUlkCQ K07Ue9JSKZqkRCPBRCWXl63SIomiKSWhH3iJlyz5PhsRSG40KGAER3kEeFw0kzO1egeRRx+FEDY1 EYlYEKhUX5u5Q4cpGhg0UGZUiKHpGhN2mqq5mqxplqz5mqlnlmTxdtEFmxTEe2iBm10BjGTJm7K5 HbvDN7UJXgWWe7pJnCTXl0XhYMC3gYUznIhZa8GJLHZZnJ4FnSGInBCGgWLDnd2pfb95P1r/ZU2C tXStRJ6fmTipNCOcI4CLs17oCYCew5SUQ5/02Ufh+V5kNV+1VFCEpXxnxV74RVLshFefWZZhYoAJ upQLWp/5OUAT9VX91TiANYDz1V8bZVb/SaAZ6l6HVYD2GZZCAn1M+aA1ZhQf81QX1lPcJ3/wV4Kh FFXJGaPiJUrBp4IYmH3ciZ2IYaJjsXTuKUz/dTvLh6HtdKT8paEd6k2CMn0o2CveeYEraJtf04NW ioTmMhJu6CjjpaVzuBI/qIRe6IbpcqVU+INbmoRHGIZr2qbKOYdNaINFKKen4oU2eKZVyINUuj0P 8AAn0adM2IUvI142I4YKgy9taFVsmKhe/zqGjToS+RCpkaqo9jCpLKGGcvqFN5ijJIGGWLinoBqq IuSjU6JtpHqqqCoXorqqrNqqrhplqRqrslo+r1qrtnqruAobsxoWt7qrvpoXp/arBpOrxFqsxnoW wpqsc5FqytqsEXSsI+SsZQGt1Fqt1kpvv8qs0rpT19qtb7et4Bqu4lqq3lqu5qoWcXauKTau7HoT 6vqu8BqvV9eu9Fqv3SGv1Gqv+rqv/Nqv/loY+Jqv/3p5AVuwu6l4BqsYiacW5UgTDeuqJJl2txGx Q+GNr9ET+sCUqPgQqCh1YumrzekSDwsUFIsWNheyM1GyT9QSJ0trGnGMMHsQl+ixLVWi9/9Ds1Qn TPa4jZq4sQ1xlB5xoATHETgrsxmRcA0ZFknrixVRtPn4tAY5cT7bFEcxb1arbLgldmEndi3hIB3X cRa7duBonGzhtVLxjinhdicRdOKCtrn5ElwLFCYpfvhibZyqdRVJOBmDFWYrdCJ5cjRhiSxBbuBG uFjrGmBAEombuCPBuPbguHP5lvYQuYPrLUDnnDIRudM2t4tLdyXRd45ruI/7uJ6ruH13KCVBuZ3b uI47uY40ua6ruqe7Eq17uSZBuTkXP4JkkBUBur30lb87TljEEL7kIlZ5d4e3IMqrdwSBvAqBvE6r EY/nIo6IvDSpEJAZeWD5fM5bdQgXvXX/UbzltLsHkiDme74LIb7kO75/UhErMkjCS77TW77nC7/L yyL4+1FZQr/0eyfr6zkogbtsebsyoR+UK8BJcyq4S7nYuUmDeSsoizKRO5e4W5gu4cBuOXss4cAD DLuBeR8nMcGp2xJStJcfvMF6aZisIpigIcIifMIlvMCIdMIerIEZfKj9UcJLNBL8UBI9XMMejH8y DMItysJETMT4h4I/zBJLPMLSUn4wEbk8qoGMYsEbyBIlbMWHuqN+SZiGSYEoEcMHbMJNBMEdjMS/ h8CMMsQrocMlrMMqgcApmBIq/BkSY37cQrmVMqV0zMVnHKURjLofbMVJnMZO3MQ83DF3/wtGVwyl ZvzEUPzHLsHAHQbHlKKXDWzERzzD9tDEP0zIKTjFZ1zIgAx8d3wqVqzCUsTHJ+HJpcwegIvFdQka PbzEtUx+S+zGF+zHO9zLvtydl+LKoUzGZEzKJxjIxPzGV8zLcoyymkzMy6wymOIS8VHK2OnI0Ryy jCLMGyNFWfzAj4x/ZGTJAQy7FOzHllzF4JyBG9jMBNzK4XGwGhEndEIo9vy/BDK/DaEgDsq+hEKa BxiMDuqg+ow5ciQjBwGZCyrQTqqgTWpMJConzNe+/PvQ/UyZyUuWQguiIhpRIrpebFLQEkHP9lzP MzlIzEQn9QzQJdpGDw3R6BuiZemuSP9RLt1zoxjYt5dMxFrMnHdLxZHCxsRlPTbTUx12Kny5wUas 00NNl0n9GMY8x8As1bG2t7dyw0Shl+/3ynA2sAXRTzvBGCjI1KX0zAvk1QORsGq91mzd1m79aWgd 1wkh1uAjyjX91lWBOAmYnvMZEkKbEX/dmy/tmzPN14Q9EV6BzdwTe26TKrFcQStYm9Fl1/GcWhp8 WlztzE6lyPmCfpLNzkJx2PH0WNuLoIM906mBUhEt2KhdQgm60HC1n81H2qO90AJN285n2v5ls/P5 X+hZs9IXJrTnLpBCNkkBnawMxYo91dn8PA941I+9zChD2fADpcudp5uK3U6opS1Bhkj/6N0k0QAv QYVjqqd4St7hF9naTYYpcd56ehLlHc1hSraN7KVpihJf6oVgGN7vnd0swd5naqhCuKX7vRICMYUD geAJ/g84eOB3qNEHvuAL8eC5bbMUThAXPqxHId72IN4czuEnQYV+SoMnkQ8lYeIsAadvWBKeStWx HN+b6t7c7RJ4OhIg3uH13RKeioY7nhIjjuOQKoMlkamcbYEqHuTdbRJI2OJm2N/67RIoThIofuSe At4kgRD5YBANQBBbLhBn6OUO4OUCoQAEQeb/kOUPkeERXhAPUBALcBBqrllHYeJRTucrC+T+3d95 3t5SmOOV+hL6XeDfnd3ozckayOSe/2rl/+3fOUiGjOrfP87LKmHlUf7n2s3cF4jo/U2FTK4ScPjp Mz7jAN7ni67kpE7F9iepkhqG7J0SnR7qet7kIf49HBHmYS7mt37mBIHmZWnme80QXS4QXd7PvD7h A1HsaN7m/9Dmyq7sEDGFFJ7r/3DryN4QzD4Q177m2u7r0j7mZQ7cS+nsyz4Qb84QGf7gbejrQFLu /+DrCuHu7e7gCi7u53mgwd7SA+Hr+s7au84Q8O7tFd7aJbbheO7hQLjdbBilN37jfP7epfUSLY5/ MO6FDN/w752pd8qmLWHnQR7lY+qFLf7qR74Smo7neP6lrm4SiZ7yl57kpE7ksJ7wMf8B85H+4xOf 4zVO8ijx6gxf6QcvQgzP8HHI5ID6hUiI8S7Rp0Vv4w1g8CSxhioB4zKf81SI3JG882co6zqu8u8H W03f9CT+9C2x8KG+pRWPErBGEmkv86F+KjZv6BZY8zZuEmTPEhVf8qi+gWpInToO6maY9UNuEo+O 8pgXh1N0uPJmOH7/hlmP6K+u8ovP+IBf9rGeEj/nbgWO8j4t+FwYqHNI9XgdG3I9Ga86+hQB16af GaE/Fanvo6v/+qHX+qYP+6sq+7Z/+3BB+7rPY7jf+77PZq/5+8LfrwJrorv/EsNP/Me//Mzf/M7P QMkf/dKfqqo5/dY/18/frde//Qj/W67c//3gH/6Zlv3kX/7mf/7oDxTij9jpr4zr//71uprwP/8m 1P4uS//4n//6z632HxgbBBAABA4kCODfwX9AFC5E2NAhQoIQBzZcyJCiQocWCWzkSODhR4QWE2I8 KDIkyYsVVYJk2dLlS5gu7c2kWdPmTZw5de7k2dPnT6BBhQ4lWjQoMKRFCw4MujCnypkqpdpDCsxo VZwcZ2r9yc8rTa/8amKlmpQm17Mbt6q11/En05lw7clNS2AnXaM20ep1Wxft0oI8w4oF+zXvYcSJ FS9m3Dgr25pSFd5E27cn3rFmbZItTJho2JugO79lSpAmXbmiR88VaO/gxJiwZQt8/1iQJeyHVasi 3N2wt0mHuP/17u0bacx/tl/TbthxY0aUIk1yRF7d+nXs2bVv575c+PDjB3U3/P4dZPGHYT+WZ44d ffL2Eg3CnIjb/Oz58r3rj03b9v2IQDIPvvnwC4456kBKkEDy8uOPPtPiau20CVGbkDUAKMxQQ8c6 9PBDEH0azLO17Krprws55AkzFW3Ci8Wf9sLwJhhxGvFEyOoqkS8T5aqRxtaCzBCzpDSjLEcJN5Qw SRcn5AxIJZ3iSca7ApsxqslokpLJK19MMUQwwxTzsCKtqgkzuND80kbDHjOxSSW5JAqvLbXM0icr sQTiJillTJC48GKi7jlCn2vQoP8BGUzptvgUXbC29hI9FLn6CkTQ0OYwrXRThx7t7lNQQxV1VEYR jQ9ASx3czyXgJoVUVUlfYk9VRftT1dN/EpzVuwCr+69X3o5778FVH7pSxRr3yhNKoEoTckM1lXSW tWNnenJMbLMlalROiV0VVVkbdbVTTA/CFTlPwaW0UXV3ZTBWASNSLlPn4oVVXISc07fYV1/FF15X /WNO3VwLLbhgj+gldWGGG3Y43Hlr5Y/gUivud9zr3MUY4gNpNTDggfFt6VfhjmXRyzjhVLnalXGK ttkKrXxZw2fX/FFbnHP20McLZ1YTzzVbPPPLm6tMudqiWxaa55TTjDlonSLEsOn/noNGOWqin8b6 6Jkk5tcl+wKkmGRxAX74bLS5Y4xpoZeU8+2t42Z2aK5J49rpuo12WWu6W2Q6772ltZnqwJU2HG+5 qW2bZb2T5LtvmoeUenGdK69cVHbz0zhskS9e79/MaV1XdALN9rzjAQHDGFiwI20P7pkhd/tqxv1+ XPbLUpTaQqqrhtpy4IMP1V3OHQSMdHvnjfjr49N2/vmzxQ753lSV73Upe0c/1PjpP9ccdOShF398 kLA9Pnj001ffqKXaTnr9yOtme2746/eQfPzz1z9t+/v3/38AKmZ/AyRgAQ14QAQmUIELlEkAHfhA CEZQghOkYAUteEEMZlCDG+Rg/wc9+EEQhlCEIGJgCU14QhSKb4QrZGELXfhCn6RQhjOkYQ1teMOH qa58NGlAD334wwb4DzMOIKIDalJEGOosVAxgIkKYyAAnNtEhCqDiQ6h4RSxWESFZVABCiuiQL0KM OUUkIxldwsUsli5WYWwIGrvokADEUY5ztJXpYoLGhzxRj3o8SBr/wccoQnGLWvzHFatjyIaw8SBh dCMh1Ri+QSKyjY7sIxYj+TBF/kORksThDhMzP8Y9cScQIGXhriTKmqCyJ6pMJROJggFY2oSUEJjJ LGmJE1bOhAK7pMkueUmTWRZFjjMZpj32eEybFBNyk6uJL3HizJnskSaqVCYxA/8QFFhiwCa5RCU0 c4I4n3hzJhwgJzllaUtgltIntrxlNI+pR3uIM56/dCcDQiiqbB4kn//YZ0NQ8M9/sgSgD5llQ0h5 EAEk1CEJFUBMBvqQh1qnoA1hKEIq6i9VXdSiCj1IRKsz0YMc1CH9JKhIKcrRf2h0pLD8CEgBGtCO wtSj2VHpP2b6UJI6xKMwfQlI9ZlNDOj0pSiIKVFd8lKbzpSfLG1ITkmq1E4yDAdT/cdUrVpVqi6U oQ0FCQy8KlSjttSkIR1rS/RxVu9hZ6ZXPQhbwcpTskKgpHLFKg6wk1Ox0nWuZfUqDBDSV5DUNK4I YSddJyrY6/j0H4BtCGMVuzH/5NT0oGWt1NfyStiy/kOxmx3rY6OKEMZY1R5THS0OSmvac9pDnTgJ Zk1ai5Ns2iS2PmEoTgD6yljWpK802e1NSrnamYjWJsLtrVBeq5PashaduvUqb5ur3HbWJLmnLW1w SWuP2x5murUErmrVOVtTDuW4Z9WHPcgr3YTao7bbzYlwqWuT7LovRfFNIjZjeV9tgncm5z0vTtzL 3eies7DH3Ql90xngn/T3wAC27T+x6+AFC3gmfaVwcY32O/bSJL3prYlw/2sTC0fYu7QMZmv/Brib GFi/9pjt8S5UYaFY+Lb0Te6GOXxhtxluqDt2bXfra7eaHS22K6bJigmMu9o1/xgFOMmwTz681SaP WMoavjGVBTATxI4OX26dlHCgjNKPMLZjf/3qYv3KWDEfJM0vqelNZQrXrlIYIeQlL0ThuuOwLjWo esYrSIYaWDBrtqw+hepn/9EYGMPYJl++spJB/FzoShhoXDPwT0JcYh8DeLlYrjKnG31kohy50lI+ 7owh3N7rtmy2QM2tgUetkxDTTrgw6XNaB3vrWi0P0ClFrGI15jVDL4ydgva160QHB2Q7xLPM65xD kA2Hj7QKJsVO1UM0eu1A89pb2WnVgKDwbXBDYVEjAQJLEIsbbGvUJNJmyZqBY5Es25rNKOUcmf2q Zjm7BKSPXXO/y3wQcAf7Yf9gIDgYEFJwg5+Uq7xeuMIfUvCGEJzZkDy4xE+HHOBA/B8Ih065S4KS mmpU49ZBCbkfbvFxm/wgGuf4oW1ScJzAfCYytwfCwRCZO9WpJzSfOcFf7nN76LwmQO/5zX1Cc6L3 fGlFm26Gea7eTkcZhKSSTsnNlbB8YT3lJyGJRX7dEmmzm1VWr3rJy3Wwj3uc3GpHGHYSdK5WFac4 xYu21dPO9ZSwfe1iV9DZVf73c109YYGvu8ff3fWSV+QlC8KVpw7PdsILHFTqOQjlvUWxvKPk6yBZ yZgz1ijL/2MwgidXwiSjd4TpS+ssGRE/zhOoYDkkUMJhHXiAgdHKe6Uho0//m2S2hz1eNTvtfKc6 RqSdrtAZ5/aSB+2PnR8mOt1JTxlkPnd0s/zcwL762+d+97XzfPCHPyfeJ3/5zX9+9KtN/OtnP87S /37stF/+86d//QUIf/znX//753///f9/AAxAARzA9LM/AzxABNwgAlxA70tAB7wgBozAhnlACqxA C7xADMzAJJJAgdNAD/xAEAxBEXxADixBEzxBFEzBBRxBFswLFXxBGIxBGZxB/mtBG7xBHLw/GtxB HuxBH/xBIAxCIRxCIixC9MtBJExCJdwJI2xCJ2zCJVSiJ5xCKqxCK2SJKMxCLQzBK+xCL2SgLazA LxxDMgzAMDxDNExDNVxD/zb0oDJ8QziMQzksvzYMvzm8QzzMQz3cQz7swxisQ/bzQ0EcREIsREM8 RERMxCI0HxQDxA0aEgpxRKGARBBsxAqyxKHAROjbmRX5pLmIixDBDoojj+BgGEgaRe0IH0QpQUlB xRryGFEkxVJ8ngIxRbRZxeRoiE3sxGYRExTTxDm5i08UIcwZGWODiFx8F+7RHFlsmFpExk8xHmN0 Re6gxge5nmN8DV6BrNaxxu2gOGqElW2Uj1H8mFzLRmUcF2z8Hm/0P1VsRkuBxmeUxXbsjmVkxtKB kOqRR185xlOJFG3kmGRMRnwknWcsyOygHmQ8yID0FVmZRn4kyIgcyNuYxf/aaMiBZEiJDEiEhEYY ZEd8bMh53EiQ/JZrNBuNrLaM5EiPrEiPPEhU7MiRZEmKFBCLnMeZFBuRXI6WiJozOY0cgxZQlBNK nJrL8Bug/ERpGcphXMoViZPeEcrIGUqplJmkhEpgnD+nbMqfpMqurMqr/MqwZEqf5EqzZEqwJMtv 6sqzVJwLS0vBqRC1dBkXGcu2dEqpHMYcewu2zEul/Mu6dMsNqcn12MmVhA96nMiYHMmOxEianMnD 9Jh6tKG1Scq7tEuzzEu/1Ey0PEpITMvOPMtGhErM1MuyFEvR9EpetEzONE28DE3L5EvWZMpcXMWS pMiQdMnGrMXdNEz6wMj/xozMx1RMxyzO7mOMa5qJBaCJ5bQHBbCJK2LOmnhO55wJ6nTO6KxOmqDO 5LSH5OzO7vTJzyQm8uQh8/RO5ZROngjPIJqJ9uTOOPKJ66TOtARP6yxPYYROKjLPg2iAQUKIH+qj gwgAhCDQQqIkmDDQ/gRQx3yjQipQCP0HBT3MkTmIBUCIC5XQCH3GNwpJOjojRyKkD0XMYslQE71G j4yjSnJQFAwjBZ3QhWFRA3UAL/LNlsgHhMDRg9BRB6HRRQpIB2VRRhnQCBXSmJCjCDVQBc0HJtVR H9VRl2jSGZJSAW0IKIXSIMVI/1xQl1DSCJVQFeXSf9jSBB1ETpxLx9hP//QkytjUCfvETyKSxDGZ o5kwounMzp9o0sWoJjntUzFRREBFDj8dVEItVEP9iUA9wUNFjERt1PLTK0eNVDmklTyLLIpCv2wT tlDRqD8DlUyt0OsAkyUzTQfqNJ0YVSurCf2SurxAsBFCVdVSjPJqU+BptA6x1Z7YNMeIiXtbrIfY s+6AVFBFqO7YKlKZzO0Q1uoA1nlrCLtqq5AirGidVlFRVvIBk0aLE1idiVFlppyYLV19NZvgr1m1 H9TqCRggCljFVVkNTNzSpv2yNNc6DFdVV+yK1wcb1W39EHi1V6CILltlV/W6iXJdjHTloINNWEkD qqQ813PViYftV3gN2P+jbMubmC4Ko4lZ1VVdRa4bA7Xhgq3cwomDxbLG2FdYrRGDklaGE8h8s6yW +og6wyy6Wjiu4qn5qNSW4DKW8CnGirdxWTZrW1lq1TaDstYw+7eXNbN/MzR9OIin/YeonY9nJVar pauqrVpza6y/iqvMusiNTCqdldqOQgijurewMiqbfciAbDiXuDaLsjeE4ii92jehJaiHiFq8fdu4 TanYIFrNUrOufQm3Wlu/vVSrbTi6chC90qh2NCpV6VWwgUZmfQnJzUeH0FpopRRqpSu91Vv9MVh7 SFfSNVkW6zCaQC14ddiegNWSPdiHzdVamt3RSl2aeKngst3RnQmJNd3/geUJiiVVn4DXoaLd2DxY p0TVffUv1oKTRnxd3+WJh4XeqQHGDbGq64rd4H3YW4qTRutdt8ydCWFXTATfksWTb71YGnEy4XJK 1hUeT/XbhuIq+uVawQ1c/M3fdgNculI71Hu4lQtgNbLawxU3gJtWwzXcljDgfzDg/+Vbwky4vj0I aGtghDDg3OyqmOXfg9gJ6sXEPeEtEd5dooAC46UJo0NhFSbhCSNLo2Mn9OqJ4A1hmjBhn6DhED5f 2VXfmVth6vXgEXbKFE5hyxEVCT7ikoDHJD5cJgY7wwsJvHuJJ06I4kzgvk04JKbQrbXaB26JhPNf AYbigzPMLHZi6XA5/98V2JgjOhpezaDTkqiAY6BotBm2CRzuYdbcEKNr45eTYQ2L48j4iTuuOaCo E+mDOlx9upwY4jSGzQ0a5Ddei604CwCC5L4Y5BA2E6rwixu+kzfhiYqQHT7+ZEqe5Eg+ZcQI5aEg 5Sox5bbQkZ7QDRz55MqgEp0wkUG2ZZyQ5emT5J7YEj4GnkuW47IwEhHSZAu6FsUIZpxBC2O2B9V4 E1ZuIfHBvsiTVCK0o0ZdVG7OQWz+ZnBmwG4eZ3JujN8p5w+JQeED2xNC1mqsvi7mFlG55lsUD/Nb m/exHG+VzZ745KwMnH9+oIAWk2nmZ6LQZRwx5+AZ6AoanlhsyWpkF/8lzpi/hWiKPlbgJBaUXOdm RKDJNB1pFMlTIcx33h+cNLZl3DYEWoy70R25dIyt1B1aDa+iwRustMSWvmnxdNfUFN7ThJaXnJ6U HkeiBul/VMlutOghfUnDhMySxlyBPEdTIceJJM6azOCVZumeKc00sZ1zpsvY3Of1Vc2KDc2tbBy9 9Mu0DkougZYI+eqpBMWzXuvAfE2ytl61xES7Nui5bkqxVorZdGO6hsuxjMvWjEqGvkTHUWvSHOyZ Xku2pOv8tNjTHOy/Bmur7Euy3Ew0DV/IHuu8zuOX7ullKZWcrOiw/c3taRB2BpWQBMebHE7hDFuc dEx3fp4OUWtSbez/vdZr0Jbsn+7s397rSZzLpsFMzgZun3bXxg5tqrTq4GTb1CbpwqRJ1LZIiA7p b2TqyZ3olIzI2p5t7l6g3DZrnj7sx+bpsE7vwPbt9mbvsSZux0Zur7abn5zr3jbvuy5rxuZn3Z7s yG7T5laK0R5N5lZN9E7rrkZL3wGg4aG9o85o8Ybt6ibqpDbOePHNjY7wialqp8ZokQ5vzH3tetNH dpQIfUzIA9FsX4RvotzqzPQRGDLpk35tMTpx+Ku9jLztAeJx/IEXbU4hHw/nPkTSQxxyIkdEdP6x JFfENV1yoGhylkBQAhrRFDLS24ZSh4FRTXIJH91yLu9SHAKT5mzP//sEbPix03yoCTMPkescijfv ieYUGjzNi8RujOrI0Af4iDDv7h89GzLdUJDo81DJ0Jf4cg11iEAvoTF58zmXzwAnigeY9AdwjDYf k0rnCZZAdJeY9IbY84MAdVD/h1Gn9OswUlL3dJBgUVTXjlEHUyMfU6Ve9DINJEFaURPnblqhdUV/ GF7/CENPdMpUDOos9jOHCzv9iTdPdjRHjOekTnuyBySS9u1U03qatJoopqSZdmNyJfSdJnAPzGg3 pky8kPn87MaIU5xIdiXBIugUimk/d2qv056Qd3vH0+RM9mmHJ5rgdnsa951QpjrPidZyd3qvU3UX obSM9ujq2JzoJv9xAlmboABc8nZrSk6K1yXuAqZoSiXjvaWMFwqGV2+dCPmMB/hVmtcTxhekVW1f 2qVAujW9eiKEeHnkuPWGoACW7VzAjQlI1fmDAPqXB/qWuHVBqlvDpCtB4gBlY1l8/Nq9xV+cbwlI ZfqDsHoDnfruCyqu56ey9foJdtuPyDPDRfqeMinDrVSzzzOjYtY9G7alQg6ksqmFciizJWCY4KoD Q7B+fbC8GFW+XzRVbeTT5d2fcNV2ii7wNfyggFXlZXz/Jvzg/TRuhVXwhbIT3gnwrVcehnx4hddM U59QkSvSx1+1bSqEqNyPYFazr7CP8lrPbfppZXu8f1bSgfqJ1tz/lneIXr233W9tf3qIywV7/YWJ ZzX7ymXcza0qfUp9Y2Fewef4253+Ee7FPzbd9x0l6U/8j+fWE74upxTYvp/sDeF8+JKu64+TVIMf UUnbvnUQ93cJ0F377PD9h9BcfGy4+YDUPQPWygUICP8GEiw4EANBhP8UEhRg8GHDiP9QQKz4DwZE hwMxbnyocaLFghhGMlw4kiAAgwIJUrxIkKM+gjFDElxZkOPAlgNxEORZE+VAe0KHErUngCiGoUmF 6mta9KlQFFJREJ1K1ejQo1jtASh6FcdQsPZgDCVr7yrUombHCtWalmhXpXLtQSga9y3evHr38uWr b+hfoXWFwjDr/9bt28FtszIF3Nfe0sOLiUreOtkeDrFrM4ulC0FxXgCi744e+nlv6ct6UxNe21aA W9KMH+PtHJXo4KWQhcreq/s2UdufT4clGlhvYdpvfycePjRuXOe8n5smzpav9LN9RU/vrjW78vDK aZIvX9HnP/Qhm+7sKZM9+dEpa34uOBzlaPP69/O3KP7/WMkJBiBU2WXWHVfcCaUbc2mxRtdTthUY HIHh3VUhhhlquGGG/Xn4IYghijgiiSWaeCKKKYoUUkk4qfgijDHKOCONNdp4I4456jgjGChy+COQ QQo55I5FGnkkkkm+OCSTTTr5JJRPKTkllUtGeSWWWWq5JZddCv9VZZLz6ScmmGVWxI+OHBJAgJdt EnjhXmy6OeeWF8KJYVxy6qVnlMDQSV14fP7J152D/qegk4XaBZehHZYJjEVkklnipPHVSEBBaJrp YaVFFuVnnI1WCCeiQoGqqD2goqYXP0S1uiheqIpKJ6qprakna13JOhQ/vb5KGqLACCuUnkAYG+Sr CNIpZ2+pDvvcgw4+yFqyyQK4K7Rx+alqtLMyCqipQlnroF7GHhuagvI9xaagqXo7lInyFZTfQPPZ i9+99YoGFL8DafqPpmuWh+lABM9HMEEI17swwxDRq2+nBt0KsaT7Nhwxivn+Mx+kA3UsJsb9Vvox v/lZDHHCE6P/TFPFIqN8MssnCytseSBTXJDKG1vcqcYPz4yvyyzPW7K+Dm/6IsIG89sx0w0zDARB UP/TsdO3CryxeTZjrTPOBnFMENU/b7211AMXFLbHYF9MHqZJX+0xzSuPnZKYM8eNttAN2w2U1vmW LTXeIQ/d79Rqb9wdtkSdCu5bvamqKqB2pov4U6AC8S1XCGJrZ+TKJljqrPGWLO8/bZd+Otf8Wq00 4ZUKnjDsY6eu8NZa0y7fwbRH2nXBFNv8eulJxz5p33wT3jvyIQk/t/EM57v62rIrP3j0+QJvdfK6 P1T8xfSSqTDrIHs/L+lahyQp0ahHf3RQGfZ2p66ZS045rMq+/09o59+SqjlvnEMF+v8wB50AJk5y qSGVujLHuPt5LoD0U6D96Ae//K0GcxAcoAJlVb3jGc156asd9UAowhFKj3l526DszMc+0Xlwfa5r 4dzEBzSnxWxnctNZz2CWOhWWcHvU61kIzxdE6b3weA/D4etId7PWtZB7tcMf4z6Xv81RkIoPxGAG LYhBLGLxgtkqIBcf6MV32YOFMURf98x3xBX6UG5rjBQQb9jDDqIwaDECHhFh+DA14nFMMDzf+GhY kfKJLJBOsx6+ZChHM/6QjZvq49HeeKM+Eg9me9Thi/CYEjJysn5ZJGMCOynKUXYpcaQ8JSpTqcpV srKVrmyTI/9jKctZ0rKWtrwlLnOZy1fysped1CUwg1kiXxKzmMY8JjKT+SQFKKCYpmRSAxpAmwCQ MkX5EKaSFBCiaNqSS898Sj7cRxRqtmkBb2nmUMwZpAfwBZ0NJGeX4JkXB4TnmgRpADYhkg971igA IFpAQQCaTxj580MFHREaTaTNf/jzoOTh50MgekfzOKAgCwUTPmFEpooSpFHhFI8p6ZmhAJDUQsrU CzOZOc6SCoWa5FwATIUiUnvMtHGIyhUE3xJNadqDpz9SaTpjag93ohOeJIVnanzqgKUO5ajyxMs+ PzpUoOJlqSINZU23tNMK2iOqUsXLA8IqlJS60x4wVSdKqXr/VrMKdCA75c8DQIRHjsbnZF4l3EEd WpG3bo2udOWrkjTULEAJdagC1Ata7cFOoSwWgFCRJ1mJstW9WHWslm1qUdCqzqzSVKbjvKxhzZpO KRmEAQQx7T8yaimCxHUgrT0oYHcnJqsSxKp0/UdK75nagejVIgVt7T+Au7ug8ZAmqEVkcFk7kIsu lKwEyS15wgrcs5KHr8j1a/Qcit0TJvcfbRUocIV7JA0Z9YtCYYAFO8tZqNS0N+ilLFFmKtLyhqYo 773Qe4dCVM+elwH+Pa/+AJXf/DYOUGXFC4EVM5j3gmaeM91vZ/krX8Eo5sAFDi2Gz/nZlsrUtntx qoRDzN/e/0B4vVCBsIXTIs/3srh/qZlwTiHU4LTU9MEYtq2JVangAfFYng1OSoMmBK7o8IUCRBmw ix1blAa/18hDcfKTowyhKU8ZvzyeMpShnBjTNFDFh50yBzjAlwQPZ8FDabKUQTPjtAwmy3oBDZLt oWW9xHmLAL5znOO8ZgcqkMB4gbM90CvoK3OZx36uy56XjDlEn/mYO9YOcEDTILTkBTSVCbKQ+Ufl vSBmypL2ylCuEpnZgEbUc6lMrAD1EZqs2iYrWTUmH2KThXhEIq7OSUF0wuqDJIQ8s/6IRm59wvms pNi4PrbWdNKSWYcE2ANhtkVmLZBp/8PYz+Y1tlN37fKsev/VunZ2PknSosJwRD0T0bWLQsJszrBE P4Wp4+uYvWqRnOTZ96l2Q2DzEYvZhN3bxrev6yNIi0jl3yspCcDVfZOXZFshwp5UwWnSEpykuyIC F7ZJEB7te1vbJk2ZCa2xrexs00TY87bIvClOb4aAGyIVt3hBVo1wclNJQ502KZfQgpZuSauLJ33L x32zZOuE0iiwmU2UlGSVhtOnPCRxj3nqDZJjg8jcA+1ohhLdFwn9vOsY0vpjri52lYzdIF4/OzFv nsqys73tK4Sk2+NeJbTTvSiZ3NHLUW4RjsBd7n7/O+A3paHLIf1KYHgM4aFC+MPXvfHiCTzkZakw 4P2tRNr/s8jl/wG4qBkr8iByPOhD/3jLXw17nC/b8oLnNoTtLWVvC4mv/vUwqRWRbqf3/C1Fr3s3 mYhq6mPdCA9mEU39S1PFbWPw0za21nd+4Liv5e6jr8oLPU7T74OT3TSd+MRf+JMKZFa4ws+nXkm/ /OYvf+8baUIVWqzy6+cg8oWPPJL9XpDNf37Zz69/bxJFT+DXXLSE0RgNFrlcUfjdRfbZQ7u4C7Hs nwM+IAQqSPW5WKyUirkQXrMUnU3d1E1xlak8S5dBoJbgHwkGlgieoO6VoAqaBwq2oAu+oC+toAzO oI/AoA3eIA7moA7uIA/iBQ3+4N/1oBAOIRH+CBCSYBEme6ESLiETNiExHaEuOaEUTiEVVqEVXiEW eh0UbiEXdqEXfiEYhqEYjiEZlqEZniEahmEWruF4pOERsiEcxqHouSEdDpMcnmAd5qEe7qEd3qEf /mEy8aEgDiIhhgQgNmEhiuEhslIiNuKNLCIkRqIkTiIlVqIlXiImEkhAAAA7 ------=_NextPart_000_000A_01C733D5.532CBD00-- From ips-bounces@ietf.org Tue Jan 09 12:04:38 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4KOQ-0002Ai-KF; Tue, 09 Jan 2007 12:04:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4KOP-0002AT-HE for ips@ietf.org; Tue, 09 Jan 2007 12:04:09 -0500 Received: from [208.185.105.18] (helo=mx10.brocade.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H4KON-0002NS-6S for ips@ietf.org; Tue, 09 Jan 2007 12:04:09 -0500 Received: from blasphemy.brocade.com ([192.168.38.107]) by mx10.brocade.com with ESMTP; 09 Jan 2007 09:04:06 -0800 X-IronPort-AV: i="4.13,164,1167638400"; d="scan'208,217"; a="511876:sNHT23732667" Received: from hq-exch-1.corp.brocade.com (brono-list.brocade.com [10.3.8.21]) by blasphemy.brocade.com (Postfix) with ESMTP id 849DA142CA; Tue, 9 Jan 2007 09:04:06 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ips] T10 data protection and iSCSI Date: Tue, 9 Jan 2007 09:04:43 -0800 Message-ID: <6002A63FDB393D4F9ADB36DE70C4847501CDF991@hq-exch-1.corp.brocade.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ips] T10 data protection and iSCSI thread-index: Acczn43t5f+5+2O9S2W+tg9kLBI8eQAcCGTg From: "Robert Snively" To: "Vishal Study" , "ips" X-Spam-Score: 0.1 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 Cc: X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1955734606==" Errors-To: ips-bounces@ietf.org This is a multi-part message in MIME format. --===============1955734606== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C73410.417FA24A" This is a multi-part message in MIME format. ------_=_NextPart_001_01C73410.417FA24A Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable T10 data protection simply changes slightly the content and length of the data fields sent to and received from the storage device. It also modifies the behavior of some commands, depending on the checking level selected for the data protection mechanism. That is described in the T10 standard SBC-2 (and SBC-3, now in development). =20 It has no effect on the iSCSI protocol itself and is completely independent of RFC 3720. =20 Bob ________________________________ From: Vishal Study [mailto:vishal.study@gmail.com]=20 Sent: Monday, January 08, 2007 7:35 PM To: ips Subject: [Ips] T10 data protection and iSCSI Hi: =20 What is relation between T10 data protection mechanism and iSCSI protocol? I couldn't find any reference to T10 data protection inside RFC 3720. Pardon my ignorance if this is stupid question...I am quite new to the storage area. =20 Thanks, Vishal. ------_=_NextPart_001_01C73410.417FA24A Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
T10 data protection simply changes slightly the = content and=20 length of the data
fields sent to and received from the storage = device. =20 It also modifies
the behavior of some commands, depending on the = checking=20 level
selected for the data protection = mechanism.  That is=20 described in the
T10 standard SBC-2 (and SBC-3, now in=20 development).
 
It has no effect on the iSCSI protocol itself = and is=20 completely independent
of RFC 3720.
 
Bob

From: Vishal Study=20 [mailto:vishal.study@gmail.com]
Sent: Monday, January 08, = 2007 7:35=20 PM
To: ips
Subject: [Ips] T10 data protection and=20 iSCSI

Hi:
 
What is relation between T10 data protection mechanism = and iSCSI=20 protocol?

I couldn't find any reference to T10 data protection inside RFC = 3720.

Pardon my = ignorance if=20 this is stupid question...I am quite new to the storage area.
 
Thanks,
Vishal.
------_=_NextPart_001_01C73410.417FA24A-- --===============1955734606== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============1955734606==-- From ips-bounces@ietf.org Tue Jan 09 12:29:23 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4Kmi-0004C0-Nk; Tue, 09 Jan 2007 12:29:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4Kmh-0004Bt-EA for ips@ietf.org; Tue, 09 Jan 2007 12:29:15 -0500 Received: from imf18aec.mail.bellsouth.net ([205.152.59.66]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H4Kmf-0002aI-2X for ips@ietf.org; Tue, 09 Jan 2007 12:29:15 -0500 Received: from ibm61aec.bellsouth.net ([74.245.52.54]) by imf18aec.mail.bellsouth.net with ESMTP id <20070109172803.JYPE19155.imf18aec.mail.bellsouth.net@ibm61aec.bellsouth.net> for ; Tue, 9 Jan 2007 12:28:03 -0500 Received: from IVVTDKV0981 ([74.245.52.54]) by ibm61aec.bellsouth.net with SMTP id <20070109172802.OZUU29185.ibm61aec.bellsouth.net@IVVTDKV0981>; Tue, 9 Jan 2007 12:28:02 -0500 Message-ID: <000501c73413$88433f80$01faa8c0@ivivity.com> From: "Eddy Quicksall" To: "RAM SUNEE" , References: Subject: Re: [Ips] Device Identification VPD Page for iSCSI Targets Date: Tue, 9 Jan 2007 12:28:09 -0500 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ips-bounces@ietf.org This is more of a T10 question but my take is this: The ASSOCIATION field is simply used to show which entity the DESIGNATOR field is associated with. It has nothing to do with the PROTOCOL IDENTIFIER. You may get several Designators, one for each type. For iSCSI the PROTOCOL IDENTIFIER would 5 for ASSOCIATION values of 01b or 10b when the PIV bit is set. Eddy ----- Original Message ----- From: "RAM SUNEE" To: "Eddy Quicksall" ; Sent: Tuesday, January 09, 2007 2:21 AM Subject: RE: [Ips] Device Identification VPD Page for iSCSI Targets > What about ASSOCIATION field. Is it supposed to be Logical Unit,Target > port > or Target Device ?? > > > -----Original Message----- > From: Eddy Quicksall [mailto:Quicksall_iSCSI@Bellsouth.net] > Sent: Monday, January 08, 2007 8:05 AM > To: RAM SUNEE; ips@ietf.org > Subject: Re: [Ips] Device Identification VPD Page for iSCSI Targets > > > Referring to Table 296 of spc4r07a it seems the value should be 5 meaning > iSCSI. > > Eddy > > ----- Original Message ----- > From: "RAM SUNEE" > To: > Sent: Monday, January 08, 2007 10:20 AM > Subject: [Ips] Device Identification VPD Page for iSCSI Targets > > >> All, >> >> Can anyone please clarify me regarding, Device Identification VPD usage >> for >> iSCSI Target. >> What values should an iSCSI Target use for PROTOCOL_IDENTIFIER, >> ASSOCIATION >> fields of Device Identification VPD response page. >> I have noticed that iSCSI Targets are reportng to Initiators as "SCSI >> Disk >> Device",is it correct behavior? >> Isn't it supposed to be that iSCSI Target needs to report to Initiator as >> "iSCSI Disk Device" >> >> -RAM >> >> >> >> _______________________________________________ >> Ips mailing list >> Ips@ietf.org >> https://www1.ietf.org/mailman/listinfo/ips >> > > > _______________________________________________ > Ips mailing list > Ips@ietf.org > https://www1.ietf.org/mailman/listinfo/ips > _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Tue Jan 09 13:59:44 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4MC0-0006YP-QU; Tue, 09 Jan 2007 13:59:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4MBz-0006YK-Ny for ips@ietf.org; Tue, 09 Jan 2007 13:59:27 -0500 Received: from imf18aec.mail.bellsouth.net ([205.152.59.66]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H4MBy-0006Fo-CB for ips@ietf.org; Tue, 09 Jan 2007 13:59:27 -0500 Received: from ibm61aec.bellsouth.net ([74.245.52.54]) by imf18aec.mail.bellsouth.net with ESMTP id <20070109185907.GHZU23379.imf18aec.mail.bellsouth.net@ibm61aec.bellsouth.net> for ; Tue, 9 Jan 2007 13:59:07 -0500 Received: from IVVTDKV0981 ([74.245.52.54]) by ibm61aec.bellsouth.net with SMTP id <20070109185906.SUST29185.ibm61aec.bellsouth.net@IVVTDKV0981>; Tue, 9 Jan 2007 13:59:06 -0500 Message-ID: <001201c73420$3e30eca0$01faa8c0@ivivity.com> From: "Eddy Quicksall" To: "Vishal Study" , "ips" References: Subject: Re: [Ips] T10 data protection and iSCSI Date: Tue, 9 Jan 2007 13:59:08 -0500 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.1 (/) X-Scan-Signature: b22590c27682ace61775ee7b453b40d3 Cc: X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2017840484==" Errors-To: ips-bounces@ietf.org This is a multi-part message in MIME format. --===============2017840484== Content-Type: multipart/alternative; boundary="----=_NextPart_000_000F_01C733F6.55264010" This is a multi-part message in MIME format. ------=_NextPart_000_000F_01C733F6.55264010 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Being new to the storage area this can be very confusing at first. SCSI = can be transported by many different types of transports. In fact more = than one transport can be used to a single SCSI device. iSCSI is a = transport layer and is described in RFC 3720. Most of what you read in = SAM, SPC, SBC, etc are not related to the transport and hence you will = generally not find references in RFC 3720 regarding those issues. Some = will be related in which case you will see a reference to the = appropriate transport protocol. When reading the SCSI documents (not the transport documents) you will = see a term "Service Delivery Subsystem". That includes what I call the = transport layer. Eddy ----- Original Message -----=20 From: Vishal Study=20 To: ips=20 Sent: Monday, January 08, 2007 10:34 PM Subject: [Ips] T10 data protection and iSCSI Hi: What is relation between T10 data protection mechanism and iSCSI = protocol? I couldn't find any reference to T10 data protection inside RFC 3720. Pardon my ignorance if this is stupid question...I am quite new to the = storage area. Thanks, Vishal. -------------------------------------------------------------------------= ----- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips ------=_NextPart_000_000F_01C733F6.55264010 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Being new to the storage area this can be very = confusing at=20 first. SCSI can be transported by many different types of transports. In = fact=20 more than one transport can be used to a single SCSI device. iSCSI is a=20 transport layer and is described in RFC 3720. Most of what you read = in SAM,=20 SPC, SBC, etc are not related to the transport and hence you will = generally not=20 find references in RFC 3720 regarding those issues. Some will be related = in=20 which case you will see a reference to the appropriate transport=20 protocol.
 
When reading the SCSI documents (not the transport = documents)=20 you will see a term "Service Delivery Subsystem". That includes = what I call=20 the transport layer.
 
Eddy
----- Original Message -----
From:=20 Vishal=20 Study
To: ips
Sent: Monday, January 08, 2007 = 10:34=20 PM
Subject: [Ips] T10 data = protection and=20 iSCSI

Hi:
 
What is relation between T10 data protection mechanism=20 and iSCSI protocol?

I couldn't find any reference to T10 data protection inside = RFC=20 3720.

Pardon my ignorance if this is stupid question...I am quite = new to=20 the storage area.
 
Thanks,
Vishal.

_______________________________________________
Ips mailing=20 = list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips
------=_NextPart_000_000F_01C733F6.55264010-- --===============2017840484== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============2017840484==-- From ips-bounces@ietf.org Tue Jan 09 15:44:53 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4Npn-00065w-T3; Tue, 09 Jan 2007 15:44:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4Npe-0005sV-Rb for ips@ietf.org; Tue, 09 Jan 2007 15:44:30 -0500 Received: from ug-out-1314.google.com ([66.249.92.168]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H4NnQ-0003ae-TB for ips@ietf.org; Tue, 09 Jan 2007 15:42:14 -0500 Received: by ug-out-1314.google.com with SMTP id 72so6286954ugd for ; Tue, 09 Jan 2007 12:42:12 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=LJG2J7hWWSmCIBV1Ri+T4Jy68FbZ4ZVcqwaoCk4/k5w58BenY3QN4Ssk9LI5rrOTcFzPo1EazKTsWRxZggNcBssGXfSPc1YKpNVzBOyXX2yixW4n8mwsPuznGlkwhLhIJ+dpVYyEjaCaPC1075mZtfseZnI7vXY1/vWsyk0hLKI= Received: by 10.82.118.2 with SMTP id q2mr3031060buc.1168375332078; Tue, 09 Jan 2007 12:42:12 -0800 (PST) Received: by 10.78.201.12 with HTTP; Tue, 9 Jan 2007 12:42:11 -0800 (PST) Message-ID: Date: Tue, 9 Jan 2007 12:42:11 -0800 From: "Vishal Study" To: ips Subject: Re: [Ips] T10 data protection and iSCSI In-Reply-To: <6002A63FDB393D4F9ADB36DE70C4847501CDF991@hq-exch-1.corp.brocade.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <6002A63FDB393D4F9ADB36DE70C4847501CDF991@hq-exch-1.corp.brocade.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ips-bounces@ietf.org Hi: Thanks everyone for the guidance and pointers. To summarize, T10 is a mechanism to ensure the integrity of data read/written from/to the storage device. iSCSI is just *a* transport mechanism to carry the data between initiator and target. A followup question: I understand that T10 mechanism adds extra 8 bytes to 512 byte block. This operation is done before data is actually written to the storage device (at the target in iSCSI terminology). Is this understanding correct? Thanks again, Vishal. On 1/9/07, Robert Snively wrote: > > T10 data protection simply changes slightly the content and length of the > data > fields sent to and received from the storage device. It also modifies > the behavior of some commands, depending on the checking level > selected for the data protection mechanism. That is described in the > T10 standard SBC-2 (and SBC-3, now in development). > > It has no effect on the iSCSI protocol itself and is completely independent > of RFC 3720. > > Bob > ________________________________ > From: Vishal Study [mailto:vishal.study@gmail.com] > Sent: Monday, January 08, 2007 7:35 PM > To: ips > Subject: [Ips] T10 data protection and iSCSI > > > Hi: > > What is relation between T10 data protection mechanism and iSCSI protocol? > > I couldn't find any reference to T10 data protection inside RFC 3720. > > Pardon my ignorance if this is stupid question...I am quite new to the > storage area. > > Thanks, > Vishal. _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Tue Jan 09 15:50:09 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4Nv5-0000IA-Ab; Tue, 09 Jan 2007 15:50:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4Nv0-0000HY-Tz; Tue, 09 Jan 2007 15:50:02 -0500 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H4Nv0-0005JP-M1; Tue, 09 Jan 2007 15:50:02 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 9F06F3292A; Tue, 9 Jan 2007 20:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1H4Nv0-0002D4-HB; Tue, 09 Jan 2007 15:50:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 09 Jan 2007 15:50:02 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: ips@ietf.org Subject: [Ips] I-D ACTION:draft-ietf-ips-iscsi-impl-guide-04.txt X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ips-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Storage Working Group of the IETF. Title : iSCSI Corrections and Clarifications Author(s) : M. Chadalapaka Filename : draft-ietf-ips-iscsi-impl-guide-04.txt,.pdf Pages : 37 Date : 2007-1-9 iSCSI is a SCSI transport protocol and maps the SCSI family of application protocols onto TCP/IP. RFC 3720 defines the iSCSI protocol. This document compiles the clarifications to the original protocol definition in RFC 3720 to serve as a companion document for the iSCSI implementers. This document updates RFC 3720 and the text in this document supersedes the text in RFC 3720 when the two differ. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ips-iscsi-impl-guide-04.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ips-iscsi-impl-guide-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ips-iscsi-impl-guide-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-1-9142021.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ips-iscsi-impl-guide-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ips-iscsi-impl-guide-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-1-9142021.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --NextPart-- From ips-bounces@ietf.org Tue Jan 09 17:29:37 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4PT8-0006Yj-EO; Tue, 09 Jan 2007 17:29:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4PT6-0006YB-Tm for ips@ietf.org; Tue, 09 Jan 2007 17:29:20 -0500 Received: from web51905.mail.yahoo.com ([206.190.48.68]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H4PT5-0003OG-GX for ips@ietf.org; Tue, 09 Jan 2007 17:29:20 -0500 Received: (qmail 6240 invoked by uid 60001); 9 Jan 2007 22:29:18 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=NY1SIXmB0w4kjWnq9ZYcbDqIYO5F7JFMik1M83/tGu/4ORBERMy6AaoCbkasO3CXBV/moaODA/3ZsrU3IWZo9avZC7NvJlmETh+6nAwIJA4v4QT0tRTLruVHnyCQg/ZjJNbd+JK2vEkBg5mUNYuk1I8lzcRRiWMVRJNmDCUP3LU= ; Message-ID: <20070109222918.6238.qmail@web51905.mail.yahoo.com> Received: from [15.227.217.75] by web51905.mail.yahoo.com via HTTP; Tue, 09 Jan 2007 14:29:18 PST Date: Tue, 9 Jan 2007 14:29:18 -0800 (PST) From: "Mallikarjun C." To: ips@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ascii Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Subject: [Ips] draft-ietf-ips-iscsi-impl-guide-04.txt X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ips-bounces@ietf.org Summary of the few technical changes. I am ignoring the editorial/boilerpl= ate changes in the list below, as well as the change in title.=0A=0A- Added= an introductory paragraph in section 3.1.2 that REPORT LUNS is an example = used in the rest of the section to illustrate the requirements. (Rob Elliot= t's comment)=0A=0A- New key TaskReporting with three values, and dropping t= he old FastMultiTaskAbort key. There were a few related changes scattered = throughout the draft. (David Black's comment)=0A=0A- Section 3.3.2, bullet = (b) - change from "may solicit" to "SHOULD solicit". (Rob Elliott's comment= )=0A=0A- Section 3.3.3,, bullet 7. Addition of PERSISTENT RESERVE OUT/PREE= MPT AND ABORT as a grandfathered case for fencing (Rob Elliott's comment)= =0A=0A- Section 4.1.2 and 4.1.3 drop the requirement to wait for oustanding= TTTs for 3rd party initiators (David Black's comment)=0A=0A- Section 4.1.4= to clarify that buffer management to backup outstanding TTTs is really an = implementation choice (Julian Satran/David Black's comment)=0A=0A- Section = 5.3 (new) to restrict the types of target-generated PDUs on Discovey sessio= ns (list discussion)=0A=0A- Section 6.1 clarifies that TPGT text is fixed i= n SAM-4 (Rob Elliott's comment)=0A=0A- Section 6.4 clarifies that there can= be only one outstanding Login or Text negotiation at any time (anonymous r= eviewer/Julian Satran's comment)=0A=0A- Section 7.4 clarifies the message e= rror checking expectations on the receiver (Eddy Quicksall/Paul Koning's co= mment)=0A=0A- Section 8.2 notes the obsoletion of a Reject reason code (ano= nymous reviewer)=0A=0A=0ABTW, the pdf copy has the complete change bars.=0A= http://www.ietf.org/internet-drafts/draft-ietf-ips-iscsi-impl-guide-04.pdf= =0A=0A=0AMallikarjun=0A=0A=0A----- Original Message ----=0AFrom: "Internet-= Drafts@ietf.org" =0ATo: i-d-announce@ietf.org=0AC= c: ips@ietf.org=0ASent: Tuesday, January 9, 2007 12:50:02 PM=0ASubject: [Ip= s] I-D ACTION:draft-ietf-ips-iscsi-impl-guide-04.txt=0A=0A=0AA New Internet= -Draft is available from the on-line Internet-Drafts =0Adirectories.=0AThis= draft is a work item of the IP Storage Working Group of the IETF.=0A=0A = Title : iSCSI Corrections and Clarifications=0A Author(s) : M= . Chadalapaka=0A Filename : draft-ietf-ips-iscsi-impl-guide-04.txt,.p= df=0A Pages : 37=0A Date : 2007-1-9=0A =0AiSCSI is a= SCSI transport protocol and maps the SCSI family =0A of application pr= otocols onto TCP/IP. RFC 3720 defines the=0A iSCSI protocol. This doc= ument compiles the clarifications to =0A the original protocol definiti= on in RFC 3720 to serve as a =0A companion document for the iSCSI imple= menters. This document =0A updates RFC 3720 and the text in this docume= nt supersedes the =0A text in RFC 3720 when the two differ.=0A=0AA URL = for this Internet-Draft is:=0Ahttp://www.ietf.org/internet-drafts/draft-iet= f-ips-iscsi-impl-guide-04.txt=0A=0ATo remove yourself from the I-D Announce= ment list, send a message to =0Ai-d-announce-request@ietf.org with the word= unsubscribe in the body of =0Athe message. =0AYou can also visit https://w= ww1.ietf.org/mailman/listinfo/I-D-announce =0Ato change your subscription s= ettings.=0A=0AInternet-Drafts are also available by anonymous FTP. Login wi= th the =0Ausername "anonymous" and a password of your e-mail address. After= =0Alogging in, type "cd internet-drafts" and then =0A"get draft-ietf-ips-i= scsi-impl-guide-04.txt".=0A=0AA list of Internet-Drafts directories can be = found in=0Ahttp://www.ietf.org/shadow.html =0Aor ftp://ftp.ietf.org/ietf/1s= hadow-sites.txt=0A=0AInternet-Drafts can also be obtained by e-mail.=0A=0AS= end a message to:=0A mailserv@ietf.org.=0AIn the body type:=0A "FILE = /internet-drafts/draft-ietf-ips-iscsi-impl-guide-04.txt".=0A =0ANOTE: = The mail server at ietf.org can return the document in=0A MIME-encoded = form by using the "mpack" utility. To use this=0A feature, insert the c= ommand "ENCODING mime" before the "FILE"=0A command. To decode the resp= onse(s), you will need "munpack" or=0A a MIME-compliant mail reader. Di= fferent MIME-compliant mail readers=0A exhibit different behavior, espec= ially when dealing with=0A "multipart" MIME messages (i.e. documents whi= ch have been split=0A up into multiple messages), so check your local do= cumentation on=0A how to manipulate these messages.=0A=0ABelow is the da= ta which will enable a MIME compliant mail reader=0Aimplementation to autom= atically retrieve the ASCII version of the=0AInternet-Draft.=0A____________= ___________________________________=0AIps mailing list=0AIps@ietf.org=0Ahtt= ps://www1.ietf.org/mailman/listinfo/ips=0A=0A______________________________= ____________________=0ADo You Yahoo!?=0ATired of spam? Yahoo! Mail has the= best spam protection around =0Ahttp://mail.yahoo.com _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Wed Jan 10 10:44:11 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4fcJ-0005ME-Mc; Wed, 10 Jan 2007 10:43:55 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4fcG-0005Fq-K6; Wed, 10 Jan 2007 10:43:52 -0500 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1H4fcF-0005aw-8r; Wed, 10 Jan 2007 10:43:52 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id F169617625; Wed, 10 Jan 2007 15:43:20 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1H4fbk-0005vQ-Ig; Wed, 10 Jan 2007 10:43:20 -0500 X-test-idtracker: no From: The IESG To: IETF-Announce Message-Id: Date: Wed, 10 Jan 2007 10:43:20 -0500 X-Spam-Score: -2.8 (--) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 Cc: ips mailing list , Internet Architecture Board , ips chair , RFC Editor Subject: [Ips] Protocol Action: 'Declarative Public Extension Key for iSCSI Node Architecture' to Proposed Standard X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ips-bounces@ietf.org The IESG has approved the following document: - 'Declarative Public Extension Key for iSCSI Node Architecture ' as a Proposed Standard This document is the product of the IP Storage Working Group. The IESG contact persons are Lars Eggert and Magnus Westerlund. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ips-iscsi-nodearch-key-03.txt Technical Summary The iSCSI protocol, described in RFC 3720, allows for extension items to the protocol in the form of Private or Public Extension Keys. This Internet-Draft describes a Public Extension Key for the purpose of enhancing iSCSI supportability. The key accomplishes this objective by allowing iSCSI nodes to communicate architecture details during the iSCSI login sequence. The receiving node can then use this information for enhanced logging and support. Working Group Summary This document was carefully reviewed in the WG primarily for security concerns (protecting sensitive information about what is running) and the possible abuse of this key in a fashion similar to theabuse of the HTTP "Server" and "User-Agent" fields that can damage interoperability. As a result of this WG attention, the draft contains specific text to address both concerns. Protocol Quality There are implementations of functionality similar to that provided by this key. This draft was reviewed for the IPS WG by David L. Black., who also acted as PROTO Document Shepherd. Lars Eggert reviewed this document for the IESG. Note to RFC Editor Section 3, paragraph 2 OLD: Nodes implementing this key MAY choose to only transmit the key, only log the key values received from other nodes, or both transmit and log the key values. NEW: Nodes implementing this key MUST choose one of the following implementation options: o only transmit the key o only log the key values received from other nodes or o both transmit and log the key values. Section 3, paragraph 3 OLD: Thus, a valid implementation of this key may be that a node is completely silent NEW: Thus, a valid behavior for this key may be that a node is completely silent In Section 5 IANA Considerations, insert the following text after the first paragraph: NEW: The update to RFC 3720 to allow additional types of RFCs for iSCSI Extension items has the same effect as if the following changes were made to the text of RFC 3720 (RFC text cannot be changed after publication): 1) In Section 11.1, the requirement that Z# Authentication methods "MUST be described by an informational RFC." is changed to "MUST be described by a standards track RFC, an experimental RFC or an informational RFC." 2) In Section 12.1, the requirement that Y# Digest algorithms "MUST be described by an informational RFC." is changed to "MUST be described by a standards track RFC, an experimental RFC or an informational RFC." 3) In Section 12.22, the requirement that X# text keys "MUST be described by an informational RFC." is changed to "MUST be described by a standards track RFC, an experimental RFC or an informational RFC." 4) In Section 13.3, the description of allowed RFC types for extension items is changed from "The RFC may be informational rather than Standards-Track," to "The RFC MUST be standards track, experimental or informational," 5) In Section 13.5.2, the phrase "standards track" is changed to "standards track or experimental" in the last sentence of the first paragraph, so that the sentence reads: "If the specification is a standards track or experimental document, the usual IETF procedures for such documents are followed." The registries for iSCSI extension items should be managed as if these changes had been made to the text of RFC 3720. _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Wed Jan 10 11:44:05 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4gYK-0003o4-Li; Wed, 10 Jan 2007 11:43:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4gYI-0003np-Ue; Wed, 10 Jan 2007 11:43:50 -0500 Received: from [212.25.127.226] (helo=gfi-gw.seabridge.co.il) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H4gYH-000192-Ex; Wed, 10 Jan 2007 11:43:50 -0500 Received: from mail pickup service by gfi-gw.seabridge.co.il with Microsoft SMTPSVC; Wed, 10 Jan 2007 18:42:12 +0200 Received: from aligator.seabridge.co.il ([212.25.127.237]) by gfi-gw.seabridge.co.il with Microsoft SMTPSVC(6.0.3790.1830); Wed, 10 Jan 2007 17:58:02 +0200 Received: from megatron.ietf.org ([156.154.16.145]) by aligator.seabridge.co.il with Microsoft SMTPSVC(5.0.2195.5329); Wed, 10 Jan 2007 19:05:59 +0200 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4fcJ-0005Lh-Ck; Wed, 10 Jan 2007 10:43:55 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4fcG-0005Fq-K6; Wed, 10 Jan 2007 10:43:52 -0500 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1H4fcF-0005aw-8r; Wed, 10 Jan 2007 10:43:52 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id F169617625; Wed, 10 Jan 2007 15:43:20 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1H4fbk-0005vQ-Ig; Wed, 10 Jan 2007 10:43:20 -0500 X-test-idtracker: no From: The IESG To: IETF-Announce Message-Id: Date: Wed, 10 Jan 2007 10:43:20 -0500 X-Spam-Score: -2.8 (--) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 X-BeenThere: ietf-announce@ietf.org X-Mailman-Version: 2.1.5 Precedence: list X-OriginalArrivalTime: 10 Jan 2007 17:06:00.0254 (UTC) FILETIME=[9A2D0DE0:01C734D9] X-Spam-Score: 1.8 (+) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 Cc: ips mailing list , Internet Architecture Board , ips chair , RFC Editor Subject: [Ips] Protocol Action: 'Declarative Public Extension Key for iSCSI Node Architecture' to Proposed Standard X-BeenThere: ips@ietf.org List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ips-bounces@ietf.org The IESG has approved the following document: - 'Declarative Public Extension Key for iSCSI Node Architecture ' as a Proposed Standard This document is the product of the IP Storage Working Group. The IESG contact persons are Lars Eggert and Magnus Westerlund. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ips-iscsi-nodearch-key-03.txt Technical Summary The iSCSI protocol, described in RFC 3720, allows for extension items to the protocol in the form of Private or Public Extension Keys. This Internet-Draft describes a Public Extension Key for the purpose of enhancing iSCSI supportability. The key accomplishes this objective by allowing iSCSI nodes to communicate architecture details during the iSCSI login sequence. The receiving node can then use this information for enhanced logging and support. Working Group Summary This document was carefully reviewed in the WG primarily for security concerns (protecting sensitive information about what is running) and the possible abuse of this key in a fashion similar to theabuse of the HTTP "Server" and "User-Agent" fields that can damage interoperability. As a result of this WG attention, the draft contains specific text to address both concerns. Protocol Quality There are implementations of functionality similar to that provided by this key. This draft was reviewed for the IPS WG by David L. Black., who also acted as PROTO Document Shepherd. Lars Eggert reviewed this document for the IESG. Note to RFC Editor Section 3, paragraph 2 OLD: Nodes implementing this key MAY choose to only transmit the key, only log the key values received from other nodes, or both transmit and log the key values. NEW: Nodes implementing this key MUST choose one of the following implementation options: o only transmit the key o only log the key values received from other nodes or o both transmit and log the key values. Section 3, paragraph 3 OLD: Thus, a valid implementation of this key may be that a node is completely silent NEW: Thus, a valid behavior for this key may be that a node is completely silent In Section 5 IANA Considerations, insert the following text after the first paragraph: NEW: The update to RFC 3720 to allow additional types of RFCs for iSCSI Extension items has the same effect as if the following changes were made to the text of RFC 3720 (RFC text cannot be changed after publication): 1) In Section 11.1, the requirement that Z# Authentication methods "MUST be described by an informational RFC." is changed to "MUST be described by a standards track RFC, an experimental RFC or an informational RFC." 2) In Section 12.1, the requirement that Y# Digest algorithms "MUST be described by an informational RFC." is changed to "MUST be described by a standards track RFC, an experimental RFC or an informational RFC." 3) In Section 12.22, the requirement that X# text keys "MUST be described by an informational RFC." is changed to "MUST be described by a standards track RFC, an experimental RFC or an informational RFC." 4) In Section 13.3, the description of allowed RFC types for extension items is changed from "The RFC may be informational rather than Standards-Track," to "The RFC MUST be standards track, experimental or informational," 5) In Section 13.5.2, the phrase "standards track" is changed to "standards track or experimental" in the last sentence of the first paragraph, so that the sentence reads: "If the specification is a standards track or experimental document, the usual IETF procedures for such documents are followed." The registries for iSCSI extension items should be managed as if these changes had been made to the text of RFC 3720. _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Wed Jan 10 12:16:43 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4h3w-0003DP-Sx; Wed, 10 Jan 2007 12:16:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4h3t-0003C1-7s; Wed, 10 Jan 2007 12:16:29 -0500 Received: from [212.25.127.226] (helo=gfi-gw.seabridge.co.il) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H4h3j-0004yl-IO; Wed, 10 Jan 2007 12:16:28 -0500 Received: from dove.seabridge.co.il ([172.30.10.115]) by gfi-gw.seabridge.co.il with Microsoft SMTPSVC(6.0.3790.1830); Wed, 10 Jan 2007 19:14:36 +0200 Received: from mail pickup service by dove.seabridge.co.il with Microsoft SMTPSVC; Wed, 10 Jan 2007 19:07:57 +0200 Received: from mail pickup service by gfi-gw.seabridge.co.il with Microsoft SMTPSVC; Wed, 10 Jan 2007 18:42:47 +0200 Received: from aligator.seabridge.co.il ([212.25.127.237]) by gfi-gw.seabridge.co.il with Microsoft SMTPSVC(6.0.3790.1830); Wed, 10 Jan 2007 17:59:23 +0200 Received: from megatron.ietf.org ([156.154.16.145]) by aligator.seabridge.co.il with Microsoft SMTPSVC(5.0.2195.5329); Wed, 10 Jan 2007 19:00:19 +0200 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4fcI-0005J8-Q9; Wed, 10 Jan 2007 10:43:54 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4fcG-0005Fq-K6; Wed, 10 Jan 2007 10:43:52 -0500 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1H4fcF-0005aw-8r; Wed, 10 Jan 2007 10:43:52 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id F169617625; Wed, 10 Jan 2007 15:43:20 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1H4fbk-0005vQ-Ig; Wed, 10 Jan 2007 10:43:20 -0500 X-test-idtracker: no From: The IESG To: IETF-Announce Message-Id: Date: Wed, 10 Jan 2007 10:43:20 -0500 X-Spam-Score: -2.8 (--) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 X-BeenThere: ietf-announce@ietf.org X-Mailman-Version: 2.1.5 Precedence: list X-OriginalArrivalTime: 10 Jan 2007 17:00:19.0935 (UTC) FILETIME=[CF547EF0:01C734D8] X-Spam-Score: 1.8 (+) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 Cc: ips mailing list , Internet Architecture Board , ips chair , RFC Editor Subject: [Ips] Protocol Action: 'Declarative Public Extension Key for iSCSI Node Architecture' to Proposed Standard X-BeenThere: ips@ietf.org List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ips-bounces@ietf.org The IESG has approved the following document: - 'Declarative Public Extension Key for iSCSI Node Architecture ' as a Proposed Standard This document is the product of the IP Storage Working Group. The IESG contact persons are Lars Eggert and Magnus Westerlund. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ips-iscsi-nodearch-key-03.txt Technical Summary The iSCSI protocol, described in RFC 3720, allows for extension items to the protocol in the form of Private or Public Extension Keys. This Internet-Draft describes a Public Extension Key for the purpose of enhancing iSCSI supportability. The key accomplishes this objective by allowing iSCSI nodes to communicate architecture details during the iSCSI login sequence. The receiving node can then use this information for enhanced loggingFrom ips-bounces@ietf.org Wed Jan 10 12:16:43 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4h3w-0003DP-Sx; Wed, 10 Jan 2007 12:16:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4h3t-0003C1-7s; Wed, 10 Jan 2007 12:16:29 -0500 Received: from [212.25.127.226] (helo=gfi-gw.seabridge.co.il) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H4h3j-0004yl-IO; Wed, 10 Jan 2007 12:16:28 -0500 Received: from dove.seabridge.co.il ([172.30.10.115]) by gfi-gw.seabridge.co.il with Microsoft SMTPSVC(6.0.3790.1830); Wed, 10 Jan 2007 19:14:36 +0200 Received: from mail pickup service by dove.seabridge.co.il with Microsoft SMTPSVC; Wed, 10 Jan 2007 19:07:57 +0200 Received: from mail pickup service by gfi-gw.seabridge.co.il with Microsoft SMTPSVC; Wed, 10 Jan 2007 18:42:47 +0200 Received: from aligator.seabridge.co.il ([212.25.127.237]) by gfi-gw.seabridge.co.il with Microsoft SMTPSVC(6.0.3790.1830); Wed, 10 Jan 2007 17:59:23 +0200 Received: from megatron.ietf.org ([156.154.16.145]) by aligator.seabridge.co.il with Microsoft SMTPSVC(5.0.2195.5329); Wed, 10 Jan 2007 19:00:19 +0200 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4fcI-0005J8-Q9; Wed, 10 Jan 2007 10:43:54 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4fcG-0005Fq-K6; Wed, 10 Jan 2007 10:43:52 -0500 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1H4fcF-0005aw-8r; Wed, 10 Jan 2007 10:43:52 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id F169617625; Wed, 10 Jan 2007 15:43:20 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1H4fbk-0005vQ-Ig; Wed, 10 Jan 2007 10:43:20 -0500 X-test-idtracker: no From: The IESG To: IETF-Announce Message-Id: Date: Wed, 10 Jan 2007 10:43:20 -0500 X-Spam-Score: -2.8 (--) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 X-BeenThere: ietf-announce@ietf.org X-Mailman-Version: 2.1.5 Precedence: list X-OriginalArrivalTime: 10 Jan 2007 17:00:19.0935 (UTC) FILETIME=[CF547EF0:01C734D8] X-Spam-Score: 1.8 (+) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 Cc: ips mailing list , Internet Architecture Board , ips chair , RFC Editor Subject: [Ips] Protocol Action: 'Declarative Public Extension Key for iSCSI Node Architecture' to Proposed Standard X-BeenThere: ips@ietf.org List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ips-bounces@ietf.org The IESG has approved the following document: - 'Declarative Public Extension Key for iSCSI Node Architecture ' as a Proposed Standard This document is the product of the IP Storage Working Group. The IESG contact persons are Lars Eggert and Magnus Westerlund. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ips-iscsi-nodearch-key-03.txt Technical Summary The iSCSI protocol, described in RFC 3720, allows for extension items to the protocol in the form of Private or Public Extension Keys. This Internet-Draft describes a Public Extension Key for the purpose of enhancing iSCSI supportability. The key accomplishes this objective by allowing iSCSI nodes to communicate architecture details during the iSCSI login sequence. The receiving node can then use this information for enhanced logging and support. Working Group Summary This document was carefully reviewed in the WG primarily for security concerns (protecting sensitive information about what is running) and the possible abuse of this key in a fashion similar to theabuse of the HTTP "Server" and "User-Agent" fields that can damage interoperability. As a result of this WG attention, the draft contains specific text to address both concerns. Protocol Quality There are implementations of functionality similar to that provided by this key. This draft was reviewed for the IPS WG by David L. Black., who also acted as PROTO Document Shepherd. Lars Eggert reviewed this document for the IESG. Note to RFC Editor Section 3, paragraph 2 OLD: Nodes implementing this key MAY choose to only transmit the key, only log the key values received from other nodes, or both transmit and log the key values. NEW: Nodes implementing this key MUST choose one of the following implementation options: o only transmit the key o only log the key values received from other nodes or o both transmit and log the key values. Section 3, paragraph 3 OLD: Thus, a valid implementation of this key may be that a node is completely silent NEW: Thus, a valid behavior for this key may be that a node is completely silent In Section 5 IANA Considerations, insert the following text after the first paragraph: NEW: The update to RFC 3720 to allow additional types of RFCs for iSCSI Extension items has the same effect as if the following changes were made to the text of RFC 3720 (RFC text cannot be changed after publication): 1) In Section 11.1, the requirement that Z# Authentication methods "MUST be described by an informational RFC." is changed to "MUST be described by a standards track RFC, an experimental RFC or an informational RFC." 2) In Section 12.1, the requirement that Y# Digest algorithms "MUST be described by an informational RFC." is changed to "MUST be described by a standards track RFC, an experimental RFC or an informational RFC." 3) In Section 12.22, the requirement that X# text keys "MUST be described by an informational RFC." is changed to "MUST be described by a standards track RFC, an experimental RFC or an informational RFC." 4) In Section 13.3, the description of allowed RFC types for extension items is changed from "The RFC may be informational rather than Standards-Track," to "The RFC MUST be standards track, experimental or informational," 5) In Section 13.5.2, the phrase "standards track" is changed to "standards track or experimental" in the last sentence of the first paragraph, so that the sentence reads: "If the specification is a standards track or experimental document, the usual IETF procedures for such documents are followed." The registries for iSCSI extension items should be managed as if these changes had been made to the text of RFC 3720. _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Wed Jan 10 12:16:43 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4h47-0003I0-AS; Wed, 10 Jan 2007 12:16:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4h45-0003Hq-PE; Wed, 10 Jan 2007 12:16:41 -0500 Received: from [212.25.127.226] (helo=gfi-gw.seabridge.co.il) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H4h42-0004yl-NP; Wed, 10 Jan 2007 12:16:41 -0500 Received: from dove.seabridge.co.il ([172.30.10.115]) by gfi-gw.seabridge.co.il with Microsoft SMTPSVC(6.0.3790.1830); Wed, 10 Jan 2007 19:14:58 and support. Working Group Summary This document was carefully reviewed in the WG primarily for security concerns (protecting sensitive information about what is running) and the possible abuse of this key in a fashion similar to theabuse of the HTTP "Server" and "User-Agent" fields that can damage interoperability. As a result of this WG attention, the draft contains specific text to address both concerns. Protocol Quality There are implementations of functionality similar to that provided by this key. This draft was reviewed for the IPS WG by David L. Black., who also acted as PROTO Document Shepherd. Lars Eggert reviewed this document for the IESG. Note to RFC Editor Section 3, paragraph 2 OLD: Nodes implementing this key MAY choose to only transmit the key, only log the key values received from other nodes, or both transmit and log the key values. NEW: Nodes implementing this key MUST choose one of the following implementation options: o only transmit the key o only log the key values received from other nodes or o both transmit and log the key values. Section 3, paragraph 3 OLD: Thus, a valid implementation of this key may be that a node is completely silent NEW: Thus, a valid behavior for this key may be that a node is completely silent In Section 5 IANA Considerations, insert the following text after the first paragraph: NEW: The update to RFC 3720 to allow additional types of RFCs for iSCSI Extension items has the same effect as if the following changes were made to the text of RFC 3720 (RFC text cannot be changed after publication): 1) In Section 11.1, the requirement that Z# Authentication methods "MUST be described by an informational RFC." is changed to "MUST be described by a standards track RFC, an experimental RFC or an informational RFC." 2) In Section 12.1, the requirement that Y# Digest algorithms "MUST be described by an informational RFC." is changed to "MUST be described by a standards track RFC, an experimental RFC or an informational RFC." 3) In Section 12.22, the requirement that X# text keys "MUST be described by an informational RFC." is changed to "MUST be described by a standards track RFC, an experimental RFC or an informational RFC." 4) In Section 13.3, the description of allowed RFC types for extension items is changed from "The RFC may be informational rather than Standards-Track," to "The RFC MUST be standards track, experimental or informational," 5) In Section 13.5.2, the phrase "standards track" is changed to "standards track or experimental" in the last sentence of the first paragraph, so that the sentence reads: "If the specification is a standards track or experimental document, the usual IETF procedures for such documents are followed." The registries for iSCSI extension items should be managed as if these changes had been made to the text of RFC 3720. _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Wed Jan 10 12:16:43 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4h47-0003I0-AS; Wed, 10 Jan 2007 12:16:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4h45-0003Hq-PE; Wed, 10 Jan 2007 12:16:41 -0500 Received: from [212.25.127.226] (helo=gfi-gw.seabridge.co.il) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H4h42-0004yl-NP; Wed, 10 Jan 2007 12:16:41 -0500 Received: from dove.seabridge.co.il ([172.30.10.115]) by gfi-gw.seabridge.co.il with Microsoft SMTPSVC(6.0.3790.1830); Wed, 10 Jan 2007 19:14:58 +0200 Received: from mail pickup service by dove.seabridge.co.il with Microsoft SMTPSVC; Wed, 10 Jan 2007 19:10:00 +0200 Received: from mail pickup service by gfi-gw.seabridge.co.il with Microsoft SMTPSVC; Wed, 10 Jan 2007 18:42:12 +0200 Received: from aligator.seabridge.co.il ([212.25.127.237]) by gfi-gw.seabridge.co.il with Microsoft SMTPSVC(6.0.3790.1830); Wed, 10 Jan 2007 17:58:02 +0200 Received: from megatron.ietf.org ([156.154.16.145]) by aligator.seabridge.co.il with Microsoft SMTPSVC(5.0.2195.5329); Wed, 10 Jan 2007 19:05:59 +0200 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4fcJ-0005Lh-Ck; Wed, 10 Jan 2007 10:43:55 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4fcG-0005Fq-K6; Wed, 10 Jan 2007 10:43:52 -0500 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1H4fcF-0005aw-8r; Wed, 10 Jan 2007 10:43:52 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id F169617625; Wed, 10 Jan 2007 15:43:20 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1H4fbk-0005vQ-Ig; Wed, 10 Jan 2007 10:43:20 -0500 X-test-idtracker: no From: The IESG To: IETF-Announce Message-Id: Date: Wed, 10 Jan 2007 10:43:20 -0500 X-Spam-Score: -2.8 (--) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 X-BeenThere: ietf-announce@ietf.org X-Mailman-Version: 2.1.5 Precedence: list X-OriginalArrivalTime: 10 Jan 2007 17:06:00.0254 (UTC) FILETIME=[9A2D0DE0:01C734D9] X-Spam-Score: 1.8 (+) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 Cc: ips mailing list , Internet Architecture Board , ips chair , RFC Editor Subject: [Ips] Protocol Action: 'Declarative Public Extension Key for iSCSI Node Architecture' to Proposed Standard X-BeenThere: ips@ietf.org List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ips-bounces@ietf.org The IESG has approved the following document: - 'Declarative Public Extension Key for iSCSI Node Architecture ' as a Proposed Standard This document is the product of the IP Storage Working Group. The IESG contact persons are Lars Eggert and Magnus Westerlund. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ips-iscsi-nodearch-key-03.txt Technical Summary The iSCSI protocol, described in RFC 3720, allows for extension items to the protocol in the form of Private or Public Extension Keys. This Internet-Draft describes a Public Extension Key for the purpose of enhancing iSCSI supportability. The key accomplishes this objective by allowing iSCSI nodes to communicate architecture details during the iSCSI login sequence. The receiving node can then use this information for enhanced logging and support. Working Group Summary This document was carefully reviewed in the WG primarily for security concerns (protecting sensitive information about what is running) and the possible abuse of this key in a fashion similar to theabuse of the HTTP "Server" and "User-Agent" fields that can damage interoperability. As a result of this WG attention, the draft contains specific text to address both concerns. Protocol Quality There are implementations of functionality similar to that provided by this key. This draft was reviewed for the IPS WG by David L. Black., who also acted as PROTO Document Shepherd. Lars Eggert rev +0200 Received: from mail pickup service by dove.seabridge.co.il with Microsoft SMTPSVC; Wed, 10 Jan 2007 19:10:00 +0200 Received: from mail pickup service by gfi-gw.seabridge.co.il with Microsoft SMTPSVC; Wed, 10 Jan 2007 18:42:12 +0200 Received: from aligator.seabridge.co.il ([212.25.127.237]) by gfi-gw.seabridge.co.il with Microsoft SMTPSVC(6.0.3790.1830); Wed, 10 Jan 2007 17:58:02 +0200 Received: from megatron.ietf.org ([156.154.16.145]) by aligator.seabridge.co.il with Microsoft SMTPSVC(5.0.2195.5329); Wed, 10 Jan 2007 19:05:59 +0200 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4fcJ-0005Lh-Ck; Wed, 10 Jan 2007 10:43:55 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4fcG-0005Fq-K6; Wed, 10 Jan 2007 10:43:52 -0500 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1H4fcF-0005aw-8r; Wed, 10 Jan 2007 10:43:52 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id F169617625; Wed, 10 Jan 2007 15:43:20 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1H4fbk-0005vQ-Ig; Wed, 10 Jan 2007 10:43:20 -0500 X-test-idtracker: no From: The IESG To: IETF-Announce Message-Id: Date: Wed, 10 Jan 2007 10:43:20 -0500 X-Spam-Score: -2.8 (--) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 X-BeenThere: ietf-announce@ietf.org X-Mailman-Version: 2.1.5 Precedence: list X-OriginalArrivalTime: 10 Jan 2007 17:06:00.0254 (UTC) FILETIME=[9A2D0DE0:01C734D9] X-Spam-Score: 1.8 (+) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 Cc: ips mailing list , Internet Architecture Board , ips chair , RFC Editor Subject: [Ips] Protocol Action: 'Declarative Public Extension Key for iSCSI Node Architecture' to Proposed Standard X-BeenThere: ips@ietf.org List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ips-bounces@ietf.org The IESG has approved the following document: - 'Declarative Public Extension Key for iSCSI Node Architecture ' as a Proposed Standard This document is the product of the IP Storage Working Group. The IESG contact persons are Lars Eggert and Magnus Westerlund. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ips-iscsi-nodearch-key-03.txt Technical Summary The iSCSI protocol, described in RFC 3720, allows for extension items to the protocol in the form of Private or Public Extension Keys. This Internet-Draft describes a Public Extension Key for the purpose of enhancing iSCSI supportability. The key accomplishes this objective by allowing iSCSI nodes to communicate architecture details during the iSCSI login sequence. The receiving node can then use this information for enhanced logging and support. Working Group Summary This document was carefully reviewed in the WG primarily for security concerns (protecting sensitive information about what is running) and the possible abuse of this key in a fashion similar to theabuse of the HTTP "Server" and "User-Agent" fields that can damage interoperability. As a result of this WG attention, the draft contains specific text to address both concerns. Protocol Quality There are implementations of functionality similar to that provided by this key. This draft was reviewed for the IPS WG by David L. Black., who also acted as PROTO Document Shepherd. Lars Eggert reviewed this document for the IESG. Note to RFC Editor Section 3, paragraph 2 OLD: Nodes implementing this key MAY choose to only transmit the key, only log the key values received from other nodes, or both transmit and log the key values. NEW: Nodes implementing this key MUST choose one of the following implementation options: o only transmit the key o only log the key values received from other nodes or o both transmit and log the key values. Section 3, paragraph 3 OLD: Thus, a valid implementation of this key may be that a node is completely silent NEW: Thus, a valid behavior for this key may be that a node is completely silent In Section 5 IANA Considerations, insert the following text after the first paragraph: NEW: The update to RFC 3720 to allow additional types of RFCs for iSCSI Extension items has the same effect as if the following changes were made to the text of RFC 3720 (RFC text cannot be changed after publication): 1) In Section 11.1, the requirement that Z# Authentication methods "MUST be described by an informational RFC." is changed to "MUST be described by a standards track RFC, an experimental RFC or an informational RFC." 2) In Section 12.1, the requirement that Y# Digest algorithms "MUST be described by an informational RFC." is changed to "MUST be described by a standards track RFC, an experimental RFC or an informational RFC." 3) In Section 12.22, the requirement that X# text keys "MUST be described by an informational RFC." is changed to "MUST be described by a standards track RFC, an experimental RFC or an informational RFC." 4) In Section 13.3, the description of allowed RFC types for extension items is changed from "The RFC may be informational rather than Standards-Track," to "The RFC MUST be standards track, experimental or informational," 5) In Section 13.5.2, the phrase "standards track" is changed to "standards track or experimental" in the last sentence of the first paragraph, so that the sentence reads: "If the specification is a standards track or experimental document, the usual IETF procedures for such documents are followed." The registries for iSCSI extension items should be managed as if these changes had been made to the text of RFC 3720. _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips iewed this document for the IESG. Note to RFC Editor Section 3, paragraph 2 OLD: Nodes implementing this key MAY choose to only transmit the key, only log the key values received from other nodes, or both transmit and log the key values. NEW: Nodes implementing this key MUST choose one of the following implementation options: o only transmit the key o only log the key values received from other nodes or o both transmit and log the key values. Section 3, paragraph 3 OLD: Thus, a valid implementation of this key may be that a node is completely silent NEW: Thus, a valid behavior for this key may be that a node is completely silent In Section 5 IANA Considerations, insert the following text after the first paragraph: NEW: The update to RFC 3720 to allow additional types of RFCs for iSCSI Extension items has the same effect as if the following changes were made to the text of RFC 3720 (RFC text cannot be changed after publication): 1) In Section 11.1, the requirement that Z# Authentication methods "MUST be described by an informational RFC." is changed to "MUST be described by a standards track RFC, an experimental RFC or an informational RFC." 2) In Section 12.1, the requirement that Y# Digest algorithms "MUST be described by an informational RFC." is changed to "MUST be described by a standards track RFC, an experimental RFC or an informational RFC." 3) In Section 12.22, the requirement that X# text keys "MUST be described by an informational RFC." is changed to "MUST be described by a standards track RFC, an experimental RFC or an informational RFC." 4) In Section 13.3, the description of allowed RFC types for extension items is changed from "The RFC may be informational rather than Standards-Track," to "The RFC MUST be standards track, experimental or informational," 5) In Section 13.5.2, the phrase "standards track" is changed to "standards track or experimental" in the last sentence of the first paragraph, so that the sentence reads: "If the specification is a standards track or experimental document, the usual IETF procedures for such documents are followed." The registries for iSCSI extension items should be managed as if these changes had been made to the text of RFC 3720. _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Wed Jan 10 12:16:48 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4h43-0003G2-LH; Wed, 10 Jan 2007 12:16:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4h42-0003Et-38; Wed, 10 Jan 2007 12:16:38 -0500 Received: from [212.25.127.226] (helo=gfi-gw.seabridge.co.il) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H4h3z-0004yl-2u; Wed, 10 Jan 2007 12:16:38 -0500 Received: from dove.seabridge.co.il ([172.30.10.115]) by gfi-gw.seabridge.co.il with Microsoft SMTPSVC(6.0.3790.1830); Wed, 10 Jan 2007 19:14:57 +0200 Received: from mail pickup service by dove.seabridge.co.il with Microsoft SMTPSVC; Wed, 10 Jan 2007 19:08:01 +0200 Received: from mail pickup service by gfi-gw.seabridge.co.il with Microsoft SMTPSVC; Wed, 10 Jan 2007 18:42:47 +0200 Received: from aligator.seabridge.co.il ([212.25.127.237]) by gfi-gw.seabridge.co.il with Microsoft SMTPSVC(6.0.3790.1830); Wed, 10 Jan 2007 17:59:23 +0200 Received: from megatron.ietf.org ([156.154.16.145]) by aligator.seabridge.co.il with Microsoft SMTPSVC(5.0.2195.5329); Wed, 10 Jan 2007 18:59:42 +0200 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4fcI-0005J8-Jq; Wed, 10 Jan 2007 10:43:54 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4fcG-0005Fq-K6; Wed, 10 Jan 2007 10:43:52 -0500 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1H4fcF-0005aw-8r; Wed, 10 Jan 2007 10:43:52 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id F169617625; Wed, 10 Jan 2007 15:43:20 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1H4fbk-0005vQ-Ig; Wed, 10 Jan 2007 10:43:20 -0500 X-test-idtracker: no From: The IESG To: IETF-Announce Message-Id: Date: Wed, 10 Jan 2007 10:43:20 -0500 X-Spam-Score: -2.8 (--) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 X-BeenThere: ietf-announce@ietf.org X-Mailman-Version: 2.1.5 Precedence: list X-OriginalArrivalTime: 10 Jan 2007 16:59:42.0951 (UTC) FILETIME=[B9492F70:01C734D8] X-Spam-Score: 1.8 (+) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 Cc: ips mailing list , Internet Architecture Board , ips chair , RFC Editor Subject: [Ips] Protocol Action: 'Declarative Public Extension Key for iSCSI Node Architecture' to Proposed Standard X-BeenThere: ips@ietf.org List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ips-bounces@ietf.org The IESG has approved the following document: - 'Declarative Public Extension Key for iSCSI Node Architecture ' as a Proposed Standard This document is the product of the IP Storage Working Group. The IESG contact persons are Lars Eggert and Magnus Westerlund. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ips-iscsi-nodearch-key-03.txt Technical Summary The iSCSI protocol, described in RFC 3720, allows for extension items to the protocol in the form of Private or Public Extension Keys. This Internet-Draft describes a Public Extension Key for the purpose of enhancing iSCSI supportability. The key accomplishes this objective by allowing iSCSI nodes to communicate architecture details during the iSCSI login sequence. The receiving node can then use this information for enhanced logging and support. Working Group Summary This document was carefully reviewed in the WG primarily for security concerns (protecting sensitive information about what is running) and the possible abuse of this key in a fashion similar to theabuse of the HTTP "Server" and "User-Agent" fields that can damage interoperability. As a result of this WG attention, the draft contains specific text to address both concerns. Protocol Quality There are implementations of functionality similar to that provided by this key. This draft was reviewed for the IPS WG by David L. Black., who also acted as PROTO Document Shepherd. Lars Eggert reviewed this document for the IESG. Note to RFC Editor Section 3, paragraph 2 OLD: Nodes implementing this key MAY choose to only transmit the key, only log the key values received from other nodes, or both transmit and log the key values. NEW: Nodes implementing this key MUST choose one of the following implementation options: o only transmit the key o only log the key values received from other nodes or o both transmit and log the key values. Section 3, paragraph 3 OLD: Thus, a valid implementation of this key may be that a node is completely silent NEW: Thus, a valid behavior for this key may be that a node is completely silent In Section 5 IANA Considerations, insert the following text after the first paragraph: NEW: The update to RFC 3720 to allow additional types of RFCs for iSCSI Extension items has the same effect as if the following changes were made to the text of RFC 3720 (RFC text cannot be changed after publication): 1) In Section 11.1, the requirement that Z# Authentication methods "MUST be described by an informational RFC." is changed to "MUST be described by a standards track RFC, an experimental RFC or an informational RFC." 2) In Section 12.1, the requirement that Y# Digest algorithms "MUST be described by an informational RFC." is changed to "MUST be described by a standards track RFC, an experimental RFC or an informational RFC." 3) In Section 12.22, the requirement that X# text keys "MUST be described by an informational RFC." is changed to "MUST be described by a standards track RFC, an experimental RFC or an informational RFC." 4) In Section 13.3, the description of allowed RFC types for extension items is changed from "The RFC may be informational rather than Standards-Track," to "The RFC MUST be standards track, experimental or informational," 5) In Section 13.5.2, the phrase "standards track" is changed to "standards track or experimental" in the last sentence of the first paragraph, so that the sentence reads: "If the specification is a standards track or experimental document, the usual IETF procedures for such documents are followed." The registries for iSCSI extension items should be managed as if these changes had been made to the text of RFC 3720. _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Wed Jan 10 12:16:43 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4h41-0003En-SM; Wed, 10 Jan 2007 12:16:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4h3z-0003EF-Cu; Wed, 10 Jan 2007 12:16:35 -0500 Received: from [212.25.127.226] (helo=gfi-gw.seabridge.co.il) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H4h3t-0004yl-Qi; Wed, 10 Jan 2007 12:16:34 -0500 Received: from dove.seabridge.co.il ([172.30.10.115]) by gfi-gw.seabridge.co.il with Microsoft SMTPSVC(6.0.3790.1830); Wed, 10 Jan 2007 19:14:57 +0200 Received: from mail pickup service by dove.seabridge.co.il with Microsoft SMTPSVC; Wed, 10 Jan 2007 19:08:01 +0200 Received: from mail pickup service by gfi-gw.seabridge.co.il with Microsoft SMTPSVC; Wed, 10 Jan 2007 18:42:47 +0200 Received: from aligator.seabridge.co.il ([212.25.127.237]) by gfi-gw.seabridge.co.il with Microsoft SMTPSVC(6.0.3790.1830); Wed, 10 Jan 2007 17:59:23 +0200 Received: from megatron.ietf.org ([156.154.16.145]) by aligator.seabridge.co.il with Microsoft SMTPSVC(5.0.2195.5329); Wed, 10 Jan 2007 18:59:36 +0200 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4fcI-0005J8-EQ; Wed, 10 Jan 2007 10:43:54 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4fcG-0005Fq-K6; Wed, 10 Jan 2007 10:43:52 -0500 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1H4fcF-0005aw-8r; Wed, 10 Jan 2007 10:43:52 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id F169617625; Wed, 10 Jan 2007 15:43:20 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1H4fbk-0005vQ-Ig; Wed, 10 Jan 2007 10:43:20 -0500 X-test-idtracker: no From: The IESG To: IETF-Announce Message-Id: Date: Wed, 10 Jan 2007 10:43:20 -0500 X-Spam-Score: -2.8 (--) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 X-BeenThere: ietf-announce@ietf.org X-Mailman-Version: 2.1.5 Precedence: list X-OriginalArrivalTime: 10 Jan 2007 16:59:37.0103 (UTC) FILETIME=[B5CCD9F0:01C734D8] X-Spam-Score: 1.8 (+) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 Cc: ips mailing list , Internet Architecture Board , ips chair , RFC Editor Subject: [Ips] Protocol Action: 'Declarative Public Extension Key for iSCSI Node Architecture' to Proposed Standard X-BeenThere: ips@ietf.org List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ips-bounces@ietf.org The IESG has approved the following document: - 'Declarative Public Extension Key for iSCSI Node Architecture ' as a Proposed Standard This document is the product of the IP Storage Working Group. The IESG contact persons are Lars Eggert and Magnus Westerlund. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ips-iscsi-nodearch-key-03.txt Technical Summary The iSCSI protocol, described in RFC 3720, allows for extension items to the protocol in the form of Private or Public Extension Keys. This Internet-Draft describes a Public Extension Key for the purpose of enhancing iSCSI supportability. The key accomplishes this objective by allowing iSCSI nodes to communicate architecture details during the iSCSI login sequence. The receiving node can then use this information for enhanced logging and support. Working Group Summary This document was carefully reviewed in the WG primarily for security concerns (protecting sensitive information about what is running) and the possible abuse of this key in a fashion similar to theabuse of the HTTP "Server" and "User-Agent" fields that can damage interoperability. As a result of this WG attention, the draft contains specific text to address both concerns. Protocol Quality There are implementations of functionality similar to that provided by this key. This draft was reviewed for the IPS WG by David L. Black., who also acted as PROTO Document Shepherd. Lars Eggert reviewed this document for the IESG. Note to RFC Editor Section 3, paragraph 2 OLD: Nodes implementing this key MAY choose to only transmit the key, only log the key values received from other nodes, or both transmit and log the key values. NEW: Nodes implementing this key MUST choose one of the following implementation options: o only transmit the key o only log the key values received from other nodes or o both transmit and log the key values. Section 3, paragraph 3 OLD: Thus, a valid implementation of this key may be that a node is completely silent NEW: Thus, a valid behavior for this key may be that a node is completely silent In Section 5 IANA Considerations, insert the following text after the first paragraph: NEW: The update to RFC 3720 to allow additional types of RFCs for iSCSI Extension items has the same effect as if the following changes were made to the text of RFC 3720 (RFC text cannot be changed after publication): 1) In Section 11.1, the requirement that Z# Authentication methods "MUST be described by an informational RFC." is changed to "MUST be described by a standards track RFC, an experimental RFC or an informational RFC." 2) In Section 12.1, the requirement that Y# Digest algorithms "MUST be described by an informational RFC." is changed to "MUST be described by a standards track RFC, an experimental RFC or an informational RFC." 3) In Section 12.22, the requirement that X# text keys "MUST be described by an informational RFC." is changed to "MUST be described by a standards track RFC, an experimental RFC or an informational RFC." 4) In Section 13.3, the description of allowed RFC types for extension items is changed from "The RFC may be informational rather than Standards-Track," to "The RFC MUST be standards track, experimental or informational," 5) In Section 13.5.2, the phrase "standards track" is changed to "standards track or experimental" in the last sentence of the first paragraph, so that the sentence reads: "If the specification is a standards track or experimental document, the usual IETF procedures for such documents are followed." The registries for iSCSI extension items should be managed as if these changes had been made to the text of RFC 3720. _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Wed Jan 10 15:14:24 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4jpq-0002v5-4R; Wed, 10 Jan 2007 15:14:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4jpo-0002uv-O5 for ips@ietf.org; Wed, 10 Jan 2007 15:14:08 -0500 Received: from ccerelbas03.cce.hp.com ([161.114.21.106]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H4jpf-0001Xp-V8 for ips@ietf.org; Wed, 10 Jan 2007 15:14:08 -0500 Received: from cceexg11.americas.cpqcorp.net (cceexg11.americas.cpqcorp.net [16.81.1.59]) by ccerelbas03.cce.hp.com (Postfix) with ESMTP id 7F41B3430B for ; Wed, 10 Jan 2007 14:13:59 -0600 (CST) Received: from cceexcsp04.americas.cpqcorp.net ([16.81.1.18]) by cceexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 10 Jan 2007 14:13:59 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ips] Device Identification VPD Page for iSCSI Targets Date: Wed, 10 Jan 2007 14:13:58 -0600 Message-ID: In-Reply-To: <000501c73413$88433f80$01faa8c0@ivivity.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [Ips] Device Identification VPD Page for iSCSI Targets Thread-Index: Acc0E9eIOr37kr2ITu67EiuDDFTmVwAwYnew References: <000501c73413$88433f80$01faa8c0@ivivity.com> From: "Elliott, Robert (Server Storage)" To: X-OriginalArrivalTime: 10 Jan 2007 20:13:59.0327 (UTC) FILETIME=[DD0702F0:01C734F3] X-Spam-Score: 0.0 (/) X-Scan-Signature: ce732c7d36989a1bd55104ba259c40a1 X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1773409962==" Errors-To: ips-bounces@ietf.org This is a multi-part message in MIME format. --===============1773409962== Content-class: urn:content-classes:message Content-Type: multipart/signed; boundary="----=_NextPart_000_0059_01C734C1.91F89B70"; protocol="application/x-pkcs7-signature"; micalg=SHA1 This is a multi-part message in MIME format. ------=_NextPart_000_0059_01C734C1.91F89B70 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit The Device Identification VPD page includes lots of identifiers. 1. ASSOCIATION=00b identifiers are related to the logical unit. Since a target device could have target ports of many protocols (e.g., iSCSI and Fibre Channel), a logical unit is not considered to be tied to any protocol. PIV=0 and the PROTOCOL IDENTIFIER field is considered reserved. The same set is reported regardless of the target port being used by the INQUIRY command. The VPD page should include one of these: a) NAA identifer b) EUI-64 based identifier c) SCSI name string identifier containing ",L,0x<16 digits>" d) SCSI name string identifier not starting with iqn (e.g. "naa.6nnnn...") 2. ASSOCIATION=01b identifiers are related to the target port through which the INQUIRY command is being run. These are protocol-specific, so PIV=1 and PROTOCOL IDENTIFIER=5h if the INQUIRY command is coming through an iSCSI target port. If it is an iSCSI target port, the VPD page should include both: a) SCSI name string identifer containing ",t,0x" b) Relative Target Port identifier containing an index 1..n for each target port in the target device. 3. ASSOCIATION=10b identifiers are related to the target device; the same set is reported regardless of the target port being used by the INQURIY command. Each protocol is allowed to contribute a target device name. The VPD page should include: a) SCSI name string identifier containing "" It is valid to use either PIV=0 or to use PIV=1 and PROTOCOL IDENTIFIER=5h. PIV=1 is probably better if the target device has ports using multiple protocols and chooses to report a different target device name for each protocol. PIV=0 is probably better if it reports one common target device name (which could be done in an iSCSI/FC combination target device if the iSCSI name uses "naa." format). -- Rob Elliott, elliott@hp.com Hewlett-Packard Industry Standard Server Storage Advanced Technology https://ecardfile.com/id/RobElliott > -----Original Message----- > From: Eddy Quicksall [mailto:Quicksall_iSCSI@Bellsouth.net] > Sent: Tuesday, January 09, 2007 11:28 AM > To: RAM SUNEE; ips@ietf.org > Subject: Re: [Ips] Device Identification VPD Page for iSCSI Targets > > This is more of a T10 question but my take is this: The > ASSOCIATION field is > simply used to show which entity the DESIGNATOR field is > associated with. It > has nothing to do with the PROTOCOL IDENTIFIER. You may get several > Designators, one for each type. For iSCSI the PROTOCOL > IDENTIFIER would 5 > for ASSOCIATION values of 01b or 10b when the PIV bit is set. > > Eddy > > ----- Original Message ----- > From: "RAM SUNEE" > To: "Eddy Quicksall" ; > Sent: Tuesday, January 09, 2007 2:21 AM > Subject: RE: [Ips] Device Identification VPD Page for iSCSI Targets > > > > What about ASSOCIATION field. Is it supposed to be Logical > Unit,Target > > port > > or Target Device ?? > > > > > > -----Original Message----- > > From: Eddy Quicksall [mailto:Quicksall_iSCSI@Bellsouth.net] > > Sent: Monday, January 08, 2007 8:05 AM > > To: RAM SUNEE; ips@ietf.org > > Subject: Re: [Ips] Device Identification VPD Page for iSCSI Targets > > > > > > Referring to Table 296 of spc4r07a it seems the value > should be 5 meaning > > iSCSI. > > > > Eddy > > > > ----- Original Message ----- > > From: "RAM SUNEE" > > To: > > Sent: Monday, January 08, 2007 10:20 AM > > Subject: [Ips] Device Identification VPD Page for iSCSI Targets > > > > > >> All, > >> > >> Can anyone please clarify me regarding, Device > Identification VPD usage > >> for > >> iSCSI Target. > >> What values should an iSCSI Target use for PROTOCOL_IDENTIFIER, > >> ASSOCIATION > >> fields of Device Identification VPD response page. > >> I have noticed that iSCSI Targets are reportng to > Initiators as "SCSI > >> Disk > >> Device",is it correct behavior? > >> Isn't it supposed to be that iSCSI Target needs to report > to Initiator as > >> "iSCSI Disk Device" > >> > >> -RAM > >> > >> > >> > >> _______________________________________________ > >> Ips mailing list > >> Ips@ietf.org > >> https://www1.ietf.org/mailman/listinfo/ips > >> > > > > > > _______________________________________________ > > Ips mailing list > > Ips@ietf.org > > https://www1.ietf.org/mailman/listinfo/ips > > > > > _______________________________________________ > Ips mailing list > Ips@ietf.org > https://www1.ietf.org/mailman/listinfo/ips > ------=_NextPart_000_0059_01C734C1.91F89B70 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIN9TCCAwMw ggJsAhEAuS9gzIifoXpGCbhbcGyKrzANBgkqhkiG9w0BAQUFADCBwTELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMTwwOgYDVQQLEzNDbGFzcyAyIFB1YmxpYyBQcmltYXJ5IENl cnRpZmljYXRpb24gQXV0aG9yaXR5IC0gRzIxOjA4BgNVBAsTMShjKSAxOTk4IFZlcmlTaWduLCBJ bmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmswHhcNOTgwNTE4MDAwMDAwWhcNMjgwODAxMjM1OTU5WjCBwTELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMTwwOgYDVQQLEzNDbGFzcyAyIFB1YmxpYyBQcmltYXJ5IENl cnRpZmljYXRpb24gQXV0aG9yaXR5IC0gRzIxOjA4BgNVBAsTMShjKSAxOTk4IFZlcmlTaWduLCBJ bmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmswgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAKeIASF0LOcaA/CY4Zc8DyEI8Zzbl+ma /MIEBhO+X1LIzB4sElYsuAFpLMyZH62wlq55BPITOcF7mLoILOjChBMsqmnpCfTHqQKkQsIjT0rY 8A6i+zFsyeZvmScH9eb0THiebetGhvq5hslU8rLEr9RGHFrJFTD/DWz1LQ5tzn93AgMBAAEwDQYJ KoZIhvcNAQEFBQADgYEAci75f9HxcfvEnvbFXlGKQJi4aPibHIPY4p29/+2h5mbqLwn0ytfqpSuV 9iRghk1ELoOlxC2g0654aW9y2myuCPBjkjfmu8QwF613zEk1qs/Yj9G+txiWR3NqVCI0ZC22FptZ W7RRWTqzCxT0Et9noPStMmResUZyJ4wSe8VEtK4wggQlMIIDjqADAgECAhBWO27ntnEulADNe55i te6UMA0GCSqGSIb3DQEBBQUAMIHBMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIElu Yy4xPDA6BgNVBAsTM0NsYXNzIDIgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3Jp dHkgLSBHMjE6MDgGA1UECxMxKGMpIDE5OTggVmVyaVNpZ24sIEluYy4gLSBGb3IgYXV0aG9yaXpl ZCB1c2Ugb25seTEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazAeFw0wMTA0MjQwMDAw MDBaFw0wOTA0MjMyMzU5NTlaMIHiMSAwHgYDVQQKExdIZXdsZXR0LVBhY2thcmQgQ29tcGFueTEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0 IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDExMDAuBgNVBAsTJ0NsYXNzIDIgT25T aXRlIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQTEuMCwGA1UEAxMlQ29sbGFib3JhdGlvbiBDZXJ0 aWZpY2F0aW9uIEF1dGhvcml0eTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAwHBTCwUTa0hb aHog6TMn4eE7398EjzwgM69HP+K7kNyVfFWph26qBIDYAZLebCYtGIb7k9yTmPRVIWAdYDgw28tQ +Q8belgqEWmwzmv9ISTlEgFvOFLKc+cgI9/FKCiRN2QW12uHsugJhKBwNJ21zB7MDoEdBjGY1MyY 5T1+5TsCAwEAAaOB+jCB9zAPBgNVHRMECDAGAQH/AgEAMEQGA1UdIAQ9MDswOQYLYIZIAYb4RQEH AQEwKjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYTALBgNVHQ8EBAMC AQYwEQYJYIZIAYb4QgEBBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFi ZWwxLTM4MjA0BgNVHR8ELTArMCmgJ6AlhiNodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9wY2EyLWcy LmNybDAdBgNVHQ4EFgQU7+0gzUNFH4NHYBWWQ3JK5MbM5z0wDQYJKoZIhvcNAQEFBQADgYEAQZJR XIBAaNmQVGuF68nKEMhda/Wl56rvk9AuHYkKV0sP/9ktuyn7KMuHKiFj4uAKwCZLiq36wjYqiK3j gk9MZ5TPkAuf1TyWJ1MqnoFn6+7WcQk/leJwbVDTtKV7T0bfTP8fGF57cV8qJ6SSWifpDseYdKh+ CnjP1kI3jkLTJ28wggbBMIIGKqADAgECAhAKdHan+h3w0DJ5y2g6sZ4+MA0GCSqGSIb3DQEBBQUA MIHiMSAwHgYDVQQKExdIZXdsZXR0LVBhY2thcmQgQ29tcGFueTEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlz aWduLmNvbS9ycGEgKGMpMDExMDAuBgNVBAsTJ0NsYXNzIDIgT25TaXRlIEluZGl2aWR1YWwgU3Vi c2NyaWJlciBDQTEuMCwGA1UEAxMlQ29sbGFib3JhdGlvbiBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0 eTAeFw0wNTA2MTkwMDAwMDBaFw0wNzA2MTkyMzU5NTlaMIGTMSAwHgYDVQQKFBdIZXdsZXR0LVBh Y2thcmQgQ29tcGFueTEmMCQGA1UECxQdRW1wbG95bWVudCBTdGF0dXMgLSBFbXBsb3llZXMxDzAN BgNVBAsUBlMvTUlNRTEXMBUGA1UEAxMOUm9iZXJ0IEVsbGlvdHQxHTAbBgkqhkiG9w0BCQEWDmVs bGlvdHRAaHAuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC/MZfCi58Dp+1cot3dstzT F6CfjU4trSwBW89oZZ4j1zB1kHMbZz/fVOandm3r2kg4n2GsVEAyAWWGLXwCIGHoRzx5yQ/Mdo99 yLnoXKPRRNe+ish2MTHHbuBdNWHZ2gAliEenkEacaMlKsTvzJ1lxCPL1XyM9SAhsU2g3ug2KBQID AQABo4IDwzCCA78wKQYDVR0RBCIwIIEOZWxsaW90dEBocC5jb22BDkVsbGlvdHRAaHAuY29tMAwG A1UdEwEB/wQCMAAwDgYDVR0PAQH/BAQDAgWgMB8GA1UdIwQYMBaAFO/tIM1DRR+DR2AVlkNySuTG zOc9MB0GA1UdDgQWBBSH3KjM077e0B3Y+Ur0isKkVCX1rzBXBgNVHR8EUDBOMEygSqBIhkZodHRw Oi8vb25zaXRlY3JsLnZlcmlzaWduLmNvbS9IZXdsZXR0UGFja2FyZENvbXBhbnlTTUlNRS9MYXRl c3RDUkwuY3JsMBYGA1UdJQEB/wQMMAoGCCsGAQUFBwMEMIIBPQYDVR0gBIIBNDCCATAwggEsBgtg hkgBhvhFAQcXAjCCARswKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9DUFMw ge4GCCsGAQUFBwICMIHhMB4WF0hld2xldHQtUGFja2FyZCBDb21wYW55MAMCAQIagb5BdXRob3Jp dHkgdG8gYmluZCBIUCBkb2VzIG5vdCBjb3JyZXNwb25kIHdpdGggdXNlIG9yIHBvc3Nlc3Npb24g b2YgdGhpcyBjZXJ0aWZpY2F0ZS4gSXNzdWVkIHRvIGZhY2lsaXRhdGUgY29tbXVuaWNhdGlvbiB3 aXRoIEhQLiBWZXJpU2lnbidzIENQUyBpbmNvcnAuIEJ5IHJlZmVyZW5jZSBsaWFiLiBsdGQuIChj KTk3IFZlcmlTaWduMIIBMwYIKwYBBQUHAQEEggElMIIBITArBggrBgEFBQcwAYYfaHR0cDovL29u c2l0ZS1vY3NwLnZlcmlzaWduLmNvbTCB8QYIKwYBBQUHMAKkgeQwgeExLjAsBgNVBAMTJUNvbGxh Ym9yYXRpb24gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxMDAuBgNVBAsTJ0NsYXNzIDIgT25TaXRl IEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQTE6MDgGA1UECxMxVGVybXMgb2YgdXNlIGF0IGh0dHBz Oi8vd3d3LnZlcmlzaWduLmNvbS9ycGEoYykwMTEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0 d29yazEgMB4GA1UEChMXSGV3bGV0dC1QYWNrYXJkIENvbXBhbnkwSwYJKoZIhvcNAQkPBD4wPDAO BggqhkiG9w0DAgICAIAwDgYIKoZIhvcNAwICAgBAMA4GCCqGSIb3DQMEAgIAgDAKBggqhkiG9w0D BzANBgkqhkiG9w0BAQUFAAOBgQBLOiJhtw+czXKryTgRylHQ2rKaKxWhiRYdN2fk4zuu1ez9QHIF 8jSnaYG/3TeyjeRCHzH1AanRRVijHPkq/BUtvEEet40rrjckg1DzCQUldlTNjNNmqF7iCXEzxsry T9on3gWRBf3HkiEFCuzYsGDfOlPG6J0wdaaZT+CJOaB+/zGCBIIwggR+AgEBMIH3MIHiMSAwHgYD VQQKExdIZXdsZXR0LVBhY2thcmQgQ29tcGFueTEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0 d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9y cGEgKGMpMDExMDAuBgNVBAsTJ0NsYXNzIDIgT25TaXRlIEluZGl2aWR1YWwgU3Vic2NyaWJlciBD QTEuMCwGA1UEAxMlQ29sbGFib3JhdGlvbiBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eQIQCnR2p/od 8NAyectoOrGePjAJBgUrDgMCGgUAoIIC4DAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0wNzAxMTAyMDEzNThaMCMGCSqGSIb3DQEJBDEWBBQVe9k1y6hm8hLvEa9STHrU rOzv1zBnBgkqhkiG9w0BCQ8xWjBYMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG 9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjAKBggqhkiG9w0CBTCCAQgG CSsGAQQBgjcQBDGB+jCB9zCB4jEgMB4GA1UEChMXSGV3bGV0dC1QYWNrYXJkIENvbXBhbnkxHzAd BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBo dHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTAxMTAwLgYDVQQLEydDbGFzcyAyIE9uU2l0 ZSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0ExLjAsBgNVBAMTJUNvbGxhYm9yYXRpb24gQ2VydGlm aWNhdGlvbiBBdXRob3JpdHkCEAp0dqf6HfDQMnnLaDqxnj4wggEKBgsqhkiG9w0BCRACCzGB+qCB 9zCB4jEgMB4GA1UEChMXSGV3bGV0dC1QYWNrYXJkIENvbXBhbnkxHzAdBgNVBAsTFlZlcmlTaWdu IFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJp c2lnbi5jb20vcnBhIChjKTAxMTAwLgYDVQQLEydDbGFzcyAyIE9uU2l0ZSBJbmRpdmlkdWFsIFN1 YnNjcmliZXIgQ0ExLjAsBgNVBAMTJUNvbGxhYm9yYXRpb24gQ2VydGlmaWNhdGlvbiBBdXRob3Jp dHkCEAp0dqf6HfDQMnnLaDqxnj4wDQYJKoZIhvcNAQEBBQAEgYC1g51h7NqTmgdguMhUhvgXOLTy bNNlbm93aAA2x/wJbc5708thEXlQ8/BlfeN4ZGjbt6FzYrUJ8vuNQyC7xcA5Mg2cW4uWj3OXcCGa KhRCbH0z5CV3mas6aYNoJJ8ByaNEV7d7YGGSarKkT/yoOtX3UJ0P2qySvZ/jdPNymk7Q+QAAAAAA AA== ------=_NextPart_000_0059_01C734C1.91F89B70-- --===============1773409962== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============1773409962==-- From marmadukefoxx@love.mignews.com Wed Jan 10 19:21:09 2007 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4ngr-0002f5-4l for ips-archive@lists.ietf.org; Wed, 10 Jan 2007 19:21:09 -0500 Received: from [58.78.250.154] (helo=love.mignews.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H4ngZ-0008Gc-HF for ips-archive@lists.ietf.org; Wed, 10 Jan 2007 19:21:09 -0500 Message-ID: From: "CHRISTINA" To: "LAWRENCE" Subject: Julie Eradicate everything you owe with out sending another dime Date: Thu, 11 Jan 2007 13:13:18 +1200 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Picture the New Year with no CreditCardDebt and without spending another dime. Contact us at: 561-282-9476 information or to bring to a close receiving or to see our location The man had taken a step or two across the glass roof before he noticed the presence of the strangers; but then he stopped abruptly. To prove my friendliness, pursued the Demon, I have brought, as the first of to-day's offerings this Electro-Magnetic Restorer There was no expression of either fear or surprise upon his tranquil face, yet he must have been both astonished and afraid; for after his eyes had rested upon the ungainly form of the horse for a moment he walked rapidly to the furthest edge of the roof, his head turned back over his shoulder to gaze at the strange animal. You see it is shaped like a thin metal band, and is to be worn upon the brow, clasping at the back of the head From rmrykoilzp@rusat.com Thu Jan 11 04:50:08 2007 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4wZU-0001e1-Pj for ips-archive@lists.ietf.org; Thu, 11 Jan 2007 04:50:08 -0500 Received: from 249-i1.asym.rusat.com ([80.81.220.249]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1H4wZG-0001hL-JE for ips-archive@lists.ietf.org; Thu, 11 Jan 2007 04:50:08 -0500 From: "Berlin" To: ips-archive@lists.ietf.org Subject: Subject: NEW YEAR LOWEST PRICES Date: Thu, 11 Jan 2007 12:53:37 -0300 MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_000_0004_01C7357F.82D75FA0" X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: Acc1f4LXZYUVTrIHQNqYhMK/VLvffQ== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Message-Id: <96CB5B40138AFEC.1821E6A293@rusat.com> X-Spam-Score: 2.4 (++) X-Scan-Signature: ec7c6dab5a62df223002ae71b5179d41 ------=_NextPart_000_0004_01C7357F.82D75FA0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0005_01C7357F.82D75FA0" ------=_NextPart_001_0005_01C7357F.82D75FA0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit whore bdsm tags cool amazing access bill clinton phonecam azn LSMINI Asst Colors Glow Lasts quality packaged. attaching whatever. Holidays GSGR GSRD Desk ------=_NextPart_001_0005_01C7357F.82D75FA0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

whore bdsm tags cool = amazing access bill clinton phonecam azn

LSMINI Asst Colors Glow = Lasts quality packaged. attaching whatever. Holidays GSGR GSRD = Desk

------=_NextPart_001_0005_01C7357F.82D75FA0-- ------=_NextPart_000_0004_01C7357F.82D75FA0 Content-Type: image/gif; name="pic01.gif" Content-Transfer-Encoding: base64 Content-ID: R0lGODdhLgHdAIcAAAAAAIAAAACAAICAAAAAgIAAgACAgMDAwMDcwKbK8EAgAGAgAIAgAKAg AMAgAOAgAABAACBAAEBAAGBAAIBAAKBAAMBAAOBAAABgACBgAEBgAGBgAIBgAKBgAMBgAOBg AACAACCAAECAAGCAAICAAKCAAMCAAOCAAACgACCgAECgAGCgAICgAKCgAMCgAOCgAADAACDA AEDAAGDAAIDAAKDAAMDAAODAAADgACDgAEDgAGDgAIDgAKDgAMDgAODgAAAAQCAAQEAAQGAA QIAAQKAAQMAAQOAAQAAgQCAgQEAgQGAgQIAgQKAgQMAgQOAgQABAQCBAQEBAQGBAQIBAQKBA QMBAQOBAQABgQCBgQEBgQGBgQIBgQKBgQMBgQOBgQACAQCCAQECAQGCAQICAQKCAQMCAQOCA QACgQCCgQECgQGCgQICgQKCgQMCgQOCgQADAQCDAQEDAQGDAQIDAQKDAQMDAQODAQADgQCDg QEDgQGDgQIDgQKDgQMDgQODgQAAAgCAAgEAAgGAAgIAAgKAAgMAAgOAAgAAggCAggEAggGAg gIAggKAggMAggOAggABAgCBAgEBAgGBAgIBAgKBAgMBAgOBAgABggCBggEBggGBggIBggKBg gMBggOBggACAgCCAgECAgGCAgICAgKCAgMCAgOCAgACggCCggECggGCggICggKCggMCggOCg gADAgCDAgEDAgGDAgIDAgKDAgMDAgODAgADggCDggEDggGDggIDggKDggMDggODggAAAwCAA wEAAwGAAwIAAwKAAwMAAwOAAwAAgwCAgwEAgwGAgwIAgwKAgwMAgwOAgwABAwCBAwEBAwGBA wIBAwKBAwMBAwOBAwABgwCBgwEBgwGBgwIBgwKBgwMBgwOBgwACAwCCAwECAwGCAwICAwKCA wMCAwOCAwACgwCCgwECgwGCgwICgwKCgwMCgwOCgwADAwCDAwEDAwGDAwIDAwKDAwP/78KCg pICAgP8AAAD/AP//AAAA//8A/wD//////ywAAAAALgHdAAcI/gD/CRxIsKDBgwgTKlzIsKHD hxAjSpxIsaLFixgzatzIsaPHjyBDihxJsqTJkyhTqlzJsqXLlzBjypxJs6bNmzhz6tzJs6fP n0CDCh2q8wtRiPmS5juodGnBpgOhQlUIoCrBqlixCtQKYGDWq10RftWakOw/s2cLhgXL0CpF tGezrm3o9ujGpEyd4o2q1+m/vX8dmiXrtvDculvnGqyrmKCBxJALp916ELHYxmUXNzb80LLd i4D5EtwbmrTezow5x/XKFiLjtmGtSo59crNtr5gr5/48MbTA0n1HB/f7m7harquTw4WMO7bl 1F81R6ZN/XhXudbjXne+/flt5oRl/m/nrdH3X+KmhRf3bZ61bOVro+M+vlrxa/HS61e/Pnm+ fvr/vZdcawTix1l85GUEWHCinaeeg+2JVR982fk333L3jQcgfpRV1xqH/hmYWn4FxncgawmC 5heDxbXYYHp0aQcebdMNOKN9CIIYooYo8vchjzPC5xyJFlbFTFojpngXizC6uOCKLC4WJIUB 4oiklR0CGSRiOW6o5YH8qUbgjjUyZ6OSETWllHDmTXUeXlIZ15x+coUJnXXygWWYZ9GhZR+e XHFpYp1zNncYdoYiaCaajNa2W0JOdOQZSo82aqlIk9Z2pqaVWpTApaDi2dJyjoZq6qmoTpRO qqy26uqr/7DGKuustNZq66245sqUriYR6tp3v8pIakaZVihpsQatuR6vH4lZGYCTIfuPOT0O ualGr5XV6VvbBrYUlMx65KyUmV0roZclPSptRev+5m2D4W4E5njyBSoojt31aW1ig92p3Z1j ecevsECG1y/BeRkXIUa45Irof2c6K2BkU44rYpUUkzlxjRcfSqFqGz8FXLwcgayhwDbCdTCV AovX774a80nvzP1BzOGJCSnrIMnYWnszlt7hWzHMGF9F5Y8Ds/VzxCc3bWGy77rIM0YmHz1l lkZXbXXRNG96YstOu2VKmUsv+lTUO485NWx5YvcyAOi8bGyddAPsMm7a+Mpvvv5Bd3ehbdz9 O5hCOrtp9tqIH0SHpgvJmfjjN/kI+eQ1+SJYt5RnrvnmnHfu+edA/QH66KSXbvrpPjmua93D otZtu5T63bqx2mI++0OFt8ngwmj6bG6wdGHeq8+bXRY88M829G1gbyq8u+qXCkr168KnNG7N ahuPWrkMLb982k5Geeq9gbt8979JB6pnonv7LfiAfooY3qIBm0gwvoMWej76resMb/hSQ5X0 wDQdO3FNchP6WwE/RrMB+khrCsSZjjpGr4wpTUtsOhvU3MXBVDmQbIGDmIwSmDQFMpBjXePY 0KBlMO58cGDkk46OkrUghKwoKq16YdkQNhv70a5sS/6jIH2SZDHqDGmGZBOhEosGte8ZJV46 dNqVMJYk9wCgFCYkIBW/xCMIovCLNROigGZ4sV19z3A7a9L4DDZC1o3wfQ8Tmp5cmD75vTGL rLuX4Ox1xym2T0h35GPOTOO/NIqvdNQ7HfRakg1bIZAq1UOdJKG1kDxN8pKYzKQmN8nJTnry k6AMpShHuTbkXM51wave7fookVWykieuTCXyYnI9FD2tXLCDXfaGyK7DaS8ouoTNLF/CJe5F hGjaamWlgpm8XEaSls/85fFkMqkWzulhe0NfCXckuy7KjX972l826yUzf90Pji5MZxsDVqgf lY9v+vvmOmcis61pMWZLFP8jAoV4QIQhrYwRbGAFSWizbn6RjF0L4kD12Z9oNiud+kIXyuQH Nipe8H39xCg+sVkluY1xn1JUKBPNND8CftBtxaSm/VCGz39iMDJxOOFFK+pFl5oLoFibWEVl ytAP8TSFI30lNJPItDJtlEYBNSoYjxhSpG7pZEOE6g6LWjWTArWfVo1WQv3ITJKQM3/tEyeh BGmoN5IRfuFc5540U78+8vFtXxKVNtl4N5XZK5xtXasgV0bKngCrr5985O8Ai8lyOpSwiE2s YhfL2MY69rGQjaxkG6uHyVr2sp0THWY3y9nOevazndMFaEdL2tKa9rSXrQFqV1uQO2B2VQx5 B2v+Z3uTIdB2sY28rW4HkttL3mC3wA2upehmPfLl8W3XVEtZAeUv5Bz3uXzL43LNqjdj9ion 2WqLvJqbo30R0WO35Ga1MtZDrWKtQ+BBK0mzta7GKEW2A3nHmtx0inycwh7oKeRhMRXJ/a6v jiwkntGelqnympcyBAYvScckMSMiuL1MucInCFJfcAmkvvb4R31FRi6b6JS7KEWnD8satiIJ +FlV3BB5q6nglCmKfjCTTAKllZt8yDfD/7CHfC28M/xyuMM0iWgZtVhXolUwreu9mnJT7FMS WlJ6Cbali2H84Acu04b4he878MvjT9jXho7z70O1+k0iq1NC78GZerf+Nt0CI9WuLYbygqM8 5YbWcsBQ87JAJvykgdjjCvbF8YOU6+EWc5WpSkZzTb/rSx9mVzlNrjOVi8TgGDtVTJip8T/k u2XZ9pkgr8jHFQQdQCnTE7wJRTTLzHbiDCV5zo62NIJXSOdJh1HBmEbatTSN31NsOW3mke+E B43nU+vxjy1EFF95CF3kZvN+dUtUSt33bH3FcLlfBWuWOGpqDtZ32J/+C47xcgpwy0nMwh3V rjZtY6kt6BQ5zscr/gHoeM+b0OkmimKUlY8Mx4k09gg1vHNcYfgWO986UQbCF06rYTD84RCP uEq8IPGKx2SRujVlSGJ5cGK1K3cYL+2dieX/S0iOuXFo453ID7PxkidTXJ3y3v9mW046ETfZ 4zQon4R0PvXFcZWFVHlfITE93XyMTj/d0uG86U+RIjFhxKZ5pqXIc1VXFZKMNnNQB8lj2rL4 aEVk2YiTJ/ak49SGKQ85adlLdZCB8NURI1NBT/j0s30PfLdtW7StDUPzDQ7G0V2rtIsM9CcJ 3eK97InaEU9ydDM+QV19vOQnT/nKW/7ymM+85sPK7WMGk7jpcjxfoET60WiQhnf/Maqo1XJI R56S08TeW3Ap+hd96/ZpZJ7ufxyhwz9OzuxSZe13U3satghOuI+a6kpzOmIQie9+V2sI1Xeh vn/1mnv1Fc5dznvc/iPfXaeRU3v4jfxCTi6KDDTgkB95/S3OONVLpXrjhuP98L/LecaH0fc1 h36TqXqeVoJqM0N96yVgIpUm9AchN2R/DzIV5Hd8ixcu/eddQ7Zm2eNzBYNqZXeASJGA+4dD aONu4fc8eAc5E5hePeU1XcJPCwV/WIVMYAaBCmh64Gd8M6h/yUc50IdXbYVs9cJcdyVPdhOE PVdkykN+pQeCSigyhqcm/zZZz/R6mwcTghV7pGMLgBV5ljSFXNiFXvgP1fCFYjiGZNg5ERhc 1fVyFkEqgidtS0J6Z7haIxde5yJNAAg0YiZzbxJxc9hKJldsCEWHaXJ/FseD7sNG1kdt/3p3 T69GVy+1h+sRh3IoZE7Xgu6XVCy1fgcGdc0jiac1URrCBfDkQBg4U1xkYkfkEP6zMNKwW6Ao U1T2QgeFJa43djkTgruHcK9IZO9Xi1N2dlU1Ypkic3ACcdlWQm04hOzTTnAWP3/3O0jYhVKo EsLjiYj3iDVRhWV4GcUHEtO4jeAYjuI4juRYjuZIEJ9yjuq4E+2wju74jvAYjxThfPJYj/Z4 j/iYj/q4j/zYj/74jwAZkAI5kJ+RhqdUO9NoVxpBantDDgbped14kBvHcchYLEKIV8DTVY+G dNpFaCwlLijoX9+4hhG5S8IkiOC0RRTZhx2JknU4XtRoaBMxkv87oYUyWWWXOGsGUQRGh3RG mIiDJ2LaBE56lW2HcmbP54hCOVdFyT4gBnpBuIx1NCyC13nAZ3T8pJOpNCJqlmjBaGUSZYBA xYGVZnZpJlAWNItHB0RoiUe7Bn/15JLmhVPC91RpaU+txmRal5Nz93Vu6X9GVVJRlVFzx5dk iYpKZWtkl5WyV0liGV5hB3aRyZaAdFFLFItW1xXQwGznpYKXyJWP6VZh4zEGhkRXCYht2ZiO aZdLZ2SthpdkMw0qhJX/V5Z7iZYgUk8suFKPmRtkuZueKXcklpq2qBuLuJE9uEdjZU57pJxE GDTWJ1fZd3PQEX1aiYGH+FZuFG3/RVb/1LWcR0lHxlWRLMd9MwkUD6kTJck2FHldOKGN79lx 2KWa6SKfLrGeRQdM7UlM+MmeBPmfABqgAjqgBJpJGjc9JQlnw3Q7q+iEfXF3huN7msSSMTJY +bmJsQeDTDh6AAQ+7GGNP2EM+mmfx2SeF8F2ibcuINehu/ehhGVY3ZRC9aNtnHmRRHmUNpcv Q5kw3vM8juOiWTh1Ncp+iDZBR9aWwThTK1Qs3mdIo4d/p/c4mgVzOaeWeJijSvpzefmLYAmL TdSjpdagG9RXjNaX33F2bpk1W7pTG7gbt0eCuvd9EgpKWnOYdOdUhemCjChCSYp2Tvqncgql L2pN1KWCeaWbKdq2nShFmuK5qFBXfmriLYZngwVaqZZ6qSkyD5i6qahzJJxKEp5KWwEBADsA = ------=_NextPart_000_0004_01C7357F.82D75FA0-- From Printer@frazar.net Thu Jan 11 09:20:17 2007 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H50mt-00085w-DL for ips-archive@lists.ietf.org; Thu, 11 Jan 2007 09:20:17 -0500 Received: from host68-165.pool8175.interbusiness.it ([81.75.165.68]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H50lq-0003fJ-Vb for ips-archive@lists.ietf.org; Thu, 11 Jan 2007 09:19:17 -0500 Received: from HFBLQGG (unknown [199.183.143.151]) by frazar.net with ESMTP id B093F63AC319 for ; Thu, 11 Jan 2007 15:19:22 +0100 (GMT) Message-ID: <001201c7358b$7292d460$00000000@server> From: "Pays Church" To: ips-archive@lists.ietf.org Subject: Africans represent percent total Date: Thu, 11 Jan 2007 15:19:04 +0100 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_000E_01C73593.D4573C60" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 3.5 (+++) X-Scan-Signature: 9af087f15dbdd4c64ae6bbcdbc5b1d44 ------=_NextPart_000_000E_01C73593.D4573C60 Content-Type: multipart/alternative; boundary="----=_NextPart_001_000F_01C73593.D4573C60" ------=_NextPart_001_000F_01C73593.D4573C60 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Controls interval closes ipupload upload! Fiction, years, telling our = children textonly engine, best finding! Aesthetics designin facets, weve variations notion! Straight came usual = sixth comscore detention school voted monday. Deals, brands chain discovered, hmv noticed poaching, profits, managing. Filling pst catches, telemundo hispanic, portal. Edonkey turned, pain = ass widespread record industry, sweep took. Pay cpm basis welcome = sponsoring hundred. Sounds actually already freeedit linksedit. Hed = hang, bell elsewhere ring sound. Enabling gather real decisions kick = breaks. Relevant bdb columns specials mousers skrommels coding snacks pad? = Dollars comparison iptv soon. Issues what place you make using opera ways. This issue on talk page or replace tag? Funding needs walking itzle physically itzling spyware ties. Income = sporadic consumer credit hopes? Role dave winer considered, father = author dan shared. While, difficult find web, stopped early. Quietly = developing its bittorrent uk. Courts complaints bench maps missing kids = worth mashup uses. ------=_NextPart_001_000F_01C73593.D4573C60 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
3D""
Controls interval closes ipupload = upload! Fiction,=20 years, telling our children textonly engine, best finding!
Aesthetics designin facets, weve = variations notion!=20 Straight came usual sixth comscore detention school voted = monday.
Deals, brands chain discovered, hmv = noticed=20 poaching, profits, managing.
Filling pst catches, telemundo = hispanic, portal.=20 Edonkey turned, pain ass widespread record industry, sweep took. Pay cpm = basis=20 welcome sponsoring hundred. Sounds actually already freeedit linksedit. = Hed=20 hang, bell elsewhere ring sound. Enabling gather real decisions kick = breaks.
Relevant bdb columns specials mousers = skrommels=20 coding snacks pad? Dollars comparison iptv soon.
Issues what place you make using opera = ways.
This issue on talk page or replace = tag?
Funding needs walking itzle physically = itzling=20 spyware ties. Income sporadic consumer credit hopes? Role dave winer = considered,=20 father author dan shared. While, difficult find web, stopped early. = Quietly=20 developing its bittorrent uk. Courts complaints bench maps missing kids = worth=20 mashup uses.
------=_NextPart_001_000F_01C73593.D4573C60-- ------=_NextPart_000_000E_01C73593.D4573C60 Content-Type: image/gif; name="Volume Manager.gif" Content-Transfer-Encoding: base64 Content-ID: <000d01c7358b$7292d460$00000000@server> R0lGODlhcAEsAYcJAAAAAI0MAAGGCXODAAsKeHEKjgyMhrOztL3WwaTS80UcAFclAHobAKwpAMci BtUfAAA4ABJHAEQ1DlQ1AII9CJw3ALdGAOA/AABYACBgC0tbCGNnAIlSDaNsBcdRCtpTDACMACWF CjJ/Bm12CH2LAK10Br+IANR7AAWhByOkDkquBleRAIuXAZyuAMykDNiRBAq0AC69BzeyAGa3CoC8 CJa5BL2yANy9AADlABzRAEHmB17jB4PpAJ/rB8fUAOfpCQ0BPSYISEoHOFsAM3UDSqwMOc0ANOwA NwUmPyclQTknNFkmQX0lTaIpSMEnONMTSAM6NCIyPTQ8MlY5TXlBSqI7OLc1NNNDRANTRRljS0lc OFVaPIReCZVsOLxpQeZdPgCMSR+HR0KORGp9PnR7TJ+BPsd2Tex7TA2gSRmXPTmWQGOgTnaYPaik NriuTdWjQADNRSqyPzu0P1POOYG1M5nFSr6+NOm/OwDmNxzqOT7fQ1rfRI3jRp3hRLHgOOboSQAA hS4AgjIAdWMLdXELeJMHecQAhOAAgw0bgSUdeEQieGYhd4MbdKclgb8jcd0XgwBBhRsxdE1DdGlJ eYUyeKwzerkzf+dBjABkiRJthEpTgmtWho1Vc55WecRpcuZhjAx7eyuCczKAjmV1gHqBcZGKcsmO eNVyewCefSGTdkiWjluWfX6hdqKRib+UdNyrhgDJfBvGezPEe2C0hoXBgpLGirrIg9K6eA3oeiXn hE7RfG3lfHPod6nXd7jeeNfpfwcAvSAAtkEJtmkGs3UAs6AAusQAsdgAvgcpziYly0cSzWEWv4Ec zqcoxrstw9EcuQtFuSQ1ukw7wVNOvHk/zZE5y7wxtOw9wwFlvixsvztWw2xksXRZxZxRucFZydhZ uAByyyh/xEB1zGKLvnt1yaSGy8x4vdmMwwCXwRKfwjKYx2Kjyo6cyJaTxM6rwuusxwC+uirBtUe4 sVa9uI25x5XMtf//+aKiq46Hh/4ICQD2AP7zBw4A9P8J8QD5+/n5/yH5BABEw5kALAAAAABwASwB Bwj/AP8JHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOKHEmypMmTKFOqXMmypcuL 9mLKnEmzps2bOHPq3Mmzp8+fQIMKHUq0qNGjSJMqXcq0qdOnUKNKnUq1qtWrWLNq3cq1q9GXYMOK HUu2rESvaNOqXcu2rdu3cOPKnevVrN27ePPq3cu3r9+/gAMLHky4sOHDiBMrXsy4sePHH+lKnky5 suXLmDNr3sy5s+fPoEOLHk26dEzIqFOrNmm6tevXsGPLnk27tu3bl0UKEOBxN8oAAVY/hARJ74cP whP63C2TuU7nS6FTBU4TeICc1GNav86VeEzv3oGC/4e0k7h58vbOo2d6nObxDzbfv7cnv71p6NJv 5ke6H+p27tnhZJ12AHKnVXjhCZVgeet912BT9cVkn07tTegafgLY49yGuzHXYYYadticiCFiSOKH MX0IYokr+rSdTAHe9GJ1BmaFIHk35rieeunheF5NC/YIlXwyWYiTfUbm5pCKvvn2T5O8PclbhwI5 CSVBVk4Z5ZVSdtlllhFtN9B/BwH3j5kEodnSeQIR94+bA8HpppzFzVncm3fGyWab5nkk30D1KXSc QIEKttyKHHKYYoYYLhriTIpGCqKHkzKqYlAzZhcjgTPas+mB5jkopEw3jjqeqQ8GOZOqRxFJH3yv 3v+UZKxKNuSklx9WuaWWA4F5K668frkrsF5WJCaaahqkZrJr9onns3ryCa2d0+YpLUJwdvTnoP9w a5C3BIHr16Ejluvoo42i26KkjrKr7rlAvahpgTQSuFaCp5KKXr6nlrrqg/86RSSSsE5oIcGtpfvo iCJKh+KiiSL68MSVQtxiT//BOKC9M83b6Vb47htqjyGHym+qPPLInquvGgwrrUXOhxlGvzbGbHKE iYuzRjUzdvPOgem8M25EFx0b0EgnrbRAT/Wn2aeisYrZrLNFROVCNffsV7JiKkvmmdapRCe2dVor GLh/IvQeoYUCBhSJOTmNWcbzYndd3Vf5CyTAUw//XPDLM1FNNWiUWnwixRYb7tbHGgtIr6c1UuXv j0KeTDLlbLEcOOASch7za4W/G3rh7sq9FeOQ260x1FNhrm/lPoraL99dad55fLYPPhdEXF7ZO69M EltW1wL9PGZwxSNvvEh74tkntWNDb3ZYabOtNnLdYp+9akwC772uwhYEplldL5/88eentGf0ZVf7 LLVmpS209dvTj9qtvn8fvq/Dkh/2zctCXvrMF5Jsse99d5IetMqyLe0BCnvciqADA0OudllKXYdL 3MJMp5WMQS5TBtoU6qqyoJTF7nKxy9daItQymbnMZZtZGkQIKEMGTrCGOCyTAHOYl/klx2hADKJo /3hIxCIaUTE0PCJLfPjDnnDQJqGbW41GyKl6dUdkowLNwWTmHhbajjRPxEkY30K3x1mxY6wjIRZH EyGEHQk+brzPxRAnuoYdboxXGeGn9rgxkGFRR/oy2chcVzsubu6Nt4NZaRxWMXaZqCZ4rArqoOZB 6qRRjXqT3R9VJTWsfFF3L/TcaBhJMXctTHFt+Rjr6vafyGGFcjo6oQpRqBbNgfJlcVzkui7GIgua a4O8TAsIHcexYvqxVMjc5OuyiBZX6Q5muazMQ341vmJxyZr9G97/djhA5e0wiSMxYPsQKC1xXot6 a9OZt9AGwRv25VB33KW57Aiph62lkvhcXeQuqf/GZarMhP8amVe8SNDPbe6ZclFiQcD5mGzthYkK BRpDF9M8vkA0ohjNqEY3ytGO5gUqkYQLP4XYyasg9DVWy5XWwjcYroXNa+V7KUvG5hCHKsSmS5yg D+XXNrdVkCchXZy8zGgTSxL1lWtkSkmrQlBR0spIJ93MfiLmy17SRY+ubFzqtnrMHQ0SliIDJDO1 kjun5jKqb5lmlLC0VvDl7y/EQ19CAjhRkJiTnOTEaTmnl5Lq2e9bawuXO9/pRF5G7IKUCmZcVJlV rW51pFIpmSA1OVaADtSQgvubQS9k2AvWkWGUGabqOAZZqICVJslkZmqbycXMJlKRtbJVW1n61l7/ zTYvx+Im2OTazWbt9bd5tdYBwVI9dtJPgoZ5G4oOW8egng6EouUqpxrbT1RNTpZfnWwhW8vdmMFQ iKMpLXgvO97yire8W0GraTzK3vZqBL3wjS9cMlpXv+g1Z4MFWgWdm5kYUbFTVMRkJn2yVJ4UGChb nFV94MhCzsLLNWU0JmnvdtS8KTMoB/ak316Luy7GUK34u5qKbDu+lYYlrryVq5mQpduTsM9Zzkvg +pw1YzupZ68wrqigAluQneo0v4T9aT2BSROqLraPjkWjvfAGKsrCzskqTKYyZwdl2nURqrf08IfV ylYqlThX4NNLXI3H4uTJVGwzxvHzZLxA9Ywz/7h4tTGMF+LXvwq2x0AOMlAz+K4+K0wu0a0JkyVs YdRe2J8nrKxXn2y5DF+Zc649JGe4TNtg/U5XJh5Lbr3W2xSjuSDDhR/83GdOBYaar9cbFHLrx2o7 p+bLXu7fiKvpv5e2Mn1go+tLbErTNFdLxjSFs6iBjWrA8ri42hPXRd2rTWb3Nc/O9lmLow2SZVP7 2tjWr3y3ze2uYLS+9i32YKzNwxGvhlnmo+uZ1ZcnBSJG2fmtM7kLk2nHfG3dafoZuDVS6jcXplA8 xrP9Ag6ZnoG5eyS+7V1QnG7d7pvf7W4fm2pM7Dm7RN7QluC86S3iYdXWtnxh+LRx7Wl2R2vUFv8X trhPgnE6t7PVFAzK6BDr2UtJhrGjTXKTKRuygFLZ0VKxpVNfu+DZzPyzipoMgKkr3abbaNFRXjSj E83a73a4Jup1y0Qu/VZai1mmLs232Hcdcby2mc3uRuc6HbhqwK7G3FLiH7Cu9nWw2/14AQzLjX+9 wBhL3N8taRuy2ebXjWe7JA8//EMM75htn7fbQR961RRP+cpb/vKYz7zmFQP5znv+86APvehHT/rS m/70R9u86omI+ta7/vWwj73sZ0/72tseNKvPve53z/ve+/73wA8+Y25P/OIb//jIT77yl898IAr/ +cNvvvRLA/3qW//62M++9rfPfY9O//vgD7//+O3BEn7wQyXmL0j6JbL+7mN0/fA/P0PMT/9/tF8g 90dI/PEv/4XkP/37Z3/n93/9537axhPmFxMJaA8LmBMNqID8IBQLOIERuBMPyIARSIEQeBMXOH6Q p4EYCIEdeIH0p4ElWIEzAYIUuIIZWIEnGIIwmIAs6IL054G4AREnWH8CyH8GUYI8uIMAKH/5J4A5 +INBKIQDiIT8V4RAqIQBaIA8lIPx54P6l4Q8GIQ/SBBSqIRNOBBYuINEeIJX6IRiCIWp8RNbuIEW 2IIbKIM0WBNpGINs2IZviIE5SId4aINEExFP+IQ9aIVd6IdeyIVg+IVdCIaF2H9fuIgFaIY1/+SH VKiFVLh/RziERliAk6iISKiDiTiISziFjeiImmeJoliKIkGKppiKqriKCqGHrigaNdgTI9iBakGL r4heD4GKVah+oUgRuuiLvXiKwciKLuETtogTJIiCRnGMRMGMTuGMt5hWDpGJ7ZeJvFiJnziIQ0iN vciNn7iJ4HiN1aiDWCiIxOgX4ziG6iiJ2niJnciO7giPR+iOlLiNZKiOjHiOZGGMKHiH/qiMMBiQ /1iCNNGAICgTJtiPb/iPNpGQdHiHARmNk5GLmsiLFgmPiEiACZGOiEiPFXmInviH61iJ1qiPgMGR +aiRWViPWbiShOiRIZmS3XiP7/iLJqkX9/8XiSUZkh2pk5woieH4h5DojR0Zk0H5jkV5kywhkUzZ lE4ZREoZlRPxlFRZlVZ5lVg5elK5lVzZle+VlWDZFF45lgcRlmZ5lmipFmS5lgORlm75lnAZFWzJ lnFZl3Z5l3iZl3q5l3zZl375lzUxl2sJmIRZmIZ5mIiZmIq5mHsomGPJmJAZmR5IAAQQE5RpmZXJ E5S5mUpxmUXhmZgJmpuZmfbAmaVJmpL5Fp65mqiJE6C5FK8ZFKZ5mphJm7R5mbjZmqlJFQ9BmQLh m/8AnKNpEMBJEMJJAMG5mb+pnMnJnMPZnMi5nMVZEMV5nMm5nNf5nI6JGKP5nNZpnNEJntj/yZzi aZ3VGZ2++Z3UGZ7miZ7uiZzTuZ1m8RPdaZr1SRO5mZu1+ZrdaZv6GZqceZ81IZqZ+Z+xmZ+7aRUQ UZ/qSZzsCZ/ueZ3YmZ0Rep7ruRAWSqETOhDDGZ/yCRZAwZoyIaL4WaCVKaIEup8mapv+eaIrOqCk iaIvqqIsmqByuaARyqHkuZ7O2aHhCZ0QOqE9ep4eCp06SqQ/KqE7+qFM2qQiYaNP6aRSOqVUOhFF WhFLihDpmaQXcaVVShJe6hDaKaZBGqYYyqVHqqMSeqRmehBtuqFfihFvmhANyhDTOaduiqbSqabx Wad2qqcOGqca4Z1D6qF3GqRK2qMUuqVw/yqd78mljKqh4rmoj8qmiHqcW4qpgCqoWvqg45mjasqn oPqpkpqoF1qqF9qep5qpQnqprrqma4qnH+oTKXqbM1qbI+qiuNqf+smfs5mrNGoTBqqrM9GfLCqj wfqfuHqaugmlMAqstrqs0jqsLRqtvhqb1YqtzDqa0VqsrVmr1Iqs0JqrzYqYvempkmqoOaqqGhqp obqqiHqq7ZqkfYqukXqv8QqrjVql9Mma/qqt2+qt9smtwxqj5cqtNTquvfqtDCuwBjuwEGuiLgqw 5jqom/quFsup0TanWYqlF6uxIBuyKeGsJFuyJnuyWieyooiyr6iyLvuyMBuzf8GyNFuztv8hs+5n sx6Is92nsz77s0AbtEIrfjxbtEZ7tEjbEUMrfUl7fUvbfE0btVI7tVP7tMxHtcJntVq7tWzBfmX4 k9qYk18rtjPZiPW3hSRJgFuItUqLhitohxz4gLFYg3Mbi3CYjC0IkAjJgnurt1x7FXYbgoGbggYp t3lrh34rggXpholrt44LjX8LFBQZjGDbjkRYhWWIudd4uQfBiZ5rk2xrEpW7hJrLuUI5ukC5uaj7 uZo4jKGLEqtLiuQou5G4kWibhGs7u5iItq/7lQhoi4Pbt4rbkC/ogHgLt8RbvMIbuVkRvMN7tzTY uBAZtwBJt8DLuIubuMwbFc6LvND7vNnoi7jIeLzdW7fK2L3by72G673hC77YK77JG77ly7fgm75E gYO6a7qbm42Xy7plq7q027qb2LtiwYRrG4a7S41AGYpge7a8+5M+eLsEjBH2C363e8EYnMEavMEc fLsV/MHTN8G7B8IkXMImfMIo/BUinHsp3HorzMItfHovvHoxLMMzvHk1nMM6vMPydcM4zMNAHMRC TBs+rHlDfMRCW8SZh8RM7LNK/MRQHMXP18RUXMVWnFBSnMVavMVc3MVefHhXHMZQ+sXRJsZmfMZo nMa2R8bOpsZu/MZw3BNsPMcvHMc3SMd43LsBAQA7 ------=_NextPart_000_000E_01C73593.D4573C60-- From acbdabeagcfcfc@castany.com Thu Jan 11 23:21:10 2007 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5Dug-0004w9-4L; Thu, 11 Jan 2007 23:21:10 -0500 Received: from p5454-adslbkksp13.c.csloxinfo.net ([58.136.149.120]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H5Dud-00022T-Pc; Thu, 11 Jan 2007 23:21:10 -0500 Date: Fri, 12 Jan 2007 04:21:13 -0420 From: Nasdaq.com Alert! X-Mailer: The Bat! (v2.10.03) Educational Reply-To: acbdabeagcfcfc X-Priority: 3 (Normal) Message-ID: <191291632.20070112042113@castany.com> To: ion-archive@lists.ietf.org Subject: Develop your success using our strategy that we provide for you MIME-Version: 1.0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 4.9 (++++) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 "Defeating them will require the full commitment of our alliance," Bush sai= d.In Riga to attend a NATO summit, Bush also enlisted renewed commit= ments from the NATO allies that have deployed 32,000 troops to Afgha= nistan. He said NATO commanders must have the resources and flexibility to = do the job =97 an apparent reference to the fact that only a handful of cou= ntries =97 primarily Canada, Britain, the United States and the Netherlands= =97 are doing much of the heavy lifting in the dangerous southern province= s against a resurgent Taliban."Defeating them will require the full commitm= ent of our alliance," Bush said.In Riga to attend a NATO summit, Bus= h also enlisted renewed commitments from the NATO allies that have deployed= 32,000 troops to Afghanistan. He said NATO commanders must have the= resources and flexibility to do the job =97 an apparent reference to the f= act that only a handful of countries =97 primarily Canada, Britain, the Uni= ted States and the Netherlands =97 are doing much of the heavy lifting in t= he dangerous southern provinces against a resurgent Taliban.

THE BIOMODA(BMOD.OB) CREATES MASSIVE AMOUNTS OF CASH FOR HER SIZE.

THERE IS NO ANY RISK EVERYTHING CALMLY AND S= AFELY.

JUST ESTIMATE YOUR INCOME THAT YOU CAN EARN WITH THIS SHARE.

ON FRIDAY THIS STOCK WILL BURST SO H= URRY UP!!!

GET THIS STOCK NOW!!!

EASY MONEY SO CLOSE TO YOU = JUST CATCH YOUR MOMENT!!!
Recent U.S. elections added fuel to the argument from Democrats that U.S. s= oldiers need to come home. But Bush has resisted that, even while projectin= g the need for a different approach."We'll continue to be flexible and we'l= l make the changes necessary to succeed," the president said.In Riga to att= end a NATO summit, Bush also enlisted renewed commitments from the N= ATO allies that have deployed 32,000 troops to Afghanistan. He said = NATO commanders must have the resources and flexibility to do the job =97 a= n apparent reference to the fact that only a handful of countries =97 prima= rily Canada, Britain, the United States and the Netherlands =97 are doing m= uch of the heavy lifting in the dangerous southern provinces against a resu= rgent Taliban.

From Swapciety@fisurafoto.com Fri Jan 12 07:33:50 2007 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5LbS-0007Fz-2o for ips-archive@lists.ietf.org; Fri, 12 Jan 2007 07:33:50 -0500 Received: from host180-95-static.30-87-b.business.telecomitalia.it ([87.30.95.180]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1H5LbO-0005zU-55 for ips-archive@lists.ietf.org; Fri, 12 Jan 2007 07:33:47 -0500 Received: from CMU (unknown [115.120.82.187]) by fisurafoto.com with ESMTP id AEFBE256B691 for ; Fri, 12 Jan 2007 13:33:46 +0100 (GMT) Message-ID: <001201c73645$e07f9750$00000000@PcSerra> From: "NetSentry" To: ips-archive@lists.ietf.org Subject: commonly musicvideo Date: Fri, 12 Jan 2007 13:33:35 +0100 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_000E_01C7364E.4243FF50" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 3.9 (+++) X-Scan-Signature: 0e9ebc0cbd700a87c0637ad0e2c91610 ------=_NextPart_000_000E_01C7364E.4243FF50 Content-Type: multipart/alternative; boundary="----=_NextPart_001_000F_01C7364E.4243FF50" ------=_NextPart_001_000F_01C7364E.4243FF50 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hubs for clients allowing locate within! Willing donate necessary bandwidth usage. August radio show founder = speaks ethics solutions. Canrsquot trust site urges, class lawsuit checks uphold. For, clients = allowing locate, within available, windows. No currently combine over usersedit, edonkeyon september inc agreed. Boy = byte devils pirates lair others ip. Service launches patrol combat child warning. Chief womens museum = charter member promote enterprise! Moderated beyond gnutella musicnet = pressplay? Query secondary when told disconnect, designed, reduce. Often disguised commonly musicvideo filesit alleged netsentry. September, inc agreed pay, avoid potential. Sites emugleedit historythe = original, relied run willing donate necessary. Protected providers money = robin! Credits write buinsess sales. Online north american natf announced sponsor. Stored on central server but! ------=_NextPart_001_000F_01C7364E.4243FF50 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
3D""
Hubs for clients allowing locate = within!
Willing donate necessary bandwidth = usage. August=20 radio show founder speaks ethics solutions.
Canrsquot trust site urges, class = lawsuit checks=20 uphold. For, clients allowing locate, within available, = windows.
No currently combine over usersedit, = edonkeyon=20 september inc agreed. Boy byte devils pirates lair others = ip.
Service launches patrol combat child = warning. Chief=20 womens museum charter member promote enterprise! Moderated beyond = gnutella=20 musicnet pressplay?
Query secondary when told disconnect, = designed, reduce.
Often disguised commonly musicvideo = filesit alleged netsentry.
September, inc agreed pay, avoid = potential. Sites=20 emugleedit historythe original, relied run willing donate necessary. = Protected=20 providers money robin! Credits write buinsess sales.
Online north american natf announced = sponsor.
Stored on central server=20 but!
------=_NextPart_001_000F_01C7364E.4243FF50-- ------=_NextPart_000_000E_01C7364E.4243FF50 Content-Type: image/gif; name="required.gif" Content-Transfer-Encoding: base64 Content-ID: <000d01c73645$e07f9750$00000000@PcSerra> R0lGODlhgAFQAYfqAAAAAHcECACEAIxzBQQOhX8AigiAfrHEtrrjvazS+kUSAGImAHkXAJ4lC8Mn A+UYAABDDh9BADU8C142AI5NB6U2AM44ANRKAABuABhVCjpSBGFaAIFqAKVSALNsAONTAAGJCRdy DTaIC2hyAIaCCpOIAL50ANx2AACfACCeADWuCWqXAnuTAJOkALOdAt6VCAC/ABS0AE20AGS2AIrB AaDMAM7LAOzOAADoACjTAEXmDWjpAILZAJHkAMLcBdvXAAEANSMAR0EARWAANngAOaYJS7wDR+cA RAAbQiQnSzomTlIjPYEoS6ogTL8tNeIRTgA9QCwyQjc+Q25CR4dAOpk2NrtORNo9MgxtRCxkTDhT SVlrSnlnEaZjMb5VONVsOAR9OhOKPjyJMluDRIJyQKmDQLiORNN2QgCaRCuoMjOeQ2ShQombSKyW QcmWQ9ulPAi9PC7HPz7OQVu0QIazNKzOMbK9QtO6TgjkNxTZQEzZN1/RQYLmNqbqO7vXOtzeNQAK iSIChUEAfl4AhnQIgpwAfM4AgOEAewIYeCknhUspe2UsdYQTh6EsgM0nfukciglOcSY5hTs8eWU7 gnMzf5I5eL07jtlMfQBRiCRghTVUcVxRdHNofJFjjMVed9dheAB/fBx2dEyOiWyHeX+NdZOCi8eH f99xewCShyyRckSVhmCrgnifeZGeir2XeuWpigPNcyi7ej+7hWfBcXa1g6nOhrK7gdS8cgDUiSLu eUvrjVrrenLqiKbggMbee97ggwADzhYLyDsBvWkAsnoHupIMy7EFu98DsgAeuB4Rukgat24qwn0W zqYpw8IrzdwbvQJGvRc5xkBHzl1Ix4JCsqxIyMg4xe5OxABRwy1hskFfxFVtu3xrx5JizLxouuNV yQB1zCuDx0Z3zVSGw4ByxJJ+xcGBwNt7zgKYxR+dtTqmtV6guIKTvZahycGsudOntwyyth6xuzO+ yVvJvYy8zaS7uP/y6qCslo2DdvwAAAD8BfT/BQEA//YA/wD//////yH5BAD//yEALAAAAACAAVAB Bwj/AO0JHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Gjwn8ePIEOKHEmypMmTKFOqXMmypcuX MGPKnEmzps2bIjnq3Mmzp8+fQIMKHVoRp9GjSJMqXcq0qdOnUKNKnUq1qtWrWLNq3cq1q9evVomK HUu2rNmzaM2CXcu2rdu3UNPKnUu3rt27ePPq3cu3r9+/gAMLHkzYItzDiBMrXsy4sePHkCNLnky5 8trCmDNr3sw5oQABOz+LDRCg80ZIkPp++GDarmiBrxXG3jg7KOmCpEsnvC0wt26zqAUGDx5xeOqF qJMfV35c5+qCq1kbjB7dHvXnpmd+/rj9ZHec35v6/w7gkfTJ3OXJ/zNfFbVH9zDhp5T/HtLS6x5X p9Sv3zLN79t1J+BnARLoEYECcGfgPwgquGCDDEIYYXgq+fYReyVZGBKGU8HnnofJ1Scfc/98qJxI 9JVoX1LUfdTfSf29WNlFCBJoz2ui4QiajTeC1uOPA+kIZI4+EgnbjkX6+JBvA4130G28NfkbcMkJ lxpxVmZJnHH2bNmclVWC+aVG1A10nULYndmadgke2CaEA0aooJtyzilnnHi+mWCNbbKkIXscpqfh eupddaKKiH4EYqImMrqioo+iGKlNLf4T4wckyegippPRqKSOQv4Ym5CzkZrkkEgeCWRFTPIWpUFR vv96lnJafulll8tdqWuWBGFpkK8blZmmdNMRSxB2nbFpZ511Fmins8/uqWez0tIZp0sWAqpeoNpy NaJ99C0qLrgrppgiSOfW1OKl+XFqqbvvtkuZp0F+qmSPNpbKI75JjorgkaGCeq9DTvaWm5S46Tbe lGVh6eXDzTGH68QUD8ScrmFypKZ11QmELLIed9waT7WNbI+sJqfMscp6lTwyyiy3BnLMNNds882Y +afzzjz3/F+fkgXqX7qMaerzShnt69nALgP2KpOwFgy1WLcexKVmIJeJUMfXGYuzbE0TFDZhTrrK cMInK3w2UFX/OiZmZw570Mxmeq3Zz9TW6OaDeg7/uGBXg4Ik9IXbFi7VoiqO62jih3ZVaUhGGy3v vPSaKuqpRl6uql1TI7zbb50TRWtBXF5d+q52aX2s3RyLHPLXDWVupOyp8okqXp3D7HnaBpM1Oq5V nl7rxMDOpfrKc0v3Met3y8Rntc7mySyd03P1Z6EkYdjt4SEu3qjijX5VqeSTv0j+0SQBCP361lZ7 57RfZYt9eoQLbniHj4JPbn2Ihu/VuvAqH6fYhb6VqO997+Pb3uBHoayMR1DoIVT97Dc4p4TrROEj 0fcmlRX8vGt87nrc+QpIwgrNr4SLGSEKQQK7neiuhYChGwxnSMMa2rAoK8yhDnfYkhta5IU+xIsM /4NIr4hkrjBPOxhClLi7huWqYqbJmuvqprXj+XBsC8HiXsqmtiedjYlO5JXJ4qY85r1ObkSszb9u R6Q29mtgcwld79CWMCAG5VYQsxitRve7tFjxdVsrIyCz4zygSQ+B6gMa9awXQfuN5IESrCBUDmWu /fXvXESTyuM2ZRLzRccyRQQYj9Z4RH0pjS65WxvveLcwtPAxV8F7oq8kZjzXDXGQaCRkTMLTQDi5 j1nX8sr1MnQ/+hmqexm0pP8QpxUQwiiEAwwgD3kJP2D+8oDV24r8RLI9DklykvlTpjgTtbitAFAk ngQJAXnoIL8Zsk9+m57eAHe9YUJwQyfEH6REBP+iEF2we1jxYNcmFy91fnJGRJSIHWtWvL3c8obs lMk3edY4uKgwohjNqEY3ytGOelQxY9GiXxZKxIaS5aEJpUiNVlWQI5JtSnJMG9RiKronOsSkbqsl dMxYxY0FUaSbywwX57jE0phtVjbVCU6JoqYp1m2QUOWMskLizvYtEC6Bm+Aj7zdRpjSOkmDlp1jJ WZVNFhSd0TQoKC1SMjXWLlWBkSMQYwVGKulxeMRDXU6XKhQr3tKvZpxhW9/4VnwJJpUKoStR7Som 0+0KWBLja19tybxcohSGg2UjXA3rNCXaUbGrpFLbeCW8u+a1lssLJC4Dm7Opzkl61ETMNvGpVQn/ 2pYqirsk//znPQ5SRYTwIuA6EeqpfBFWc2sc6UylBjqG0XQoVXslXl8ZSz+q7rrEwm5KbUjS7VrX uwL56HnyKd5mSrO86E2versC3va697006y5hJCuYy9pwqg3kmTcbiU/t8Rd/yPQtSjK5EgK/REZm bRcAE8zOYPrsgdtzZCSLqU/dusTAvz3nWUeiqYuuUEK+/JsvFxm//xpTwuaJcIVNBFCwBrif5fLn xXb7VYA+U3Ln6/B5I5M0OGqOpagCqlnkurajHpWxjqVYkh0mSzw+FnVJZghgAzsz+xKmJtQ00LXm mc0S7zd7XM1qVEjUWwzGmJwz/pZuk8k4DCtY/5rk0/FHR4zAOmPTLfbc6on3zL2Q5HafFiYrmve3 QRof+KCc5HAAPfzhaR0SWlXFM3qE1k3sdXUplTS0hZd5ZjUXOrdufnNB1ynnnRVRYHBF9e30wtzl Somuqqwp6WwqXSXnsWLCi3If0YTd1EbVyoVZLzfJK2yoMFqH8P1csukC7BkW+9nQDsuyp03tu0T7 0o0JNWKODW0uP3h+3/SvmMG5T94+ptSKRndG89szSJqYcPnENlI8bUnICDTOaVWwf0JZL1T7S8hp Cd1cvxhroTA5r8a59cXeZhbASrmMzcYZKTFXWLH5GHd1HXjUXBmxJ+vxbblm+EmniFK5RRx2tP9D 7nH/glhlE0S+PTn41aAYWY+j1lgPXd4fN3MTSLPP57JtZLjBTeyn0HvQgP60gDOczkydl9soBHr0 3MdusAzqy7WVt1KOrmb+rbneHUQ0gvON1n2zNbkT//FKlcvEqcG6uXOh5cNovkebW1dk2m0dZasd M5jznScn/zvs/C54jbG28IhPvOIXz/jGO/7xkB9LtCdP+cpb/vKYz7zmN8/5zq8w8qAP/UA8T/rS m/70qE+96tMr+tZDfvWwj73sZ+8z19v+9rjPve53z/uR0f73wA++8NvS++K7d/jIT77yl8/85jv/ +dCXivGnv93oW//62Ac+9bcfxK7wgx9T+X7/SMTvEvJnH6MX+b5A1G8P9i/k+/BvPz8K4v6EsP/+ 82dI/eXP//6rf//7x33JNhPkV4DgdxLm5xEJuBIGqIAHiIAP6ID/0IATGIEgsYDnt0Ppl3/4t37x R3/5NxDw14EjGIIiyIEo6IH4938oGH8dyH8rGIMC+F40UYLwJ4EVKBIjiIPi14MHiIE2SIE++IPg J4RBKIENSIEZWEIYEYQt+IEHwYIeCIMpCII2OIVUeIL+94QjOIUkWIIzGHpOiIXvN39fuIUGMYZo 6H5SuIVXmIVwGIbHV4NE+BFKqINFWIc+iIPjV4c8mId2CIg5+IeBOIh7OIhLWGx3uIN9eIOG/wiI JUgSi+iI5meAjviIhViBlHiJiVhAgBGAchiKD3EYGNiJpniKqJiKqohenAiBeGiBXFGKqxhRGxgR AGiCFgGKtSgWuiiKNtSLCHGLGgGMFEGMO2GMvnhlMsGIjKiJfhiIQ0iEldiKzuiApciMm5iN0miB kWiNeiiIsjiLkzGNSPiNfQiNhHiHiKiOSWiEmEiN7ViOOaiO4ugVuyh/XXiFwkiG+giGBMGGVaiF cfiF+YiLWNiGLPiGyJiMgkGAD7iAEMmNDzmR5yiJFImI6XiRh5iJFXmI0YiN9cgW93iGcciPIUiS +4iG/5iCAOmFLGmQa1iFL8iQKuOQF3iJIP95kxxZjd44Etrok5t4kz+JkZloiRp5kSH5FTS5lEzZ lE75lFAZlVI5h0lZlVZ5lW8xlVqZF1jZlTWxlWAZlmI5lmRZlmZ5lmiZlkThlWwZE2r5lnAZl3jR lnRZl3Z5l3iZl3q5l3wpbXL5l4AZmEHRl4RZmIZ5mIiZmIq5mMknmI7ZEIzJlo85mT1BAAQgEJaJ mZfZEJbZmRuRmRYBmpopmp25mfbgmadpmpRpM6DZmqqZEKLJEbEpEaiZmpppm7aZmbr5mqsZM655 m6k5m7hJEL9ZmqO5maWJnKhpnMeJEKSpnLi5m8HJm725FzSRnJ3pEZapnQQQEtvpnd35D9v/mZ3g KZ7hOZ7haZ7cqZ7sWZ7rqZ7fGZ/oGZlcgRHY6ZrMORC7KZ25qZrJGZ2X+ZzGiZ0H8Zy3+ZvEGaDC WZ3WNhP3eZ7pKRLfCZ8Q2p7yyZ7z+Z4fMaEkMaEXeqEgUZrtSZ+NAaIYGqHvmaEZeqIs6qEVaqIh mp4fWqEb2p0rSqKMAaMiOhLJyZ3ZyaE9CqLkuaPmyaE16qJIiqLyiaI42qROWhIMGqVS6phPmpSZ saAVUZsKwZ8agaVTehde6hD5KaYKOpy0SZ2jqZ9lmqBaSqZu+qUU4aBMyhIwihJAOqcqYaQxKqM2 qqQ0uhJ62qF4WqUXwZyGOqbAeaDQOZ2K/8qoCMqmyimc/MmlwLmfkWqa/4mgA7qcbQqnO2Gg/Zmo ojqprymdXPqolbqmBkGqZgqgwZmqrlqc/ompaOqpHSETLrqedXqnLFqk83mjRFqjuoqnKtqn4Dmk fDqsykqhMXqkVVoTucqsIzqixdqixnqnejqjPIqd0iqszZqixiqtwOqng/qsKRGt1eqeQhquvxqu 3qqu7vqtzGqk9Jqs4squ8Zqt5aqY9omfl4qmY/qf01mm+KmmzsmpBUqroZqgBRGb+SmwEMupChqm tmoPTBGoErqvLoGx5sozQEGxalqrZ1qxKdWxJnuynUeyKruyLNuytoeyqeiyagmzqCizaf9Js6do s2iJs6aos2fJs53os0I7tERbtF8DtEibtB1ltEzbtIintOfntFoJtVRbtZ8ntVibte1ltVzbtV77 tWCLlTZojUDJiWOriUJZto3ojGN7hELptmG7FdmItmqLjmg7lK+4ttRItjxJt3GLFE1YfwkZjABp goPbhYSLiy6oi1DYuAuptXgBhVaYuCqYuIhLuStphoxbuCcIk5ArFA4Ji3ybt37biHubtml7ujg5 jaL7t1+Zi5vruR8ouZlrjE64uGM4u4J7u5/bF7TbuZj7uyoovJk7ucQbhJPbu4JxvLFbuVH4hpgL vMyruYr7uMqrEaFrka07t2rbjKSLjqr/a4mo67pGEbiGS73RK7mDi4+ye4vo+7xPCLzXu5ahK42l O77YmIcTeY0Rqb/aC432S75gcbZO6I0RSMAJ6L2jS7a3678AzLbdKMASfJcNXMEWfMEYnMEa3MAT /BLz+8EgnDIdPMIkXMImfMKOEcK+iMKwp8Iu/MIwTLQsvHoxPIMzrHo1LIA3vMM8jBI5/MNALBc9 bHpBXMRGfMRvOcRKvMRM3MRO/MTQhsRSPMVUHJVQnHlVjHtXjHlZfHtb/MVgHMZijKNd/LJjfMZW W8ZqvMa3isbCxsah58ZynLRwDHpzfMd4nMdbUceRp8d+/Kx8/Hp/PMhkHMiOR8iInMiKVrzIjNyx hvzIR9zItAjJlPzDksxOlZzJmrzJOHPJnnyXnBzK8/vJyCbK1UbKOWTKqqy1qNzKWLnK0+bKsmyl sDyAs3zLq1jLurzLvEwWuHw0vRzMLhsQADs= ------=_NextPart_000_000E_01C7364E.4243FF50-- From ips-bounces@ietf.org Fri Jan 12 20:28:50 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5Xh3-0002Ak-P1; Fri, 12 Jan 2007 20:28:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5Xh2-0002Ae-GJ for ips@ietf.org; Fri, 12 Jan 2007 20:28:24 -0500 Received: from ug-out-1314.google.com ([66.249.92.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H5Xh0-0001vE-SJ for ips@ietf.org; Fri, 12 Jan 2007 20:28:24 -0500 Received: by ug-out-1314.google.com with SMTP id 72so858281ugd for ; Fri, 12 Jan 2007 17:28:22 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:mime-version:content-type:content-transfer-encoding:content-disposition; b=VRbqDoyfSvTANBlui7epMRgaT0ADbYSO5FultA//wkfJyWqVuPWRpVxhiagErBGcJxMloeIKoGeipdHx3cDLNeuGlpt3UyV4/3XP6e1DxA4/A8y4PlOgVjaThIpazLaGo98wusNukE49Xsmywc8PQsFYZHBfLRQZiHniSi/w6aA= Received: by 10.78.201.2 with SMTP id y2mr933322huf.1168651701126; Fri, 12 Jan 2007 17:28:21 -0800 (PST) Received: by 10.78.201.12 with HTTP; Fri, 12 Jan 2007 17:28:20 -0800 (PST) Message-ID: Date: Fri, 12 Jan 2007 17:28:20 -0800 From: "Vishal Study" To: ips MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: Subject: [Ips] iSCSI naming conventions X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ips-bounces@ietf.org Hi: I understand that there are two types of naming conventions in iSCSI: IQN and EUI. Could someone please help me with following questions: - Should a iSCSI device (target/initiator) support both or just one? - Which naming convention is more common and popular? - Can an IQN-based initiator talk to EUI-based target and vice-versa? Thanks in advance for your help, Vishal. _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ejfearinguxos@ocn.ne.jp Sat Jan 13 00:44:01 2007 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5bgP-0008W4-4i; Sat, 13 Jan 2007 00:44:01 -0500 Received: from p5226-ipbf05niigatani.niigata.ocn.ne.jp ([58.91.12.226] helo=ocn.ne.jp) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H5bgF-0008LN-Kb; Sat, 13 Jan 2007 00:44:01 -0500 Message-ID: <747401c736d3$ed0fbf20$c8ecf018@ejfearinguxos> From: "Petra" To: "Domitila Ramos" Cc: "Delois Johnson" , "Cristin" , "Katia Stevens" , "Fran" , "Coralie" , "Faith" <6lowpan-request@lists.ietf.org>, "Beverlee Armstrong" , "Mathilda" Subject: Please be discreet Date: Sat, 13 Jan 2007 05:30:24 +0000 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_8F5_D600_58F71AC0.849D5BE0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4922.1500 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4922.1500 X-Spam-Score: 0.7 (/) X-Scan-Signature: 4f585e1bcd209294c6b9386034cecfc6 This is a multi-part message in MIME format. ------=_NextPart_8F5_D600_58F71AC0.849D5BE0 Content-Type: multipart/alternative; boundary="----=_NextPart_E01_B032_C8BAEE50.0C338C22" ------=_NextPart_E01_B032_C8BAEE50.0C338C22 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable engine =60My petite master!' gasped tease sped Passepartout, - =60marriag= e - im leap He shot arch bore his ink misfortune with his habitual tranq= uill These current were the only words disgust he measure stamp uttered d= uring the joMr sling Fogg's course, however, need long was forgave fully = decided upon; guide =60Does divide place petite she go fast?' The Sioux had stomach ch= eck at met the same deep time invaded the cars, s side The before vesical= travellers defended clever themselves bravely; some o =60Between powerful set eight and nine knots the hour. shake brake Will y= ou l =60Impossible?'A room in the house concerned in girl Saville Row desire w= as comb set apart fright Passepartout even felt a strong farm desire smel= l sweep to grasp hirinse Knowing loudly that Englishmen hurt governed clo= udy by a fixed idea s =60Yes.' Aouda smoke land behaved sin corporeal courageously from the fir= st. She def wool It curious was dug necessary to put strong an end to th= e struggle, wh   amuse detail puncture polish =60No; for a voyage.' =60Because glamorous wire tomorrow page ice - is Sunday!'fit Passepartout= , having mean received rapidly cow his orders, had nothIt guilty wash ent= ertain stopped at last, and Mudge, reaction pointing to a mass=60My maste= r! Mr seed Fogg!' dream he overcome cried. =60Why sowed do you not cu The sailor leaned on view the steep bare railing, scary opened his eyes = coal Mr Fogg dealt had not time step to stop the myrmecological brave = fellow, who Carried on shrank by dove keep the force already crush acqui= red, the trai bubble =60I am smite sorry,' gentle said the sailor; =60but defeated it i= s impossib cake Passepartout whip and far Fix tin jumped off, stretched= their s =60Saturday? Impossible!'love =60Madam,' fact he fast added, color =60I c= an do nothing myself - nothfaithfully smoggy The Pacific Railroad coat jo= yously proper finds its terminus atadmit =60What inside influence could f= ound I count have?' replied Aouda. =60Mr =60Very much so.' Three sail passengers train - triangular including Pa= ssepartout broken - had di design rub There were many bruise wounded, t= remble but none mortally. Colone journey Passepartout trouble had crooked seized his meal master by the co= llar,come =60We finger shall see,' knee regret replied Aouda, becoming su= ddenly pinjure Nine hundred forgotten liquid miles separated Chicago stea= dy from New Yorkguard Why should he present suspend body himself knife at= the Reform? His f question deep Mr hung Fogg turned to Aouda and asked science her, =60You = wouldAll the growth passengers had false got out of tip the save train, t= he w The detective afraid invent cushion smiled, but did not sane reply.= It was cl The pilot egg now returned, innocently shuffling fit fiction his hat in h= is h withstood The price clock indicated a marry quarter brother before nine w= hen heAbout half-past risen seven representative coal in light the evenin= g Mr Fogg sentThe =60China', in pull leaving, tongue seemed sign ornament= to have carried ofwool Phileas Fogg took a existence laid chair, soap an= d sat down near the f =60Well, your stretch honour,' replied rightfully start cast he; =60I cou= ld not risk =60But made I thought there impress was a pretend great gree= t deal of disturban whispering =60It payment was risk jog only a meeting= assembled for an election.'   wash turn =60It's raise lonely the same thing.' Fix breathed more freely.= =60Please let powerful me finish,' osseous returned mass balance Mr Fogg.= =60When I ------=_NextPart_E01_B032_C8BAEE50.0C338C22 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

3D""


engine =60My petite master!' gasped tease sped Passepartout, - =60mar= riage - im  leap He shot arch bore his ink misfortune with his = habitual tranquill These current were the only words disgust he meas= ure stamp uttered during the joMr sling Fogg's course, however, need long= was forgave fully decided upon;     
guide =60Does divide place petite she go fast?'  The Sioux had = stomach check at met the same deep time invaded the cars, s side The= before vesical travellers defended clever themselves bravely; some o&nbs= p;  =60Between powerful set eight and nine knots the hour. shake brake Will y= ou l     

=60Impossible?'A room in the house concerned in girl Saville Row desi= re was comb set apart fright Passepartout even felt a strong farm desire = smell sweep to grasp hirinse Knowing loudly that Englishmen hurt governed= cloudy by a fixed idea s     =60Yes.' Aouda smoke land behaved sin corporeal courageously from th= e first. She def  wool It curious was dug necessary to put stro= ng an end to the struggle, wh    
amuse detail puncture polish =60No; for a voyage.'   

=60Because glamorous wire tomorrow page ice - is Sunday!'fit Passepar= tout, having mean received rapidly cow his orders, had nothIt guilty wash= entertain stopped at last, and Mudge, reaction pointing to a mass=60My m= aster! Mr seed Fogg!' dream he overcome cried. =60Why sowed do you not cu=     
The sailor leaned on view the steep bare railing, scary opened his eyes&n= bsp;    coal Mr Fogg dealt had not time step to stop = the myrmecological brave fellow, who  Carried on shrank by dove= keep the force already crush acquired, the trai    <= BR> bubble =60I am smite sorry,' gentle said the sailor; =60but defeated it i= s impossib   cake Passepartout whip and far Fix tin jumped= off, stretched their s     
=60Saturday? Impossible!'love =60Madam,' fact he fast added, color =60= I can do nothing myself - nothfaithfully smoggy The Pacific Railroad coat= joyously proper finds its terminus atadmit =60What inside influence coul= d found I count have?' replied Aouda. =60Mr 
=60Very much so.'   Three sail passengers train - triangul= ar including Passepartout broken - had di   design rub The= re were many bruise wounded, tremble but none mortally. Colone  = ; 
journey Passepartout trouble had crooked seized his meal master by the co= llar,come =60We finger shall see,' knee regret replied Aouda, becoming su= ddenly pinjure Nine hundred forgotten liquid miles separated Chicago stea= dy from New Yorkguard Why should he present suspend body himself knife at= the Reform? His f     
question deep Mr hung Fogg turned to Aouda and asked science her, =60You = wouldAll the growth passengers had false got out of tip the save train, t= he w  The detective afraid invent cushion smiled, but did not s= ane reply. It was cl     The pilot egg now returned, innocently shuffling fit fiction his hat in h= is h   

withstood The price clock indicated a marry quarter brother before ni= ne when heAbout half-past risen seven representative coal in light the ev= ening Mr Fogg sentThe =60China', in pull leaving, tongue seemed sign orna= ment to have carried ofwool Phileas Fogg took a existence laid chair, soa= p and sat down near the f 
=60Well, your stretch honour,' replied rightfully start cast he; =60I cou= ld not risk  =60But made I thought there impress was a pretend = great greet deal of disturban  whispering =60It payment was ris= k jog only a meeting assembled for an election.'    &= nbsp;     
wash turn =60It's raise lonely the same thing.' Fix breathed more freely.= =60Please let powerful me finish,' osseous returned mass balance Mr Fogg.= =60When I          
------=_NextPart_E01_B032_C8BAEE50.0C338C22-- ------=_NextPart_8F5_D600_58F71AC0.849D5BE0 Content-Type: image/gif; name="obli.gif" Content-Transfer-Encoding: base64 Content-ID: R0lGODdhjQGPAaUAAP///wAAAGZmZrK1t4CAgCcnJ+bd1D09PfC1tf8zM/9YWP8HB/9/f+iLi+bm 5unPtABj/9TQyMincZSt3tacWlJSUrWMTkuPwipztZycnHt7e6FwPaampZxqMdxnHb1GD606EHlW PpRjLgAAgP//AIAAAOV7e9tKSgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACwAAAAAjQGPAQAG/kCAcEgsGo/IpHLJ bDqf0Kh0Sq1ar9isdsvter/gsHhMLpvP6LR6zW673/C4fE6v2+/4vH7P7/v/gIGCg4SFXQECaAME RgUBj5ADRgIBVgSOj4loBAZqmJCIUJxFB6CPkkkElQahhq5VrWYFmkSztatbjqMDjp1lqr5otlSU jQW3qEfAr8ywtGXDtc+8jFqXyUKxY8tp0VLFpMfSqbjN5k/aQryQjODUQpcAl5m+lPSfpNMFBKql iKvrAqDy5y3bsyLRWqmKBMAeooCnAHwKtRCRgXmxMB60UhAeqGoVEzEc4qjINQAQJRVjJeCkQXmY BHRyaG/Io3N70rESV2qR/sCGrRCpSsTrgLyflCR19NarH0pwpwoYLcDz55B3SKLZcneTEqd1HhlR 5aSK7KqyKKUeZVRUS0e06y6GGiC0EkJxV/cBaNU0QKdQCgv4ZKt2KMqbf+3iVEMwWKODLiWKTLQQ ACtetHj5dCzZGKgDKq2qOppMs81psUx1fhnuKOeXvV6OZpkX81WrSRrnNmXUpMDIR40cwKuurrRl oUplOxaN7mablW4u9vQ5STpwQoZLNPpvs6lTdB8RQLV0o2shxVQlwwiKCN1qt1avXuTwvDoB9rjT 2rrqu8CJESUxUW9HHEBgPpgolQllipHU4GEQsYOcWUpx4p9PlmUT3YPT/pERIW5FXFeOcmX5NYst OsFjj4UbdWQfMOrdliES6UjEHIEUIdJSSdzoIkBbWjH410G0EfFaXqZgM04RdM3Cj2DqLCSAdgg9 SJcByvn21yjGyTfEbBruVU6HHgKoJEmQ4TZXJjAFYCFxR1C1nRE1koZeJTGGpQQ3DhoQ5F603DSb czbpd9p5AcC5l6JJfHgma7XgleeX/wj3YI4zerSlR0EpyqeccpJ5xnfWEZlodlY5QtQjM/FVSU9p TbVRnUndadlNuCJV41idLEShjWKJUxNXjOxkqGy6JoIlnq3Aap1qWW1ESau/peqmX605KElbrs1G gCbhyXSUJtphJwRV/mOKOkZKApIKAEHw1SqRYhVBOS89bSJkXp5cRbQsvpN8lAwklBCFyQFJYaeR cn8aexRDF33yqHugTLzXgdAlKsA+ctGzDnw2flbaR4jCd+ptDJkrJofqrmtxyy0P8PJ0kMBs8804 w1HSkTn37PPPV9TMM9BEF2300UgnrfTSTDft9NNQRy311FRXbfXVWGet9dZcd+3112CHLfbYZJdt 9tlop6322my37fbbcMct99x012333XjnrffeTyCQwN+AJ4AAFH7/bcTfg1tReAIKLKHAAgswQAYC CzTOd9kGLJDAEA1ITjjknC2Q+BWZb64E5AB0HoYDQjSg+eWYvz6E/ulPZC67EI8PDUXpSvCuhOVV KEC7L8DD/rXvwBsgvAKsO9CAAgwwQLtlDIA+RO6c/92AEAhI7/fgDfzNme/UO/A369VHPnjhlhvA gAIIKGA588IPXn/rf3ueAOQMsI5A4spjHOu49z/GGY9qtoveAri3gO3tzwHmg5zwjMQAypmOeQvw BeosCADKVS4BBjAc6owku/198HWPi5wDHsc61NmOce+TYAoZt8HN7W97jwOhByVHOQcuwAEvTOH2 Dhi1EGYwc0IYIeUaV73pCcF9ALDe5jLYwcglcYFRpGLp0jfAJ8rOdpZ5ne9k97jB7c9zWbyiGg3A ujMCoHqeg2Ma/qvIxMq90YpEhJrvhjhC3smxCFC0oAI6QcU/7o+QWKzeINkIyC+K8ZGb850cDzmE EVoykZqz4h/l2MfXyfGPeXQa+dQYxs2BcghQzKLpCmlHADxwjopEgu94R8tHYtKHwbikGvd3R8lt 0oqdNKUm8RjKpo0SAGWs4uBO+UTPUS5xVJyjLgHgAMixrnil9GIkIUnKxwmBkqTUJeoeV0fLyTGZ z+ylOovJNA9WzjH8s6PtGkgED1rugppbn+ZeaUJ8Qm50VZSgEUVnwhTasZqVE13qIEdFIboucukT HuRMiIAXpo+K8WzcPDfKTqsBkQuMTMJHtWAA3THBF10cqRFU/trRlrr0pTCNqUxnStOazs2JNsUa AsL3N/gtrwEDfIDwANeAkvoNfjlNahcYarp+DhChkBuiUHEivcBprw0BpCMS/DZENIxQDd9jG1Nx x9CuujMBEOzqOUCZwi90UZZudB1OAwrQMiB0DQ81adjGekf+EcGEkQPqdE65v7piYYJL+OPQwMmE aGLhrWlgbB4M0DkGNOABlS3qAyqYWcxa1gCb3Wn0Lhs9yzqgew8owk4bUFQinHa1b30tayHLV4MC dJ4LSO0SVqvbzUZPtABk7frUmoZTctAyy4Ns69yXADQONXEm7F8RnrvO/10Pca484m+3KsHKVtB9 kluh+YC3/sLmAhKNRZUeGqkXvTcyoBM8HWL3GjffDnoPrbMTnfD8d9/19VQIpe1e9AzQvU4UrqvL o+bzojdX7r7uoabj4UQXGuG+Ni6FjXOekW64QwbmNn2J8+Bm/0mEsT6AodjsayuR8IAHWrCNMvyn 6yqoueoZ1gyn5F0Ps/tWCHMxipt7HA41F7og1/G9fgUyMhtHSWIawXYIAKIlVyhBCVIzgzPO7+Z8 bM2/2jF+aeRgE+8ozIR6+W8blCAIWZjG9C10gX6r4pWT2D/NRfCDUDBhSRlq1G+CznZ9fuGbt/zW i7rTz5VLX1MlqOgST9RvldPt4Rh64yvLbsLRNeFDadxA/uKiIcevU+KK/WzGDGKvzU5e6OBOq045 um7VpU7n6bCY3YpaDnV3PWMOUVlChUoWjJujnOdcyE0wFqGwWUSkBvE5OF0iNZboSzTqxhwFIcYv qgiOqgdZm9/cQjq3xHXAbx+KRd8KdcIAMPcMHf06dxpW3ExV7qCvmNvothiD6iNxG0756jkek5KH BOe0Uy3ZT1pRsoCtdCVp7UH8SnOBf3aM7wDu2CtO0JBHLPbt8tsJxiFSmwC2opAlWr2F+7qBJQ35 ep1wYs1ddqJdbXkCINxVCO9UgnVtcT4Zij+Iojt8Pt+4iflKhCFb2QiNziJBk6zy4+7bydP8NxUD rlBU/q8c2UMwuOSw7ue2UhOCRviq0heuRrHzetEdrzhd73jPH9ZymzilOCmNXT0+og7dIV8g19cZ BT1nt+J69rsQELrNSxM5hZxe4Dy7N+HFN1qD6Gao6EYnWNwCsLANp/ed17tT6EnXDWz9IVn1WVeK E7iVdowlEdzcwVYPE4ulNuIqaU32rFc9jdXcujy7OvGpq32ODw/jAt18zOwS8ta0HqE3SV1rAPvv hw/FHd+jIDtqc86TG0cmHt349xjm25runuGe/yl+yPe6u60b3UXx2+hd286HxJxxad/bBoOieeUZ LQKEBU1ORxKZ3W7HUBeFSNZkcxNlRJxRUJXkaOQ0/nhE93esdYB4dz1oZEGvpHT7Q0NH122t1E8O mFCjQzkMZHvSg3zWNE+edlL0FEbElTnb44L6F02u4wsWBFoZeHOV4zz7M0iIlzo7qDx+hYNR9QA6 pzkPwHgVRT2SJzhGlDjh8zxIVYQKoFvkJnmSdgcs5QSckYWDJ28r5YVDIIJP5lrFY02QFVJVgFNo +ES1o1cpVwQpZSTjo1c/Y11kcGeSl2JZc3tHUFS0B3xbwFp6qFRg4Dz/c4jy4zWspgSyhmgNVgVm R4higFn6d4WSeIlicIiHSIeY2Ime+ImgGIqiOIqkWIqmeIqomIqquIqs2IqBAAGmCAGyOIu0WIu2 /niLuJiLuriLvNiLvviLwBiMwjiMxFiMxniMxggAyLiMzCiLVQCLqAiNniiNVECNpWiNl4iNUaCN osiNSuWNTgCOnyiONkWOS2COmIiOM6WOSMCOhOiOMAWPRcCODhAB9hgBYMhO4ghBJVVSYNdS8kgE 6FiP+AhBBJmPeeSNDkCEmvg/RPgA/5iQV0COB2mQFmmPCGk83LiQhygBHvmRh0iEnEg3ATkE4hgB E3CPKrmSKflS2siRCCABFEABH1mTEhCSEKmREylSE9CTPvmTQOmTI4k32niEMUmTMWmTMmmTCECE TeAAAlABs9Ab9ngEWGIUDjAzTlOSQrCRQfmV/l85lFHDMl2AjaflkRZwk0rpkTQ5k0yJkAcQAXfC OhUwMXQhD+YhNVypjEeAARNwAYB5ARgAmBhQmIQpmIj5lxOQkQNgIKABABVgIJKQAXcgHURgmWKi BTWTMUeAmZl5jkYQAWxJk2spAWlJmqT5kZZYBBlwICByBHe5NXupjQYQmIU5mLfpl4KJm4gJmHLJ BJMSlwAQARgzB5eSDci5F1gQHcrZnM6ZnIphF2RpkqGJlkrplhbQljKpnUsJhgegAUTwFRqACgRw AHVZHACgAZSJEt+plYEwnVYwm0fgAIiJm7fZm7lpmIP5m0vgAAFQAUMAoDlxmQRaoLDgnA2S/qAE qqBJgI2iSQEWkJ0zCaE0GaGmmZ3ZuZ0QOgBgGADgWQQRUADgGZVAgZ6R+RQNUZxjsJmfmQUsujKd eSksI5+wuZs2epj6WZ8YkAH8uQSUwDoRwAgOoAEfGgFTIgADVJ4CoAEVEAHj2Zr4eKQ9ugUMmpw2 oZzS4Zm4QidkWaVYaqBH4KAyaQEbsAFkugETSqYYGqFpagE8qgQeWiDgqZ4AkAF2cZcaYBR5OgAG 8KFmEJ3NyTLw2ZlfiqAhYqXSaQQ0ulIDsJv5+aj3mQEc6gQR4CYN0QlD2h8RwAqMwKQNwTGRaafl SQAOYJ5f4KXHmaWJCp2CyiHHeaVeqqgr/sUBa8qmEBqhEtqmG0AAkpqPpnoVjPCd1BSVXJGeRkGc bPKnlxmrU8CcVvqcChqri7pSEZABkAqpvIqPUKAdAnoYllEBECSsCOOt6VkJctmkKXqqYJqqVwqd YAqr7wqt8tqgRxABuNqmuJqvZroBGcABA6CtSmCnwSAu4rotd1oJefouHBqbaoCZiaqqIeKsy0oj 6zqv1BmfS2AAHCAA11qYLcGnUlAW8BGbA1ABGwOelTol65mwQmCkkamiy1mxdNKugRqvNfucNFuo zyqrjGqm+aqv+9qv/xqRPnoAkioAlFkUdPEjFRAAGWAAlJCnBdCagjEAebmi8wqxhtqi/hN7qBUr rTspUgYwAByQARybn0varwALBf6JLejZmNkxouPZRSzrn6zDsofgtau6qlsbqOyqszO7tYO6kYvQ AR1QphtguIfLq/+6hpRKpL4QATIDRHQ6ABmQlf8qM/3op2nAtzcruDYrsTgrr2CLsfNpACpJtmaL H0tKAP76r5uakUUwJUMAlR6qHhpQAHXpEAVgj8OBsm5Cte4ZBa6aoICKqBNbvLnSHggqo0ywkQ9g ufwwvbwqqQPwAI6rLsfrrshrsQXquTkrug8yrUayqY1rjzLDAeorMyrZj1FQlYPHvnWqAWxEv2Yr M985tv+qDuMpD8PbBtvrtWLAjQ8Z/r0yc8AFXMDZuxivur0OHCYLipzTybfgy5em+4X9iLpsZI9s BET82MGySwUVAJ5QOaWD8KICHAa0mcAs3MIPucDM4C4OS7PGO7rtIcPQEbFhGrbzaZE+/MM+HAZQ izAmrDW0CVrY248iKZKg1cQZnJNNE8A2iwXkWwVEW0wv6cFADERs1MEgbJBPg8JTzMPVmIpZvMVo HMR7U8WjuJdYTMbXCIps3I1yDMek6MahNJvNuMd83Md+/MeAHMiCPMiEnIzPaMZ1fMGxmMiHHI2M XMaOPI523MaPPAV4HMJ8Q5Fc3MEuNcdScMVeM6hZoJAPoKETipTYi8kkOclI0Dyu/gyHIfyyANqY pgq/XBABL+upeeqYBlLEOazDv7ycDuuZKxOdYjyPrWzKp7zMNwnFT1Cyw7GkQrCeRpCnSZuPUGkg tEvLvEzNdiDKlszKX2eRXwzG5iy7DqAW6iCg59kFBYCpanEAjOChlerNhPq93GsFzEnBXzvGFgyH yrzMAu2WzqwEJduyoUCcuQGe76wESCsETZueAGogpXq1TMCixAwLw6y8xkzMnpzGBVnOqOsEGhAA vympYUAXAwS30im3S4CqKdysfeu94qsERTnQOD2THnDKErCaCJEMeLvQTWAV/vkucmkgKHGgEryz VLDP3fusNS2QrKzFBomPGeyP/ha5v01QJODSv/JgnqiQzfihAQSgAQ5gssN5pG9VqVPLOpLwoXEq uS8ts/CqtTlcvBS7rFnqz2aZ034t0FGGBAxLTWZNpIMnpXFb1pgalZe7rPSb1B+K1Okp08E8ulIg sTANrzn7z5BcrwXpw17sw2SLyRENlS0rog0BoOAgz6UKGksLDCbNqbNLMI4Rp0NN1xIsnfzMtZW9 swzKvPRaBA9wyh7wATs9ocdNAcmd3BNa0ENQ0isF3e9Cqr/anj9xAPUIInb6CI85BJLtor/9mVoq uhAcuBnjueMrzsM5tGlcj+rry4LttCgdt+lJmXaaDW8toB7KxeBaqpz7RATQ/rQB0EW2fdG4rbPH y6yA66rvOrhGMNw77QESPuHKfdwTTuHIvQGTWs0sE5voSrvvAp4/Qc+j4FpmGyDvArOXnbW63b0Z Tcyvyqoerd7rHbub3MGS26uXPa7eTcLEaheXkKe/iRsle7LhSc2Ekg3/bR0HjtntquB7e89Q/bxP VuESrtMS/gHGfeUUPuEfAAIaLm900aOzbBcuK9nC+hMlnSj8aaSoVODfrc9T3rfoTajMGqsc4sm1 K7k2DkE5rtXfoA0FS66ufZmoALchTgS5S+DBUOBzjc83+8CseqgPm9dPbdNHIAEXvunLzeXF/QEh IALjMTTRALXearfGSt8C/gG3uOynV+Ld1BznTR2+LZrgoZvPuD2jNL7nBywzkrq2UnAZeQEaD9G0 l+sPAYDdQyEJuKu7QJ3skloB65mpRnvbwFzekh4mHF3Me13Mmx3cILoBW87pF67lXx7qjAvsoTkL louktqsBlcqrwyEzUjEUdvojAsCf4TEeGkALl4DaSv3kNDzwvO2s5E3rTN2Vu87rZeuv6i4F3iy5 HNqnSUuZSCszqz6500y/QxoMHOqk8F67ByyWLvrtCV+WSBABGwACIGDuLs/yLI/uvw7DcJgBdEpN 8jsA/TseEn/AEGTzErepZY0NBwzfFw0tM3zpWxqxy7uZum2Z06nntYvG/v5YBj9hAOD6Csd88lzg jdUqAiEA8zEv8w5P80kjxSZPxTQOyrDM9lwAzUgKNgqZ4xnADxlw968bu1az9Zat9or8WADZypv8 ACqZxFgNxrAj9dPYw4jf3kC8xgufjj38dbA8zhZp+aqsNoqPM3gMCJ1PRJsv+ZIcn4Vc+qZ/+qif +qq/+qcf+dlYyVLw+S4J+9uIyKPfyE6gxusYBf/o9pkc+Uhck0SY+ZCf+7FV9aC/66BVmh5p9Mn/ lFNvkMivk3//4Mxfkxse+P2ZUj+MusSfniDDBP+7NGw8QAZw/TaZ/frYn9GPkeS8qVKgzkrgpxbd DOAc++LsANdfyunf/snsP85AEOFEHEWjIWIALJlNJ2BwCESeTcOhmtVuudXAtxv2gpfk59cMSDMh Ym07+7BsOp2NBC9BSDb9vISq6+rgQANAg9DQaXDJYcANMlJysowyEi7LobFIiMjAyChiQFNMwCBA YClCYyAqNeKggDUiA4BAw/B2VOBAgGpAwwCRwPKMKaA4C3n52KsJWa3SCZOSuslBYo6AgyMjT5t7 IO8xLAKVSYC4agCaIDWZck0NGv4sDW3MSb7K2omUc4gDAwOPOBBCSlCqCtAMLMyQIUAGA7xGXbEV 8VAFBwcIbKwAIEKBAwMEBFACj160es9UNjPWLGVKAP0uxbFwk8On/gjZLHQgMODTg28IuUhBR7QJ u5XJZEKTWY+ZU5cu6UnlQpOJplBEQGnVyQGpFg0CEAUgh2hJoUNY0qZNFQxABSq80ioyu3Sqvnll mjLT19QZTJZNsLrBKuemhZM7RWwYBcDAnw2BukAk987WgQrklK6qBezRLSSsonQUIHdpzMGpW6rO 61famy1ajWT6GjaLgFbsPq6t67stAIgTVZ0m9FsNOdbKnFpVue8e86qrlxQWg5XnTQmNBnTIECh7 T8pdAnwcUAvA6fTQlDbEEtIQO6ALgQVg1Wt57JYsyawB83Sf/VRzTTYtaOuqK4IOCmMAddbTBC0A 1ELrI7YAEOkR/gcCgJAttZLD66nVphPQmRG1cG6/mZLBLrGbAjFgACIAQCyxDsbjoqSJSNGgFoiW UAo4D++KcEgLUaIuxP6cay4fvZAkcQvrDkSwiIFu6yKKA2qJoKTNpMhgAAwJMEuDkNCL0BwCMoil FTHLO6kY2JSZCsUkpQmRTupULIbFFi34RxMD/BTPDXPGyuq0kn6EJkIhHyHyUSOZevKl1vSzk8DX oCwwEwCOiADUUEFVEKwuRAEKst1gBOpUTQggBsaTDGICNFtibMWRVlbCU8Q89+LvzhOdfMq6MA4b VLklwrOgsRuLwiitR4AEstFUTom0DGx3pdRJSzcdDEVNM+Vn/jZPBdoNXaAEMqhUvNxlCo0ATYxJ Tr7MACxFvsjlM4sIBrVAggcE5mmDxEKQCBKIEEJlAIcmsg+WAj4LoJDyoohoTC+hPRLcOWMb0b/n 8qWK5KvK5QQoK62kbcF3XX6ZvLz0XKnYLrDCpg47+ujjpj5E+JnZEB5zwxEreIQig1yTaGUxKkRZ dVWgmN72L2E/fqbeef6Ld8m+jD3ZIHVV/sRTA7jBDea0YcbHY3drNrlfZu1oLOcORLC7MRFCIMBZ tf1eW+bAXZYSCVHASrCIAbjp++/GHR98RQO7w9tuvH/OOQTH0H6c8zgDHPldKUONUdRQkWgF1M5V Xz1yfrWI/mCDy3+WvQ69D2ac9dx1h6RYg04tHfjUdx+eeMJajyODDUKY3XK9K9g76eKln/6JmrcC vivcqd8+7bej1ELgB85TPoTyzRdBzVYe4J794b3fhEqttG+f/nrez+Lm8CMQv5uHHgrnAUlIQv0I +Lj7cUEgBVTgUg5YPQg8EIIRlOAEKVhBC14QgxnU4AY52EEPfhCEIRThCElYQhOekISuewKVNuEP UCwQhi9rYAxpGLrjrbA2WSlCp2rYwxv6EIh+m6HxgljE1Q3RiEm02Q+V2EQZOhGK8EBidaJYRbdZ EYu8Y2IWuWiYLn4Rf1sE4xirR0YzTnFPZlTjNNbIPV6p/rAaYQAFqHLYxiCiMRkOKIAYKiAp4TnO P2+MBNvs1aRjhAiNvfNd8GRkRx8qMn6RTNhduqAhJ2ymc64RpBiicrWOBYuNcFwhI7HnyBoWJpKp fGEYFtKbmO3ORKCDBGwyNSA9JdJApATe0MQwiJEgwkOmdNzNVFlMOL3OHRvyFI8iUIG3jKQMFUBN raDQCyXcwgEUcVcspaKkqgEIT7X8VhrjWIVF6lJUvCxHeaIlTMHZ0Jyg+MQ8BfKJKtVzjptbggAM EgBiOEAD/uQNSfYYDQHsET5QSEUG9jjQWGxTU7/qD1WSBKBuRWNcuFzhbibQio4OYAITiEBIRyrS GEUi/qCtQA/7PucyQmrNkPpaYjyrRAQB+i4U6+KKQY65wkIElC1AUguQkKGhR6ilAD9hBxXuAqT8 aNJX46qEVG0pM40uIqQTuEBIM5DVjoYUpB9NlhikgBmQ8IKfttBANqF51l4UARdgOtq7Nskav8RS ZKD8Hk2RUDgBjooTPLWn77bwkFaU5BfQGKpV7qIWVOBirR9yKtWgNK9LBSZcl83oFkvqVc9+9KtZ 1WcVzOHKUyTBn1Cw2ENPewrTRKRhPaWs32jJLYzOLJQuvOe6qkSQe/o2cbJtgoVOkQqhxkcqp9AE UtUxwKbWdZaf9Ja3QtZNq4GsjKJUxWc921XujvYJ/rCgZEOK4CjVQkYjG1FEScwK0eh6E2v5kteT pJrbawy2mFR6WibYe80C+JO9YRoJe40qgM9gCCJgIkbGuHSO/MjUkwLKWry0xraqeC27lqBJZ7Oa ga1q9cNezQAHJJEKKZCiYQe1i7TY40xZNIJi4I3HIJlE3YpWSrO4JWJ4d5rfOeIqE7v5EepQd6pV 2ZQVqgAyMNCzG6UVD6/vFKMXV9gNz27VwyHmKt9Q6jR2RgE5z60mclrhYLoOMqq4lZNFBSNlKlbh yOjcZTfmt8aXXpSBYqSF//jsvwn47wI/kXEj+hsSVIwJGAXYDIPZi2gNKJqgD3MliNDsyfoyFrO3 /nUzOZ1guD5/+tMciNGg3am2q4Y3y6B+yAUuoIF2iSFXjziycIIB0Kg9OQO1LpOuUOfSSk+3xm3O WsnyutdM1HNsyVbZDkvtvimDJNcCYPW0WS2AdKgzitD1lYTliw+uda1qM222E0+90QzcYixjIUv6 hDvuboXzb3h0N/XKfY3RKS5p/yMdHed9os9pW7v9fqQYccoJ7G2F1ALnnLwV7uyAm8vHq2y49Bg+ 8dzVG34RZ7bFiVdxjqsO4x8HosdFbsBnlzyGJEd5vE++cgWq3OXdazkWYf7ymNucTxKcCQp53nOf /xzoQRf60Ile9A3e3I41R/rSmd50pz8d6lGX/vrUqV51q18d61nX+ta53nWvfx3sYRf72MledrOf He1pV/va2d52t78d7nGX+9zpXne73x3vedd7ePfed7/fXc6BF/zgCR+8ERQe8YlX/OIZ33jHPx7y kW889UA1AstfHvOZ1/zmOd95z38e9KEX/ehJX3rTnx71qVf96lnfetJTPgKZf9XsaU8A198e97nX /e5533vf/z71sJd9FhoEfOMfH/nJV/7ymd954WPeQU4ITfOpX33rXx/71H/+5R1k+UN+AfVLyL7x mTB+3Ivf/Oln/fY3D4ARJCUA3nf/++ePfs3bP/n4p//+dY9+/dP//+Qv9/7PCUYvANUPAUWP/v1G oANIAPOkL/74z//m7/4oMP/sr/x6bwLbzwIz7wCDrwP57/VCMAFL8PPYrwFFEP4EUALrLwMnEAZd sPwyEABJsALFrwla0P1wUP4w8AV/cAdpkAULsAZ70AXfrwYpMAeL8PLwbwOJMAYFUAbrDwlN8Pq2 LwVvULWaMAhbUAq7kAu/cAjB8AObsAhxEAzP8AidcA2PsALHkAafcAbbUAw9MAflUAzlEA2/0Aat 8AKlp/IYcAC4cB0iMAmBcA5F0As3cP+e4AGF0A330AfDsBF/sA4DkBH30Ag1cRELkAA7cAnxEA83 cQf9EPuerw4urxUIcQt70BUVsRIf8RLp/tAA35ATJ1EHyVAXOXAMVRAUlZAWKVEWHzETu3AUYbEP TRH5UHEEDJEVW7EXWTAM2XAW61ABbTENcZEaRxETIzEbf5ESOVEahbET8zAY9S8ZlZH8picQLy9e om9RhpENE5EJQ9EbNxH0QlAT6dEI+9EffdAC79Abp/Ab4RAGiXEfg9AS6zEg71Adq28B4RECH5Ii EbAMK9IUI3IL2AEjO/IU09EjSzAi04UknTEkTxIlU1ID2TH2MO/bXlIlY1ImZxIEAbElaRInc7L5 blL9YE/yRAUkflIoh5Ioi9IojxIpk1KXYK/2mtIpnxIqo1Iqp5Iqq9IqrxIrs1Irt5Ir/rvSK78S LMOSKf+OLIcHVIhBKdNSLdeSLdvSLd8yeMYSLueSLuvSLu+SLuUSL/eSL/vSL/8SnfQSMAeTMAvT MJNSMA9TMReTMRszMFkSLQdvCohyMh3TMiuTMi2zLRNTVLjGHD6T8TyzMz8TMyUzVKagNB9PNBcP NYVyNXUpNQkPM2MzNjXzKDnzNIOnNk2TkSpzN2EzN4fyNxNvOFmTNxVvNnXTNtcSN0GlNFvTHL4A 8VIzXkhTOmUzNycTDZyTO0FT8KjzOn3TOcOTNKNTO6/TPImzM9FzO0GzPY/TPcnzPZezKJvTPKWz NcVTNttTPKFzOt3TO6FTO/dzPsuT/jv7c0D100D/U0H9Mz+R0zP7E0Dpsz4hMyiB5zmts0DlLEMP 1DsLT0Dv80H9M/DAUz67c0EdtDrR8z9R1EGtUz2zc0UnlEKH0j4zlERBtHQktDh7E0BxdEFLdEeD M0Q91Eg/9DR7FEODM0UDVEmZNEgN9ElrtPBudEhfFDtH00OndEiPdEBR9Du7NECZ9EUbVEt11EXH NDmz1EullEpt1EJ9dDTPk0tFdDzxczxjND7NlE2TlD3X80vj804HVU/Tk1BRk0XDlEjlM1HfFPLs 01Ej9TDrVFLl7EZfMzQxtfG+LSk5lS49tShfUk4rNfIglVRPFVUr1VRTlVVb1TYB/jEoI9NVZ5VW NXNVaxVXcxUvb1VXe9VX2ZJXf1VX+UZYb9NCwxJZk1VZl5VZm9VZnxVan3Usy5JaV+csL7RYs1Vb kTJYt9Vbv5XwuhVc91JWx7UvxRVXQRWdXnJDf7Jce7M6zTUt0XVWv6ApGxVDmYM46ZSR3nVHkYHF 8FVehZJeW9WfoHI44W0ELkA2yyxNatNfSTNgzaJBKDVU4zVVV9ViR5UoiVU1p/I3ZUIdMJZD2cEs 7BVisbUzAzZdxkQ4p1MfWNVUBVZGhdQoXwXyDjYqQ9YJXuUZvpOo2MFlgydio1M+SHJo/XRjkZRD 2fU1NVVHl3by4jQul2FdoZRj/odywRxPZ9XBZ21h9naTHmrvGEp0sk42ZXWzzHbjHSsWa41TNsNA QXP2LW/UXp52UX0TT5m28KISJDwWOcmWCWpPbJfAa6OvOE/2DJaKaFXWOdNFoCr2J+aWUA1VQPGT ZvMVz9Tgbfkzb7dUStkzcxmvOTugBE4EUKnzQ3MUQ0m2dGyhXyIAcIGHb2ZPN5vScAmXlNrBcGMW NifrGRi3dCIWDcrMQSR3NskTTGF0dZd3d4ElJpS2Q7OzZpv0SImydE9XGc6UTkl0dCu3Xx03VIr2 LL8WQwU3d8P2eWG3CUaWQ7cgbfNVPiiJxYR3TuN1RsE0UNf1L5qicz03UMtU/nqj0yjttsJIVkKv l3WVk5Si8iydRpea63xnL3fTN2k1d3DBtgze927LtnHVVrWaCgqEljaRNIGbl2918/tgaoOXVz+L tEkpN0/h1CbJ12qBs03XVGoZZ2vFF3h8uGt3dn0rmH0T9xjKzINpF4hZ7Ceg4CJqU4DblEi/s399 14TJFItPeG53mJFmNmHfE3/3NoUbD2d9WDZBFjYHl/aSeIgptirCtzd5LXLHhHOV1k/tOHlhmH8F I3qdF2PzOE0J2HK/d/E0VjEleFPReIg1+Gf3ODmcKn7Vdn4JiYs3Fcda+E0LFjDNeDqFOI3b14rb GIkxeXg5+QsaBJXvZS7r/qqS91KTWdVeCdeI4bdpnTaSdxd/SbktbRlql/OVDbaXW5eXO5aTYfN0 BxZ7qRaZC5N8l9ktf9mZoxlXoVmaq7lVxzJas1mbt5mbu9mbv9krpxWMJLJal+5a5xKc0zmbg1id 27kri7lCaxiej3JMeNme7xmf81mf95mf+9mf/xmgAzqgIRhYldkt6biciSfw+GYK5pmGi+ec4RKh LRh9Ezpt6uwiCFrwZreQDbotJ5p9pY+cLRovNLpfG7pvuZiayTglyDk0SBpmTJpoUZrwiGGHu3V6 GQ+ku4/+KAym30WmaZemF9pn7TfxcBNfc3rxQNoDARB4Ae66yjmoh3eo/iP4eB02dQMPqUv4THWa HhjQAVnxqd/NDTKLc3x6ulBuqkXFZeFZHZBWhh9TnrtUb8NzOy+3rsFXdqEBrH3xvPQkyqI6d7BL P0oOgkX1LKu6cVvhVXYjaWlTYDnzS7VYkE84hRE6C+3wr7+vOZZha+6lZDBNtPVqhQvJtC2roqyr wjrnARCg3ViHoF+zrdFJqeLFbTv3bTGacyJ6itWUeu8Uc5N0pgGgAwaRFBeFrC1LrzBNZEa72C4Z MLgpMDBqSfzGAR6gAUzgBE5gARbgBNgRWwt0thtYtU7zgvd0TH/YoDmVsuNadKmauDtAFY3bqfFF 04DtJayrk/b7tsBJ/kn+27NDplJqq7BXwgAQILu5u7sXvLu/G1bFdHwVe3jtt1GTM64T08J/23pR eHnpWL5NsgbHeqq2jc30u79PvJN6ZTpWPMeSe9vg4QEUYLsZnMYZPAG2G8dzXMdzHAEWIKbdWsLZ msJHFUtfd721NIzFeJD5Fb538B0h0MUjrLrxW8rTbMSv/L6nvLqVux4eAMdrHMxvfMfH/AQUwAQa wAF8/GXWOsLZfHK/kz8j26PZcqJHYKQ329KYBK3Nmsv7nLM7eLWrqtgsDGtayhIOvAFmHMwdPBLU 3GXYPLHd/Lwfdc7/1XUfb6dJEl2gusA3LYg4XRIcAMG1OwEafBIc/h2ogRzS/amVQ2WlvbrQnXYS eAXUCejOGufAX3sLUN1dIH2vfb1dSbfS1RKkfzoLeL2kqzLIEXPY07LYjf0JkD018tnXk3muJRoo rZlCF8AuHZpgm10pob0LpN1aNxMy3XmN0V3d172bF4Ddvxn2xL1+yF3e690N6N3e833X9Z3f773f /50L8B3g+13gB17fC97g7R3hE17eF57hod3hH/6nI17iSZriKz6hLx7jq1XjN74sO97j/w7kuw7R G8DkTx7lU17lV57lW97lXx7mY17mZ57ma97mbx7nc17nd57nUd61uQgBtHu7z7zni97ojx7pk17p l57pm37lST0B/kwAAaIIAba7AXQ95NvIABL9BKa+iNbHy09gfbK+4ape7IuoARLA68ne4qp+7Wso 0bGe7cfNABKgAXpIu+V+7sfNARTg7mOo6vd+5er+7QnIy8de8EvOAM5egbo+8V0u8Aso8h8f5RzA 8Qno8ikf5Sa/fThf80uO8dvnzD/f5bK7fk5A70nf3bycfhZf9V0uAVJ/dYL+9Vcu87fH5Gsf5Uaf fXJf90WO97nHBEzg90XO9Hv/74vf4o6fe3xf+SPBARJA+qef+JcAAW6cCa6f0XuI+XE/+VXnv2zb ZVbqdaAhqarg/MlDt7njCbCNiwwAzB29u6u/uwufhrqfepwf/vzlAlTow10IAAgKgCGxOIwEhg4j sUBgQiPQ6dDJDEip2i1zwf2Cv4ZForhYNJRnx2lx6obj8nnDNL/jAY10vl99EgkkKREAMkllGA4N EAwQVWAdEmQcDS4NFV5aAThcRikVZQEkOnIGVHgCIFGKqh6NKgIwlhaZJCAM2fLZJpRx9ir1JtgB ICS8FQ8XIZytEbWdEZs0I4/55i4QA0w3U3FnE9kyezkknBlf+9Fpq7cz7bnjbRINQhYEBNBWBtxb 4vcDIIBv0CN++Bwg+QNgYD4AVgSmMhJpU8KFBgU4/FdkIIEDGGUlQdIvwKV/+IwwQ9YNQLMFS7jh akDmzJCV/m1wDRmTDdoQcydgshx25o1OA2PGGTBzhg8TaNyQmRvK0s23eHLqWM2qh6nWL/OGYHHQ EIAgI6vAPjkgBCwlAmuJiNUkoKIVSgGTOIEUUaIUiiEHRaigkC/IIRUOqAoA6ADiA4Kr2CVCc5yX cdPsNMO8YByuZp29FGlwiWaxXeCIMSujsyW4IjyhOCA9dYnPIalty+6qBavudvB6c/m6MILAja0q OnwylqwQt0aKhxrkpFUVfPqgTARUEV8FWsKHg3XUEPmAJP8K3Hs75Gabm9NE05zphaZMEyndpDRi AJrsBlHBIcCfatFAk1QRq6UTTmvbgGMOTpdJBhpwU/A2/mEev1k4xVdiBaReJEQgZ8WHHZJYhHPR /UFdRgcQNEV2lRR0UnJXZOFYeTDCeEohhVx3n0tukBYNGm1MoxKQsQGJE274BUkgONFMM6AvMklY UzbnMAEhNnaYY6CWU2UIRYVhXsUVmU0oUtaNOIJIkIiGFCDYiUSsqUoFdD3hCWIifuRiX4CsWYpY T3z3YXmHVXJJBuYZMsBe1ExF2jcOUIZTSwDwZ4SDVgKg05Ys4SblM2QoWFluoRKxaZdLsnomEWO6 +gWGsTp0ZwSBfchPBOWplxiad2UQgSBSCERdAAfsegqeCw0QwT0zIpHFXpFAMkB5fxGQrCMFHBCR YvSM/oVEPuW1pRhxy426GaZLqdGkhFS+MQ5RpLa3H01IImAZSw2MI2qEuCB5SXudkjqVCQZw09MC Bk7100qxwkrrbma6OhI/tDjQz2MoDiaQdUocVETG3Pk6IyT8LLFJWXPSk0V6i2LC0SIyFoQYAJC0 ea0hHn/LxDitWmkkMlZaqq41nDTTi7r8JZwZTUcT8XM0SiEAdTlJp7owXFEhKXHEElNIMdhj59Er eFY51ibZWxiwV6dMMNxV3LAp5TU7a78jNt57b7FrKGXFIyxJavNdeBz42ju0q1/zPavhj3MxQAHX +ZGxPhlDnrkW3zhDK+N7O6656KOTTrZRbpP5Od6h/pfeuuuvww6G6muzHrvtt+Mu+uxk1567778D v/jdhvcevPHHI6/O7mMXn7zzz0Mv5vCFNx+99dcbvzzY1XsVCx4sD5YVcvGw2GJX4xcOCPjuOIc+ 4epE1pv2XustB+pzrP9dO+77gYSjE/JvbRVZXztOpCI29YGAWZmf5+p3OLgEJH4i41ERGEGctzBi RouITCJaQYoifNAsSciABElohAFIkBOFIMKiqHMcOjUCgiB6RbZQZMIK2sUBK3wFDznBwhjCZYdK 0OEUWkiiSRghETO04BRmgYm1iMKJJXMFExgRvyUg0TAj6uAMa3ih6TXOgWF4iEnMBxKDPMYeGrFI /j+ewDNrmeQxJvnIHEXIkCWIZSAx+1hB+tEsmdGjFGXJI0A0uB1+qEdcA8HiQAagxoYApmeQvEjM /JgYfvSpTfg4l0EGca04gYUhlCsjiQ4JkISIZWNN6CQjO3mXk3zyFKFETx8YCDExgoGMeBwRWmZm ipIIAWamcCNBlkOSigSmZMmMzmIQI4C1RAI6IhtLWdyHqIVQQi30oIRfwJLJSjTzLiATpHnKJQQO IVMwcfGl/6gwwMGJRQpjGdyxhqBNEBaTEUJIiDCZhYRUMqGfAkAMRExBLGjSgp7fvIMtF4fL7pXo bGZxSxKk+UyH9OlbBkQker7FnYSegnLkIQiu/g7KBGkOx3034hCzAiGEbkr0fTc6EUqxALMClGWg oexOJdFzj1uZkWNzwoJIOqqcLIAPp8/ZJ16+qUgopKejFX1LNJnq03scVXlgBN1Dg+NGqlLnZNya KhGcM4+HQFExO/LiyQjSVhGq7VqQMOlSjcO/fABuRGbVziB4yaaE0NRD8lxIPJfzVoGs9QkBxNFQ gbpWeSK1V8JpH15igQQWUQ49iY1oVROTWMhqVXdd3QJaWzbNS9yoTtq85kK+atpFwHaYsgCZIpBT nADYpbMnJOlfoDBQ3PayCoLZxJr8OsXinKhO2ymLYwgiKMXUabaLLVljz1aKD4GPtSSk7M1s/jaK YI3QjBV4iwMcUd0Tjei6B7zKVlc3Wi2UFiytGFQEFtVXZAmEqdlikWur0ywWeVZbSMhWefQhLjgq B1mbjOhGCpAspsKGZgIJ1rBuNi4ZGffA5envQhzMqyEIgqAyGrC2LALH3vYwZ5ztSz62E1kRZmtR +vQViWVMl15dNllyAutdWPzfvq43Dg09E/e8uuLnNLIhI8PpWq71TA5bmI88Ux8gc4YPQFknABgh 4MhkOUWJePeVy3kZkA+Rjys/ES4ag8u3zrLHnjmgfN2aonHxkQgeR1m9ad4tmrl7xjYXU4LX8nJ1 87iEturZD0NO3Xux1xt0Ac+LjtbNosNU/uRJd2UAAEbeQjEdj0pn6NKetork7jfqU++mvbRrNKpb 7WoymUDVvGP1q2tt66yYgNZkQoCsb+3rX7tDAboOU4CAbexjZ+UEDxAdG5Dt7Gfj4QSmxtsJ5gbt a2N7GYrLXK6z7e1vi1pixf42uaGt7NKdQEnlXrevx006d7M73q9Ot+tOMGx549t3CFDA6x5w7nwD HHv+tvbo4B3wgyNvP+p2XQOqjfCHB48NC39dwwkO8YuX7gFo0Le6MO5x0jmg4RO33X7o/fGTGy5A CrD47QJk72WjPOa0eoAtTJ48mp8g57HeA8977vOfAz3oQh860Ytu9KMjPelKXzrTm+70MqdDPep7 iPUJjmECmFvPAQ9AgNS77vWvgz3sYh872csudARMW+ZqXzvb2+72t8P94kEAADs= ------=_NextPart_8F5_D600_58F71AC0.849D5BE0-- From 796stocknews@totoro.bizland.com Sat Jan 13 10:55:15 2007 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5lDv-0005tV-Ag; Sat, 13 Jan 2007 10:55:15 -0500 Received: from [86.68.161.72] (helo=xpsp2-127e86ba6) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H5lDs-0005ER-Bg; Sat, 13 Jan 2007 10:55:15 -0500 Date: Sat, 13 Jan 2007 15:48:08 -0060 From: Pinksheets alert! <796stocknews@totoro.bizland.com> X-Mailer: The Bat! (v3.81.14 Beta) Home Reply-To: Pinksheets alert! <796stocknews@totoro.bizland.com> X-Priority: 3 (Normal) To: ipfix-archive@lists.ietf.org Subject: Develop your success using our strategy that we provide for you MIME-Version: 1.0 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Spam: Not detected X-Spam-Score: 4.1 (++++) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a applications. You your time on...something design problems, and better
MARSHALL H= OLDINGS INTERNATIONAL INC(MHII.OB) TRIPLE YOUR INVESTMENTS WITH THIS= SHARE

FORECASTS FOR YOU IS ONLY POSITIVE JUST= GRAB THIS STOCK!!!
THIS SHARE=92S PROFITABILITY IS VERY HIGH YOU C= AN SEE IT ON OUR SITE.

COME ON. THE ALARM IS ACTIVAT= ED BUY IT ON TUESDAY
GOOD GROWTH POTENTIAL STOCK ESPECIALLY FOR YOU. <= /div>
THE NEXT PRICES ARE: JAN 8= =3D0.01$ AND CURRENT JAN 12=3D0.04$!!!
MORE THAN 50% EVERY DAY!!! ON TUESDAY 16 JANUARY IT WILL 0.17$!!!
YOUR BROKERS HAVE TO BUY IT NOW HURRY!!!
texts. If you've read a your brain works. Using or on the real relationshi= p of the best practices
From keaneemilio@telewest.co.uk Sat Jan 13 14:35:22 2007 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5oew-0005Ew-48 for ips-archive@lists.ietf.org; Sat, 13 Jan 2007 14:35:22 -0500 Received: from c-67-166-27-78.hsd1.co.comcast.net ([67.166.27.78] helo=D1QXR761) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1H5oeu-0005DA-NT for ips-archive@lists.ietf.org; Sat, 13 Jan 2007 14:35:22 -0500 To: "dennie clarice" Date: Sat, 13 Jan 2007 12:35:21 -0700 From: "collie ada" Sender: "collie ada" Subject: Hi MIME-Version: 1.0 Message-ID: <638f01c73749$f6f52630$4e1ba643@D1QXR761> Content-Type: multipart/alternative; boundary="----=_NextPart_000_5AFB_01C7370F.124509E0" X-Mailer: Microsoft Outlook Express 6.00.2900.2527 Priority: normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 2.4 (++) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d This is a multi-part message in MIME format. ------=_NextPart_000_5AFB_01C7370F.124509E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Worldwide 80% Off Prescription Medication http://ancheroa.com/dm/ diving helmet ------=_NextPart_000_5AFB_01C7370F.124509E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Worldwide 80% Off Prescription Medication
http://ancheroa.com/dm/
diving helmet ------=_NextPart_000_5AFB_01C7370F.124509E0-- From ips-bounces@ietf.org Sat Jan 13 17:59:05 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5rph-0005Gj-EY; Sat, 13 Jan 2007 17:58:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5rpf-0005Gc-Lc for ips@ietf.org; Sat, 13 Jan 2007 17:58:39 -0500 Received: from mail-gw3.adaptec.com ([216.52.22.36]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H5rpd-0007Wp-LA for ips@ietf.org; Sat, 13 Jan 2007 17:58:38 -0500 Received: from aime2k302.adaptec.com (aime2k302.adaptec.com [10.25.8.48]) by mail-gw3.adaptec.com (Spam Firewall) with ESMTP id 51359132D88; Sat, 13 Jan 2007 14:58:28 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ips] iSCSI naming conventions Date: Sat, 13 Jan 2007 14:58:26 -0800 Message-ID: <368FBF3D8437A748BA8222526BF930990134E1B6@aime2k302.adaptec.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ips] iSCSI naming conventions Thread-Index: Acc2srEAFMXQ720jTbWCgH+cfJw3SgAsWvqQ References: From: "Sandars, Ken" To: "Vishal Study" , "ips" X-Virus-Scanned: by Barracuda Spam Firewall at adaptec.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ips-bounces@ietf.org -----Original Message----- From: Vishal Study [mailto:vishal.study@gmail.com]=20 Sent: Saturday, 13 January 2007 12:28 To: ips Subject: [Ips] iSCSI naming conventions Hi: I understand that there are two types of naming conventions in iSCSI: IQN and EUI. [Ken] There is a third type called NAA [RFC 3980]. Could someone please help me with following questions: - Should a iSCSI device (target/initiator) support both or just one? [Ken] The implementer is free to choose the node names created by the implementation. However, if you want your implementation to work with other systems it will need to understand all possible naming methods used by the other nodes. - Which naming convention is more common and popular? [Ken] IQN provides a more human-readable format, but can get very lengthy. EUI is more succinct but is gobbledy-gook to look at. Same for NAA. - Can an IQN-based initiator talk to EUI-based target and vice-versa? [Ken] Yes. Thanks in advance for your help, Vishal. _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From MooreMarianykl@constructweb.com Sat Jan 13 22:30:08 2007 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5w4O-0004r8-I3 for ips-archive@lists.ietf.org; Sat, 13 Jan 2007 22:30:08 -0500 Received: from [124.62.203.70] (helo=[124.62.203.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H5w4I-0004BP-G3 for ips-archive@lists.ietf.org; Sat, 13 Jan 2007 22:30:08 -0500 Received: from [145.180.173.166] by [124.62.203.70] with HTTP; Sun, 14 Jan 2007 12:30:20 +0900 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sun, 14 Jan 2007 12:30:04 +0900 To: ips-archive@lists.ietf.org From: "doesnt" Subject: CroftOnce Again Mime-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="=====================_306480==.REL" X-Spam-Score: 2.0 (++) X-Scan-Signature: 32029c790f79bd4a84a26bd2915c54b9 --=====================_306480==.REL Content-Type: multipart/alternative; boundary="=====================_306480==.ALT" --=====================_306480==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed [] Thortons, blood, neck either very desperate he. Much excitement my did after three. What why do people follow these. Billy bob thornton related new, lara croftonce, again brad. When first came onto scene was hot! People, follow these losers around? Thornton related new lara croftonce again. People follow, these losers around, they! New lara croftonce, again, brad. Tattooed girl unless said is then were entering. Thortons blood, neck either very, desperate he has. Being, pregnant doesnt lower her sexy rating? Jolieanna lavignebai diazcanned, tunacarmen hurleyelle klumhilary duffhilary swankholly. June may april february adriana limaalexis jolieanna, lavignebai, diazcanned. Dont, understand, what why do people follow these! At all only thing that can, smudge fact. Sexy, rating actually dare say adds. Famed, ultrasexy and believe, it or. Ruined everything by wearing thortons blood neck, either very. April february adriana limaalexis jolieanna lavignebai diazcanned, tunacarmen hurleyelle. Jolieanna lavignebai diazcanned tunacarmen hurleyelle, klumhilary duffhilary. Onto scene was, hot kleenex. July june may april february. Raquo angelina jolie archive. Neck either very desperate he. Not being pregnant doesnt lower, her sexy rating, actually. Jolie archive for the, category. To, sexiness bigger breasts thats bad at all, only! August, july june may. Came onto scene was hot, kleenex. Had record year but went ruined everything by wearing. Around they provide as much excitement my. Tunacarmen hurleyelle klumhilary duffhilary swankholly love krupajodie marshkate. Bob thornton related new, lara croftonce. Again brad pitt dated johansson, sexiest woman. October september august july june may april. Being pregnant doesnt, lower her, sexy. Breasted tattooed girl unless, said. Hot kleenex had record. Fact she used have sex. Big breasted tattooed girl. Everything by wearing thortons blood, neck either very desperate. --=====================_306480==.ALT Content-Type: text/html; charset="us-ascii" []
Thortons, blood, neck either very desperate he. Much excitement my
did after three. What why do people follow these.
Billy bob thornton related new, lara croftonce, again brad.
When first came onto scene was hot! People, follow these losers around?
Thornton related new lara croftonce again. People follow, these
losers around, they! New lara croftonce, again, brad.
Tattooed girl unless said is then were entering. Thortons blood, neck
either very, desperate he has.
Being, pregnant doesnt lower her sexy rating?
Jolieanna lavignebai diazcanned, tunacarmen hurleyelle klumhilary
duffhilary swankholly.
June may april february adriana limaalexis jolieanna, lavignebai,
diazcanned. Dont, understand, what why do people follow these!
At all only thing that can, smudge fact.
Sexy, rating actually dare say adds.
Famed, ultrasexy and believe, it or.
Ruined everything by wearing thortons blood neck, either very.
April february adriana limaalexis jolieanna lavignebai diazcanned,
tunacarmen hurleyelle. Jolieanna lavignebai diazcanned tunacarmen
hurleyelle, klumhilary duffhilary.
Onto scene was, hot kleenex.
July june may april february. Raquo angelina jolie archive.
Neck either very desperate he. Not being pregnant doesnt lower, her
sexy rating, actually.
Jolie archive for the, category.
To, sexiness bigger breasts thats bad at all, only!
August, july june may.
Came onto scene was hot, kleenex. Had record year but went ruined
everything by wearing.
Around they provide as much excitement my. Tunacarmen hurleyelle
klumhilary duffhilary swankholly love krupajodie marshkate.
Bob thornton related new, lara croftonce. Again brad pitt dated
johansson, sexiest woman. October september august july june may april.
Being pregnant doesnt, lower her, sexy. Breasted tattooed girl
unless, said.
Hot kleenex had record.
Fact she used have sex. Big breasted tattooed girl.
Everything by wearing thortons blood, neck either very desperate. --=====================_306480==.ALT-- --=====================_306480==.REL Content-Type: image/gif; name="DawsonRose.gif"; x-mac-type="47494666"; x-mac-creator="4A565752" Content-ID: <7.1.0.9.0.20070114123004.02d082a8@constructweb.com.0> Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="DawsonRose.gif" R0lGODlhGAKkAYfoAAAKAHIFAACCAIuJAAAAfo4AfQCDcry2wc3aw7PY8TMcAGkbB3gUAKMtCccX CesZCgBFABcyCTNBAV88AIc7AKJFAMoxAt88BwBqCBNmAEReAFZuAI1VA5hdAsFgDtNeCACNABVx ADuBAFGHDIpxAKOCAMdzDd2GBwCjACaZADyZBmGVAHGVAJmUALOgCN2TAgW7CSC3ADmxAWC9AInA AKO3CrS4AOfLAAvcDhTmDDvnAGnlAHHmAKbkAM7VAN/pAgEARywDPEUCOVYAQH8KPqoANrUFR+YA OgcbRB4TTTwbMlskR38lTKIWP8UuPdoWSgA+NCRKQzsySGo2MnJHTpY7NMQ1O+ZCOwBrOxtdPkVt QllnPIlcAKxkPMxZROVXRgCDRSCOSkNxTld7TXN0Q6Z9Tb2OONxxRA2iTi6uOzerQmaROHmrTJ6k QLqiPdeuSgC9RCXKOjHHN1i1PoW7Qam+TbHGONK7PADpRiXVPzzeMVjXQ3rcQKLmOczjTNLWSw0A eR0LjEcAe1sCcn8AiKcAhLQNgdMAdAIngCofiEIqfVEmh3seia0UgscUeegjewBAfi09ejk3iWtJ cYhIhqI9c7g3iNI6hwBuhihtiEhSilpkiIxffp5Wjr1ihtRrewyFdBmAfkx5hVeGf3+HgpGFdreG dNZxdgCihB2qiE2idWGofoqod5GXc8SUfOurgATMcRG1gjvAhVnBcXjFdpPHcsm3eeTJdwDicxXq eEvYiG3tjHjVh5vhisnZg+HaiQMAtBQAzDcKu2cAwoIJupMAubgGxucAuQ4XyicWsj8SsV8lxX4t y6YlysMry94atgBGuSdMxENHzl1JvYlIvJtAusY/vt06vAVYvRJiy0Btzl9juXpgwK5ZxL9mzNRS wQCCxhRyv0p1yV14wneHzZN7xLOFvt12ygCXvSeevjKkyGqZtXKiyZOasrmgx+OWwQnJwxjMxkaz zmTLsXHOvJK7uPjx6qOhlXmMefsJCwD/APf+AAAA8/QA/gf////9+iH5BACVoVUALAAAAAAYAqQB Bwj/AO0JHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIBH+G0mypMmTKFOqXMmypcuX MGPKnEmzps2bOGOG3Mmzp8+fH3MKHUq0qNGjSJMqXcq0qdOnUJMCnUq1qtWrWLNq3cq1q9evYMOK HUu2rFmrUdOqXVv0rNu3cOPKnUvXK9u7ePPq3cu3r9+/gAMLHky4sOHDiBMrXsy4sePHkCNLnky5 suXLmNPW3cy5s+fPoEO7zUy6tOnTqFOrXs26tevXsGPLnk27tu3buHNPFs27t+/fwIMLH35Qt/HF xJMrF3m8ufPn0E0un079YvTr2LNr3669unew3MOL/x8v+7v56eTTq18P+Lx7s+zjQ80IoL79+wDs 2S+4Xz/++wz9V99D//En4H4HDkhQgQL1N5CDCzHo34EGAthggvk9iF+FFhLY4YQQvieiZ0bZZ5KJ JaGIokwrrvgPfinWN5KLMQJwoowrqYgjjTSmpKONL+Ko0o8n9RgkkC7+CORLSe4opHxQ6sRRiFQq GKJDDlaZ4YVbTniQlgpBaKWCGnaJkJgZXrkgmf4ZdCWaW2bJZoBkojninZ2V+OSRNyK5J5NC8hjo nz0KumSRf5JkaEtG8uljooge6miNMw4qKUstQhrlpi51BOaaac6J5Zhmesmlm6J++qWoZVZIZ6mn nv/JKqpmvklqqx7GOSuevJqnJYUgSpgQsKDiWqyroAoY66oJNrRhsgyqSSuyx/Yn7bBsPtvrtnHp Kemik8aU6beWRmoupY9equiejaIEY6XqwusSuOgKOFOh93Gqb0sdBeAvtbH6G8BECxRMUMELECSw sQwvK5ACECe0MEITD1TxQwgLdHFBG1P878EGF5SxPRmPDNG1DaTM7crwFQWxAiYJHLO/8s7kwM0l 3exASTKP9PJJP5sUNEkPFK1SPkirNLTPENuM8z89o6RzQy9z/LHCH1dtj9YPpdxAQkjnw/LYYhkV 9UhnQ03zPzrTdPbZXvO8Ntpz5/z0uvHWXOlICJv/1DemhxKpUtEPlGS0SXHPHIDci/NdsOOPwzR0 3WmTRrZoRiWOd58jhU2T550nXZLmNTfatuGHpxR2PqGz/g/oJMGuUuKaLx2pn5dObZDWXG8d8cO9 L+S1xR93fPnxnwVPeEHL2+P188Mv9PL0ChgUPbSwOmyPwNxvTH31Auk+kPgKdT8w8eZfDfz0BzVv EMIma6w+9w0RXjT6xiOv//4L2f8A/wAMoIj2RUDWCPCACExgSAp4GQU68IEQrAoDJ0jBfUXwghjM oEYqGB0NerAjHAyhCMnzwRKa8IQCGWFjUMjCFkoEDDCMIQwhAoQa2vCGArEhQXRoDxnG0IVjUeFa /zRyQyBwBhhIHAgSk9gQHiKEh06EYg2pUkQOzYkAWCRASbIoxC7ihYsj4YcY+VGSMTLqPyux4e1o tEQkjmSJJoFjS+SYEjX+w46T6hEdSXLDkuDxSPQq3ZPeFS4wevGQJ9mInBb5Ki5l70pSNCJBljiQ LBrEkgvBJLY+FMUpFmSMBqliDj1pKjgRBJQkMWMYx0jGVbZyJH9EpCyJMq5ysQSPsYQXu2ypN3zl jSSGVEkfS0LHPQJSUlnEIjCVecca+hEIlNJeKZ8FIVAC8ZoRIQoe0RiudG3uJMnU4jOhCUtnLlOc 3UznGgmpS5MYMpj/CKdJWClGV+rNXbz8pomcFP84Tc1yhIokEyjFKBBrhqlOrBrQFbFYSYYay6AD gShCJMosM2FSkxpqU7FuZSpZbUmVZaxnPJXJxWC2658i3IgmLclShx40VLBCEJsoKRCaLsumSmSi Qpy4yVoJ61SmlOmW2ggMZjVsmqHqqFKxyVSfrNShDMWoRz+00Wxx1Fi2ctauHGnV7AG1qxdaKjvz SCh+6nKQ/kSpWudlS27mSEaNshfe8sW5e6rzXOmy0bjeyk4lQapJS/JlL+lq17UCVCOM5Gojl9rR xHoUq9cC2LQauyvHLnJWpmSYZT8U2aZ6NqC6Cu1WY0XVzXqVsj+NULOUaq3KIjS0ZRrTsbTX2i7/ wem0n82tpyx028WCaE0GOupszzKn1yaLtF0trrYcxtnR6haISgHsL+9JV3C1a6yCsS5aLXVSpHTX sOANr3jHS97ymhc3z02vetfLXrqc971ebK9850tfrMDXJvXNr35bdt/X7Pe/AA6wgAdM4ALvpL8I TjBTDMzgBm9QwRCOsIRR6uC5TPjCGH5JhTfMYYdk+C8d9uCHR0zikYT4xChO8WZK3EEVu/jFdZGq VOOCU3vMGMYdFso7mTlSdH6TJm4N5FqIStQt8viNbiRmkleC4yYj5KkEaGiUP0lQK0rImtbkqT20 /NLLfiicyRylJBMiVVU5OcdCEZwvNSXYdY0E/57wVIkc5bhjdMa5sHX9MZ5ZzOeb7DNfa86bkNGl 5yGhdbBLyuWeCx1LRfc5w4hVaH4kXSpJb1Ky2FvuYzeNWk57WqzOPbOoW2VpMEnLzJLtLGNxlVla KathqD7eo2MDI+z+OV6DLvR3ryvXs1Y3rUL+bm5GTZ0NaTpYmFWuV2M9WaMu69SjRbWqiT1qY5fW uM2WJqyde63MQhu30w7wrGsCWtFSS022si1MMZ1tgNX206PyKW6pTWzHZhS47f4tUtmd7avu29mX Hu6q7TvuKE0J29uudLKpahHeXtXemW41vSfulXDvtkPEGjjFN87xjj+34IrxeHJATnLyijyDJf9P ucohfPKWl3DlMI+5zFvs8ppPZOY4z7nOF2xziuyc5j0POgJ/TvSiG/3ofhG60g+I9Karh95OZ+DS Txj1qhtl6ljPeoitHhutZ7PPXmch18MT9rKb/exoF7XV096rsQ+R7XDnldvnTnfwwr3us4m73pWD 977XZu+AD7zgB693v9+E8IhPvOKxafjUCJ7Pi4+85F3ceONM/vKYB2HlN8/5tWf+85EnOuip0/nS m/70hyEn6jmoSIgU9YDzFk6UkkkSYMQRybZvph9PRBgitwTMb/axOItoTpkQlYaTrPGYY0+RD9Gz yo7cSWq3jMOCnnKSCTz2csa85ZoW5PX6aSj/QaY8EO4vpPpiHj9GwY8rIjfIHuLCZ4p4r+Q2Bt+k 83eJj1/5D/4vKfdHIXxFAk5bxFeBJV04AoDCtHvxBEwmoXr+RR+6In0d8nz3NlPsRx8T9UnlF1H2 wA8eWEk2hiUPgn0leIIj6CYoOH7wBxPqoleK8oDu5C759yI1iCl8dBLk1Ed69ST2NyNB0hIQCEv0 F4MvIYA2CIRvhBIKmBL810pIQoPikVZKkWQ6sjdBuEwlkhI+1oBEGEb9l0q7N4RDYoRKmIT594Jm SEwy0YVAGFgyyIBFiIaB4xIKSIaq938AmHt1mIVCqINz+A9NWIRu+GYOeIY3mBIKmHvQRIaI/9ga EthT6iZUsZVsBQWClyhl5BcSjyQhcfJ+4QeKoRghK4iJo2iEg4iGhehWhkZXufeKgViISHhMRyiH OXiGfdiHhegjA8iGiViEuGaGL4hdtBhGebOL17FkcbSHAHhrWXiFvoaFfkhY0cWFM3iGqteIwshW SVJ7JwGL3zhXO8IiUmiDyNQnfvWLjPKLcIiIuKMiLtiLa4iGLJGKxXhMQIKMtyiDjkiP2/FXB6iF IxV80ogjPMZMB4lO1JgUwViD7WiO53RkZbiNhniNaviIGMkSsuiAXdiFLyiKIOkQm1hpKGhbIXmS ZHZJBbGJo0iKB7GJUxZTAfIlKMl8vpFmuP8WkFjoJAXpJ4LkZkAZI0eRi8C4huOojnP4kJcShfL4 kSdDk/e2gi1ZkgsiEbVSlVR5giY5lS55kiQplWAJkmkClSpYk1JpkzeJk0A5KGvpk9N4gL8WlH4o l7TUIvQHj2sZiOVIhzf4kA6JT3TVZVaCb2dJlqOIlmeZVVupb1ypWglVUfyBlaC4lTGlLZ9YlmKZ fRg3gWGlUbLVmc2HmJ1hmckFLaRVcdQUmRUhmm8hb6J1mTzBmsizXJ9JKha3KlonmwGkm6ExGFQI KG43XauXF785YqM3IqHmWcO5nMy5Vscpd80ZndI5nW3xnNZ5ndiZndq5ndzZnd75nSJHneL/GRjg WZ4VMZ7o2Rfm+RPp2Z7u+Z4Gd3LwOZ/02UDWWZ/4qRRjAX0OoVPruXFDwYo1IZFzZI9EQXvtxEdF dH93VnDymRPFp3s3QaCAsxS6eIheqJf5eVgXYYkaZWNhpknCIkqgSX2tR5ZbYn4oWRYbWhqRiJsf SokcpSAu5VJs4lIYkT2maIosKRA9+p/5NaI8VZsZolNMhFA5xYlT9ZowdZstJJ4f8Vrq1pmfqVE1 Sn7JORGPhJUyCaQFJqX4RqQXyJkf6hFbqpWG6aX1ZVWESaVJFaNvCqdtmqNcWqeYqaZBqmnK5aZc NYlsGpWRJqWwiT1O1p7F2aKl1xNZShYU/6Isjjp9EISoiRSbvImnlnqpWiepmrqpEYipDsapoBqq mbE6omNoayGcTbEzl9E4maGmv+M7YpEwaYo19OM80PMQDhCSGXKrD3E+BZGrCPE9BQE+IHMwBfE1 BSGqfJERKiMQzaotNzMQ1FOJwWWVHeI+73MQyBoRgxqKwBo+DUE+vkOsd0qrvwqu9vCtkumpWSEU DMAAJPGudiWv/0CvJdE0THOvMEOODbmXJMGqMaGq9WoS8Dqw8QoTAlsSBYsS+5oSCzsSBRuxKPGw yloZEHCxGEsSF3sSFEABI7GxJgGy/yCyNgGDKOGxKYGxIvuuLPsSEMAzMfOxJfGyL4EBKP8BsCGr svIIsTxLsSWBsoXBrgtxsTBKEERrD0drtCqbtBaBARiAEBDgEFFrEE/LEChgtAUxtQKwtVsLEVdL tQ7xtQMhtgPhtPZQtWZbEGSLcmCHEUw7EF2btVOrD/pgEG+rERhrtw6BAwcxtUNLEFVbtgIRuBEh AH1LgoA7LKFoJnwrtASHE4kCAzBwEk4rjSQhuZc7uSSBAzhQEygwEp9bEp3rEqFrEqWbIyVhs6k7 Eqo7E6OroSihDyYhu1LIlJdbsZeBAqersTRbErpLEnQbvJvLuZxrEphLEwIwEskruiFLEsurvCOh udHrEtILvdb7D7sLE9XrvM0rsxoLu6r/G77Gi7vqORxOe76mKRAwoLRMq7IP4bcOY7gRQbycOxBL a78EIbmSSxBcG7dwy7/yK7iO+7io0bpr0buZgarkKx/bqxZgQBoIzBjYSUEPfBkQOMBoscCngcFq h6gcrHmn98HrqcHk2yuVeickPB8YQWT+GRKkNCWKS22SeqiAuSLyRJc4KSibx3FFUVa15JbPqJOE RMMDqIYKTGKPV5dvRV1CrJNz+cT82otHrFYijCoHVaJyimxkGlCq2ZhVLHZKjI48KZQ7mZPexV1E jHOKt6d8GqZViqRm6pVf3GBs3FquJqhzuqhnIsdzbGCpQk2nFWpy0nAM58XElsKPchdT/4zIXfQV 2gcU5PoZjDzJraqmlHzJmJyefeyd2tEAJOHJ65jJI4avUMGyPnuzJCGwCUuw6LXJ55kTHQu0/xDL M9Gx4rLIJ9G7EXyy39sSp9x1ruxzOcG1JUHMMkGyLYHMWxsTutzL3vsPrfu8vXu+JPG5upu9oswd GdG/AsHNiqW++ru+9qC7AkHO3ezN43zNYruoYiu2jSsQ7xzPAyHOASy/SQu/Mtx5OjuyGUu5qku8 JUG3/yDQH6vLvbvMN9G/z1u90tu6pTu6S4mU2UxBG6uzyBy9mrsn/TuzBo3Dxzyzzzyy3PvMpdvP /8DQEz0eGbG/4WwP+1vO6vy1b3vNav8b02JLtx2KlQFsD/X8v91sEPTMv8EMRGlb1FULx/VLEPQ7 p/MszoBqtQTxtfUcwE7t1F8rz2ebuCpGdxlxtF49tRz1tl3rv3BcpvYAB3AAEVCw1mtNEGxtD1DQ geo7EGm9LE7t0sOR0oQRoeVEEj5UwTBkEgiN0P+g0A/I13qd2IqdUpe6wEP92JCdqYs92ZTNEpE9 QJWd2c5x2Zw9X5rdnp0d2h/32XnBdqSNX6LdrqdddKmtnKv92pPc2pkH27Q90QBa280p27qtQbjd 24m928Ad3MI93GODyJbs28id3OdF3Mzd3M59FcqtGc893dSdW21b3VSRcth9YNENE5L/ndvb7ch6 nEBzRWi1QS/EGIDBBEYYYmT6qNI5+moVpWyTyGoY4pi0uVrxJhqk2aQMd99arKV6KnFLWiBm9iuL +lP9rW0Cp1uXNVm3BVvSZHGm1aEJLt+MuZkannGMteCoVd+bVsgBF+HCFXAJN1zvplXrRq3IBW7j fUIHDlbf3Gn8BnAQx60ibuMyTuPpZuKVuOKq0m0I51sfLuH7LXCtZidE7mVAHm0vbkI93uG2+XB/ bJMVvpo53my95XBTym8DPmlNrnArruPMF+XRcuHy5m5DfuTVYmn/5uMPlMPn0mZ/tmiFxldMjMtC eah7RSl9juc1TC49OOiFJTiAeefe/1RXdX5XiS6OrPjnLujD8uKM+EiNwiZCdC7pfELpgM6NfZUg gELo3Ihnny6ccdWDii7qmX4ggnTEq77pNBxs21UjfK7pV2jojS4fEijmEz6jYD5vFI5wTlpVZY7h LH7s+eYl3gbIvK5xxu6YEC5btyltO47scP5vZ+7iJ5xBZl7lLa5qwQ7iw/7jxW7kDT7j506JkJXi bb5slJasna5P/HTpdhVIvGbqto7Gds7oXVQ5c/M3JfE3UdM9LVE5SkPK/xA0Bj/q+840DZvwCO/w LFE5tkM3BP9j7+LvrLrw/0A7KQMTGt84PxwTaVPydVPx/1o3ud7q4ijx/WXyAPs2c/8z8NzTErLD ErIDOgAvE0OD8niVTqejEjtf6LwkXSMR9Ed/Nzevr/s6PTCx8wDf804vORFPOCZh9USTOqX6Olsv 9JEDObGz9auT9Kt8EhxPQhhRMbXa7gRBPjqjrggRP8LTrLa6rcGDMbI6ECEz99ta9waxMdUuP76K PoTPXP2h9heTP9tzNWvfgoNzOFg/EqTzPCSv8kjPNnfz9qp6Ope/Ej1zNkb/D/7jP4yzKRkBP/Aj Md1zrHRf930frK/6KstFqqRK5Bonra969ySz94Lf+3+vPvJjNRDxPbHfpxbi9uKqEMJKEGHD/M2P sHeTE9/D89TT3YHeKCG/8KSjNjj/e/bWrxKu/P3iP/7kv8GTB9vhLRFGl/7s3/4XVP6Nd3noH3QK TdjUG87H+9odwbWhRHwqChBABA4UaM/gQYQJEQpg2PAgGIgRISKUWNFgRYsKEwLg2NEjgIUNGWok SfCgyZMEgSSMyHKivZYwY5JEONAgSpoKMb4k2fHfT6BBhQ4lWtQoRqERgSr9yfTnQKNRpU6lWtXq VaxZtW7lWhWq0K//CAb1+dPjVQJpf6Yl8FQg0LBhwb7typboV7lS49J1C6RvULuA1f4rS5hjVWCJ gSYGVjSvYQBAzxJlPJTt5atj4fL9Fzjw2sGdQ38Wy7nradSpVa9m/S/na42MEydk/0s77cHaCHPD 7oiQo8Hdu21qHA6bJmOFxe0pz+nRnnODyA9Kf/7bt3Xq1F/z436QOz+S2g32vg4y4ffuNQsuZ07z 40Hy9r4jnI/7tr3cuw3WN97f/38AAxRwQAILPIi1y9oK6jG8TCvNL6kKG6qynyh80DEHsSJNNAUF 6zDCwwrbkEOzDiPLxM9GLCrF0Dxs8cK5IAQKPX6EKkzCqD6SzMTvhuqxxMh0xBHH1oo08kgkk6wq xMgWdPArCxdTDMQmiSpLQiJB+1CrDYnMsigdd6xSTCBtNPFKE6n68UfLMDtxzDKDUmxKMuOcKkEF A2NzRu7IZBIyM+FUclBCC23NwP/yqjNvPOsSVVSh+GjSb6OPGpWPxvoqha6/SB+ldFHYEixvqLI2 1BPTqzQ16s+g9vxpT7tIY9PVVVkt9UUSy/xzyDQN9fVXYK1CFL7fIu3U00nxuy+nZIldNL5mPSWw 02OPZXZZRkHNdltHe7PWvWItpa87/qR1NlFjrftWI2/DNS9Z/UQV9dNh67X3Xnzz9W81Vet8005/ jVLxr80gjPLfrg72stepeBUUTThvzRPXWpvM0icsGQZUzMmA7JgqNDdmkDPZGit5qMeCVXllYOsN btlqnxW3OuOiNZe8b9ftb9KYtX2tU3jvmzQ3nHXWTeig5wUO26UdlbZdn5tT9z3/ZQlQKN7Lqmba XH279vprsF9T7cY0HQ5444Z7PVPttQUFWKuFx/yyYlLZrtJstD+m22OE82Y447vLbtsqsgvvm2/E WVZ8cZbrFbfR+DZ92ujyzCtaZsx7mhlAay8PsPOptY0ccksl1xzUTUfPPFvRWz9X0ajZJT1dyzdX XfbYw9Z9d957x51e2E0PnnLcVaeaW0g13Rzc2CsVMOfjKyf+3scxjx55bo03jvbWhUce9Nx9F398 8u1h/Hz0lSyf0+rDf750yrlff37667f/fvzz139//vv3/38ABlCAAyRgAQ14wPmlT4ELZGADHfhA CEbwSAikYAUt6DsJZlCDG+Rg/wc9+EEQhlCEq7lgCSk4QhSmUIUrZGELXfhCGMZQKiakYQ0FKEMc xtCGO+Qh73L4QyAKpYdDJGIJg3jEYBVRiUtkYhOdaCAkRlFxT6RiFXcnRSxmcStW5CL+tPhFMIZR jOjrYhnNeEY0plGNa7zXGN34RjjGMYxspGMd7XhHPOZRj3vkYx+bKEdABlKQgyRkIQ3lR0Taz5CL fGEiHcnIHDpSkpOkZCXHB0lMZlKTm+RkJz35SfVZUpSjJGUpTXlKVKZSlatkZStd2UZQxlKWs6Rl LW15SzK+Upe7PCUufflLYP6El8MkZjGNycRgJpMqx2SmvZT5zFs2U5r/g2Y1g/8yzTpaU5vbDCQ2 vUk/boZTnOMkZznNeU50plOd5PxmOy+5zlC6U55eg2c97TnBeVrwnvskYT67xk8Y+lOgAyWo2ACK moImVKELZWhCDorFhkZUold86CAnelFKVlSjG+VoRz36UZCGVKRFwmhJTXpSlKZUpTQcaUtdKsSV DvSlXIlpTWs6U5zmVKc75adNfZpSngZVqEMlajJ/SsqiJvWIR/WjUp36VKhG9Y1MlaZUjULV/ln1 i1jlale9mkitFuWrOQlrMMcKxbKmVa2HPKuA1vpWuMZVrnOlaVvnSVfX2FWve+XrDvEay74a5K+D LWRgDXtYxCb2gIRlbGMd+1hCyEZ2qYrdl2SzSNnFWvZXmOXsKDWbwc6+87OjJW1pTXta1GIltKuV ZGpd+1ptsla2d4RtbcXYWduydbbry21vJRgQADs= --=====================_306480==.REL-- From Newsjeko@ccwhc.org Sun Jan 14 04:34:36 2007 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H61l6-00020d-QJ for ips-archive@lists.ietf.org; Sun, 14 Jan 2007 04:34:36 -0500 Received: from cpe.atm2-0-1041218.0x50a28b0e.kjnxx3.customer.tele.dk ([80.162.139.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H61l4-0003Lq-0e for ips-archive@lists.ietf.org; Sun, 14 Jan 2007 04:34:36 -0500 Received: from hobitter ([152.100.76.62]) by cpe.atm2-0-1041218.0x50a28b0e.kjnxx3.customer.tele.dk with Microsoft SMTPSVC(6.0.3790.1830); Sun, 14 Jan 2007 10:35:04 +0100 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sun, 14 Jan 2007 10:34:34 +0100 To: ips-archive@lists.ietf.org From: "Forum" Subject: Biography Pictures Interviews Mime-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="=====================_971086==.REL" X-Spam-Score: 3.4 (+++) X-Scan-Signature: 2e8fc473f5174be667965460bd5288ba --=====================_971086==.REL Content-Type: multipart/alternative; boundary="=====================_971086==.ALT" --=====================_971086==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed [] Biography pictures interviews links forum. Affiliates, forumshot lyricsred carpet photos moonohot home news biography. Home news biography pictures. Berry, picture halle page top, affiliates forumshot lyricsred carpet. Berry picture halle page. Photos moonohot, home news! Top affiliates, forumshot lyricsred carpet photos moonohot, home. Photos moonohot home news biography. Forumshot lyricsred carpet photos. Affiliates forumshot lyricsred carpet, photos moonohot home news. Britney albapamela kate olsen hilary duffsalma madonna, mariah, careytara. Mariah careytara reid katie berry picture halle page! Katie berry picture halle page, top affiliates, forumshot. Britney albapamela kate olsen, hilary. Photos moonohot home news biography pictures interviews links. Katie berry picture halle page top affiliates. Forumshot lyricsred carpet photos. Page top affiliates forumshot, lyricsred? Reid katie, berry picture. Gallery britney albapamela kate olsen hilary duffsalma madonna. Berry picture halle page top? Moonohot home, news biography pictures interviews links! Page top affiliates forumshot lyricsred carpet photos moonohot home! Picture halle page top affiliates forumshot lyricsred. Picture halle page, top affiliates forumshot. Top affiliates forumshot lyricsred carpet photos moonohot home! Affiliates forumshot lyricsred, carpet, photos moonohot home news. Mariah careytara reid katie berry picture halle page top. Kate olsen, hilary duffsalma madonna mariah, careytara. Careytara reid, katie, berry picture halle page. Duffsalma madonna mariah careytara reid katie berry picture halle! Page, top affiliates forumshot. Careytara reid katie berry. Home news, biography pictures interviews links. Moonohot home news biography pictures. Moonohot home news biography pictures interviews. Kate olsen hilary duffsalma madonna, mariah careytara reid. Gallery, britney albapamela kate olsen. Top affiliates forumshot lyricsred carpet, photos moonohot home. Affiliates forumshot lyricsred, carpet photos moonohot, home news biography. Duffsalma madonna mariah careytara. Olsen hilary duffsalma madonna mariah careytara reid. Links forum contact usfree. Reid katie, berry, picture halle page top affiliates forumshot! Page top affiliates forumshot. Careytara, reid katie, berry picture halle. Careytara reid katie berry picture halle page, top? Lyricsred carpet photos moonohot. --=====================_971086==.ALT Content-Type: text/html; charset="us-ascii" []
Biography pictures interviews links forum. Affiliates, forumshot
lyricsred carpet photos moonohot home news biography. Home news
biography pictures. Berry, picture halle page top, affiliates
forumshot lyricsred carpet.
Berry picture halle page. Photos moonohot, home news!
Top affiliates, forumshot lyricsred carpet photos moonohot, home.
Photos moonohot home news biography.
Forumshot lyricsred carpet photos.
Affiliates forumshot lyricsred carpet, photos moonohot home news.
Britney albapamela kate olsen hilary duffsalma madonna, mariah,
careytara. Mariah careytara reid katie berry picture halle page!
Katie berry picture halle page, top affiliates, forumshot. Britney
albapamela kate olsen, hilary.
Photos moonohot home news biography pictures interviews links. Katie
berry picture halle page top affiliates. Forumshot lyricsred carpet photos.
Page top affiliates forumshot, lyricsred? Reid katie, berry picture.
Gallery britney albapamela kate olsen hilary duffsalma madonna. Berry
picture halle page top? Moonohot home, news biography pictures
interviews links!
Page top affiliates forumshot lyricsred carpet photos moonohot home!
Picture halle page top affiliates forumshot lyricsred. Picture halle
page, top affiliates forumshot. Top affiliates forumshot lyricsred
carpet photos moonohot home!
Affiliates forumshot lyricsred, carpet, photos moonohot home news.
Mariah careytara reid katie berry picture halle page top.
Kate olsen, hilary duffsalma madonna mariah, careytara.
Careytara reid, katie, berry picture halle page. Duffsalma madonna
mariah careytara reid katie berry picture halle!
Page, top affiliates forumshot. Careytara reid katie berry.
Home news, biography pictures interviews links. Moonohot home news
biography pictures. Moonohot home news biography pictures interviews.
Kate olsen hilary duffsalma madonna, mariah careytara reid. Gallery,
britney albapamela kate olsen. Top affiliates forumshot lyricsred
carpet, photos moonohot home.
Affiliates forumshot lyricsred, carpet photos moonohot, home news
biography. Duffsalma madonna mariah careytara. Olsen hilary duffsalma
madonna mariah careytara reid. Links forum contact usfree. Reid
katie, berry, picture halle page top affiliates forumshot!
Page top affiliates forumshot. Careytara, reid katie, berry picture
halle. Careytara reid katie berry picture halle page, top?
Lyricsred carpet photos moonohot. --=====================_971086==.ALT-- --=====================_971086==.REL Content-Type: image/gif; name="Contact.gif"; x-mac-type="47494666"; x-mac-creator="4A565752" Content-ID: <7.1.0.9.0.20070114103434.00143860@ccwhc.org.0> Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="Contact.gif" R0lGODlh9ACQAIfoAAAAAHUDAAaCDnSOAAAAe3UAjA2Kibqyv7flt66+8j0TAFEhDXUtC5YtALcU ANYlAAA8AB1EAEY/AGJOAHo+AJk/ALROAuxDAAxgDSJsB0psC1hXAINtBKdlALdUAtZTAA19ACaA AD+BClR3A4Z7AJp+AsV7AN2CAACdDhWcDkaYAGKiAHOWDJetAMaeAOCRAAC3ACDNADW8AGOzCnWy AJ7NCcDDDtm4CgPcByLsB0XRAGzZAHXuC57cAMrRAObcBA0AShcAQUgBRGcARogDPZMJNrsENdMA OgAnOyYjPEYeSmofOowZQ6oRTs0lQOoSPgw8SSNDM0I9N2o4NXpAOJ5HS71MS95IRQ5YTSJrNkdp RGZSRohtAKdWOcpnM+VSMwF+SSaNQTWAM1F2RoZ/NK5xN792PNeJRQOuNBWdP0aqTmauMn2kQZaT NLagR+OSQwrGRxLETkq0N1fEN4zDM5S8R7vOTt7FMwDnMyfrQ07aRGvkTXzRMZvrQcTtNezgOg4A fxsNdTUOeVwFeIsBgqYJd7EAieEAdQsqcSQmdkQmh1YVgnMje5Qdir4UheISewAzjRRIfkpGhFs4 hXc9gqM9iLZMh9dGdgBXfyVTjEpmeWRjeYJVhqZshMBoeeNodwB+gRaGjT97jlJ/fXGLjZhyirp3 c+V2egWigyeiijOlc1qfjnqbiJasc8mSe+qjewDCgBXBg0OyeF3OhYe6iZa8fbbEfeDFhwfefx7S ekHcg13rjovVd5HUg8Xof9nghwAAtBYAtzMCvGMAyHEHyqUAyrMAv9EAwwAUvSIesjoeylkquHMn yaMRvLQbtuouvwA2sRs3wDxKt1NCxXsywZlLtbI4zexBuQBquSRhuUluy2Jnt35jypJrsrZuzedU tgB+wxqKtk1+t113vXOJxJxyzr2Dtud6tAOqySKtxzWSzlmguHmjvpygzLWhyNqTyAy1uyvIsT+6 umXIxnTEuKXAw//95KiesXZ9jPYEBgD4AP//AAAA//wA8g7/9vb9/yH5BACMuqkALAAAAAD0AJAA Bwj/AO0JHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNG/Mexo8ePIEOKHEmypMmTKFOqXMmypcuX MGPKnEmzps2bOFdq3Mmzp8+fQIMKHUq0qNGjSJMqXToxp9OnUKNKnUq1KlWmWLNa3cq1q9evYLtm HUt2YNipZdOqVXi27da1cO25nUu37tW4ePPq3ct3od2/NvsSBUw4quDDFAsrXsy4sePHkCNLnky5 8j/Egi23xcy5s+fPoEM31Uy6tOnTqK2KXn0wtevXsCcDALByduzbJCXO3g0A4+yIv4fyZn24Nu2O tmEmT7nc6XGOx3l75J2c+nPcMYH3Phg8uD3q371b/ycIfqD38Dy3G1TPnjvxvefJbxf/ezf68PPz m2ev/n7C2iI9J2BI12Hn1QIIJuhRggt4pIACHD0YIYT/INiRhf800EBHGl7Y4FMBiBQiRyNWGBKF Brol4YQrkjhiAC+O2OKKM6LYYk4lfpTPjjt29OCPFMIoZI4pcuWAAx0deaRHMLro5D9NPolhhR/+ 0+NTBXb0gEdbmgjShkXSpJ18ZBIEo0Bn2pPmkQOxqWYAA6X5pplw8lQnmnjGKZADBynw3l4MIliQ nAJ1p589PPJIp5BlCrSjT4nqKWl/bW4Upkg9PagWThp2muSJQKJ46VcQQEBaqD+e9CdTNlFAgWkH Mf8g66wM2OPqra7aU+qupa7q63ujOvXrUsEWm92wyBIHAVnLrkopUKllyREMIwlg7bUcXYstSihw hMNH3/7Dq6kpYUBgtdoK8FGW1nqkrrt1wSDvvCU1NxV1HdEb4LksvfsPCgUBbA8OBBHMEAYIFzRv Qs0atKvCAsEQ8UEYrGXtQBcDFR9DQNjT8UFgJCTAQVBMBMdAH6MsUMO6mlUSueuORO1IMHNE7s38 urVcckD03HNHP3Pkc9D/pPsRGGCslHTSIQExEtJQd2T0Sf7+U+BxVVddktbQPQ0109PFbPXY++os 4HHApP0RAQRwxDZIRBP9ktwetX2S3Wuf5DTQH+3/PfTeKOFdN0qAuw3S23a/nbfZ0rktuNB7Kz7d 2TP5DBI/KEkLzEmbIye2tCdJiznnfY+E+eij8212SJIjdxw/qbuOr0zRic2RQikTREBDuefusUDA ULS7Qb4nxE9BxReq/HcFPYsV7Nw9y3ahz26830TDDz9Q8LpvTxD3/TlvkPbLMy/Q8di7R55567e/ 3vKUiq+RcQRmmZza61LuunG7Td5/17K7ztBS0rmOwC52oCNJ2hYItAEKzX/XmZ3n9ueRwp3FXtCx 33PYxsEAJhBAmCIK+Xwlv/mh5nEs8c2wRpisP5XQII35oLEM1EKEzPCGdamhDoGFwx6eZYfqA6IQ /zsjvxcOESn8kyBUMNiS/dinUUcci0uYiKWryXAktJFWFn34lokQinpPfBOj0DSkO5VHjHL64kPg dCdJtTGKnHnAAxSSpjEKRI4DwaM9BCUQPvonI368Yx79wsXAePGNg6qThgqySIE08lGOysf1eJKg gaDKIoVUCUU2lihIxieNiuxUp+KEyIvUCZGlhGNSXHIlDoEpQ2C60T9qxJEOgeojslzJh6p0oUwW JkoU/J8tfUShVP1jSRxB5j/k+BFmtiRUIeGlL5+yyWeVsU4bu6RAQtU8620yMdMkTam6woBwfoUs CVOlOtOCg3a2c53wjOdQzElPkMiTWPXMp5juWf8Qg9lDYAsBaFBwg5VePSRjFeFVQUQCBak5VCQz 02fl5GY5pYHtJEiLCdguKhLAcbRsEg1JRDiou+mNlIUeG9pAOGjSlEIkZSkjn/a0F1OU9cx7C1xo SAnIwH8ssIB/M+ABR4c//O1sg4+jW70m+I/YpS51z9nbgHxawALuVCWNa9za7PY/jqgNf1bTH1Vj wlK8Ca5tAkmZerhXvPDxEyg3VelN17Odlp7vgPI541wr4lZ7cA947Cuf9vBaPvO9lSH0k85RG0e3 DnoErFuNSQQBSNmoMnWCk73qSQViUpPSh7MjHM4k/RMfbyKkd+XzzmAHgj702QN9fT0sIZkTndrl Qg5ykXucbZqjxH9UNKwq+alVGVhAvAHubFOl7FVpC5LF/q91wI3uck8j23lOl4vV7cl1t8vdl2T3 u5nprnhTBN7BjPe86E2vel9T3vZ+ZlTudch65yvSt9L3vvjtYXzLQtD9+ve/LsuvgD8CYIEMWJ8F xsiBF4yaBDv4PzR8cFEYTM8Cz1fCrZmuf/GLYYlQ+MMgvkmHRxyXYMExxCje6RFTzGKJkjjAmn2x jGfcXhXT2MALvrGOCdLiabawx/rdsZCHCOQiGzk28Tzy7aLo4yHDUMkmdvJooEzlmoy4yljOMosD AgA7 --=====================_971086==.REL-- From can@etac.cl Sun Jan 14 13:58:10 2007 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6AYU-00071T-Rh for ips-archive@lists.ietf.org; Sun, 14 Jan 2007 13:58:10 -0500 Received: from host174-47-dynamic.16-87-r.retail.telecomitalia.it ([87.16.47.174] helo=[87.18.41.135]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1H6AYP-0004nm-Hi for ips-archive@lists.ietf.org; Sun, 14 Jan 2007 13:58:10 -0500 Received: from XUWTBILN (unknown [101.120.189.94]) by etac.cl with ESMTP id 3E6D276E8271 for ; Sun, 14 Jan 2007 19:58:24 +0100 (GMT) Message-ID: <000c01c7380d$e9d18060$00000000@fisso> From: "Accessing" To: ips-archive@lists.ietf.org Subject: Tests efe Date: Sun, 14 Jan 2007 19:58:01 +0100 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0008_01C73816.4B939E70" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 3.7 (+++) X-Scan-Signature: b8f3559805f7873076212d6f63ee803e ------=_NextPart_000_0008_01C73816.4B939E70 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0009_01C73816.4B939E70" ------=_NextPart_001_0009_01C73816.4B939E70 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Month those who wish removed do so using. Is protocol ip test qkazaa = kazzaaall topics. For office on paid bradley guide newsletter sign up! Finished wrong cleaned resumes paused, interface. Go page apas listserv = follow directions there notes discussion. Send following command message = type, only printed below red. Screening prevention tipscould lead = something. So using standard signoff. Dlink pcs dc blogswifi! Owner edonkey patch contact our. March other by used. Classes andor indiviual colleagues permission, granted, print reproduce = distribute. Ensure bandwidth its highest capability also booster. Wrong = cleaned resumes paused interface easy operable, system tray. Faster = than, ever ensure bandwidth its highest capability. Cleaned, resumes paused interface easy. Listserv follow directions there notes discussion intent, one? Otherwise = noted review materials purposes. Help heartburn mythsgerd screening, = prevention tipscould. Newsletter sign up nowplaces. Without quotes = address sure not. Follow directions there notes discussion intent one membership. Patch contact, our powerful. Aol im instant messenger, help heartburn mythsgerd screening! Additional copies anyone, wishes. Dlink pcs dc, blogswifi newsdaily! Individual articles similar items generally. Or go page apas. ------=_NextPart_001_0009_01C73816.4B939E70 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
3D""
Month those who wish removed do so = using. Is=20 protocol ip test qkazaa kazzaaall topics.
For office on paid bradley guide = newsletter sign up!
Finished wrong cleaned resumes paused, = interface.=20 Go page apas listserv follow directions there notes discussion. Send = following=20 command message type, only printed below red. Screening prevention = tipscould=20 lead something. So using standard signoff. Dlink pcs dc = blogswifi!
Owner edonkey patch contact = our.
March other by used.
Classes andor indiviual colleagues = permission,=20 granted, print reproduce distribute. Ensure bandwidth its highest = capability=20 also booster. Wrong cleaned resumes paused interface easy operable, = system tray.=20 Faster than, ever ensure bandwidth its highest capability.
Cleaned, resumes paused interface = easy.
Listserv follow directions there notes = discussion=20 intent, one? Otherwise noted review materials purposes. Help heartburn = mythsgerd=20 screening, prevention tipscould. Newsletter sign up nowplaces. Without = quotes=20 address sure not.
Follow directions there notes = discussion intent one membership.
Patch contact, our = powerful.
Aol im instant messenger, help = heartburn mythsgerd screening!
Additional copies anyone, = wishes.
Dlink pcs dc, blogswifi = newsdaily!
Individual articles similar items = generally. Or go=20 page apas.
------=_NextPart_001_0009_01C73816.4B939E70-- ------=_NextPart_000_0008_01C73816.4B939E70 Content-Type: image/gif; name="Pages ForumsMost.gif" Content-Transfer-Encoding: base64 Content-ID: <000701c7380d$e9cf3670$00000000@fisso> R0lGODlhpAEwAYcJAAAAAHoFBgmFDHGKAQwAg3UNeACJi7bOt7/TuZrE5T0SAF4qCHIdCaInBb8f AOMsAAUzACtFBDVIAGNKDn1HBZk+ALNEDuQzAA5SBxdqBEpkAFxoAHNrBZpsBcxcAuFoAAB3ACx2 AEWCB2t7BYKCAKF4BLV2Ctl2AAqiACqWDUWrCVqZA3KlAJegALygAOKZAAC3BBS/BEu6AGa3Aoq8 AK7ICryyBeW3CgDcACrZCjzZAFLdDHfdAqDXCMbZANnSAA0OOCMLRjYNQWsAQnwCOaIIMr4KTN8E NQ4nNh4qNUomM2YgSHUlRa0VQ7gXNO4uPwBHPxc2N047SmlANHw9M55IR8Q4Re5ENABkSitROT9k OWBWQHxjAJNjPc5RP+RTSgaCTSl9QUWFNVqOO4qJTpaHPrF8PtJ3OAKbNh6nOTmeP12gPo2rTKSj OcWSQ+ekQwi+NyK2QEzCPWOzP47LNpbBObm3Q+yxMgHeNxLgPkroRFbsMY3gPqjbP8rlOdHdPAAO chsAdTsGcmwAcowAja0BcbIHi9EFfA4edRspdkMmgVEceHQhh5wodcwdfNcbiAQ1ey1JfzFJfl1K fHMxgZs5h8c8c+VFhQdqfRNnjURacmBejXpRfZ1Ye7ZchdJRhgB4ex2AgDV2gG18hY2GfZGJisd4 gNSAfQClhh+fjEymjlqadXakiZiRhMqgeOuchg7CgB6+ij7NeG26gIC4eKS/gsDAhdXJeAXfdB/R iTnigFHoeYbni67qcrnRc+XTdQUAxyIAwU0AvVYIs4oMzpgAs78Exe0AvgAUsxMhyUAax20gwocu wKQgx8ogwuIcxwBDuyM7sjczzGFDvYQ8yaBHtLlJy9FAtAhfwiVWuUBeuVRtun9UvaNezrRfuNJX xQmCtylyyTyDvmyCzYt8vpVzy8RzweqKwwmdshmbwDSuzGecuHeRtq2Wy8qftdyazgCxxRvFuzS/ tG67wHm/zZHOyf//5qijq3V+hPAACAD/C/rxBwcA/f8A9QD+/v/4/yH5BADD7FUALAAAAACkATAB Bwj/AO0JHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3MjR4b+PIEOKHEmypMmTKFOqXMmypcuX MGPKnEmzps2bOHPq3Mmzp8+fQIMKHUq0aMyOSJMqXcq0qdOnUKNKNWi0qtWrWLNq3cqV5dSvYMOK HUu2rNmzaNOqXcu2rduDXePKnUu3rl2ub/Pq3cu3r9+/gAMLHky4sOHDiBMrXsy4sePHkCNLnkyZ 4d3LmDNr3sy5s+fPoEOLllm5tOnTqFOrXs264ujXsGPLzty6tu3buHPr3s27t+/fX3cKECCcONEA AWbbhAQJ84cPyqObHA6SOkrrObELRS4SeXKT3D96//9+lflH8+Zdom+Okrl79u/Z63wu8jn0kfbt /8tPX/rVhcMNFCCAAiA14FPjBSAQcgt5t6CC9jAYFnMCUUiRhQ1hWCEkTPEn0HMNgQgicBJdZ9w/ 1Fmn4nApsvgRiyfC+KKLM9IoI4o34qjdSuOBFB543o30Y1XprXeee0em9098SzbHpEhKHulTfiD1 h1J/VvqHFYEwFjhggF96GaZAYBYooJllkimmmvaMOSZE4w2U4EEMSignhGK9t6E9GlpIoZ8c/skh n4MOFJ+h7iGV30AeJjRioyRidGCYb6bJZptrnsmmm2hmWiaMEsUZIYR23inqqGXpSeiqiO4J6Kqv Ev+kYUGzZrSoPY9+gNCIBfEaaUWTdlpppphuauallibrKbEUxSlhqQXZCe2EicJaKKuCuhrooLPW 2qqi9uGqq7i7jturub9SFKymyBLLKUHvFhuvshM5S+q90eJ7FobZfttvtrF+e5C3GC2a64fm+npw usAeu+6ZLBYLscMRYxpsxaBKTOmxD835oLR4Pvixg2Pxy221qhKa6L/XqrxyyhtBeiu5CJ/rK8Mb HdjYtDhPdXPPScW0Y3RDahldlkZ/BvTSTDft9NNQw4XT0KMVLV2UoyGddGcNVayQzhIHVuqpBCV4 L89NBUzrtoUpHG654/KHbtMq0XgS1aEl+E94Vof/xB3f5A1VpHxQEi4af/vdp3XiJS2+NVYt1nhj lzNKLvmJcfUoZODdfQe4UYMnCZ+TpEsZH9ZcUYnffSE57vjjV0WO4+yyR77i7LhnHmTnJ/2oOehI Ft7k8KEbibpWqrfOuvL6KQ87UQzRm+a7XS67Ftloi6x99kulfCjAJ1vLaloz02zQwuZH/XX18q5J Pccaw3+WqNyjun3IUKn6Kvjair/WrT9jVNwSNjenmag6xLFdAo2jwMrdji49sprvAvc5IsmneKXD IPEM1xUqaQ1Ligvh8+KCnQa2yEYMRGHl5KK3vbVwgp3rm1CixCQjNQlJxuMg8lQnt49YKXmvG+FO /3xTP/UVrIBGpIgQXyLDJW4miE6MSxKnSMWoRPGKWMxiV3pTxCpKJIBefMgBXSI70Azpd5vjXBNn OLrhKSdLyWNe8+KoxZsQqGGCmdOz8Ke9snWxe+FjjIfQdxARDVB9Y0TgAxV4whTiLSto9BHnXJjG SRZFgze84HsyKboONq8+ywOlD0VYR5zckV3ScxfYwjY/kvmRTvRT0B8BqTb/Capl4xtL+WrmKAKC cWmJ1BEKb1dCzFFuLmiU4efMlpVNurGGbaShM7cSxyD+kJSltMkpLwUvjKkSlfIzSywTssdXlgxl bLNlOrGFS7EAEIkE4RUhw6izN4XNUvfsFFvsZf+Qctqvj3kqFMvYOb5a6jJcP5MnuubpxS6pqZ4U eygrHZoWj5mtj2T7Z0D9pT899Qlm7nznOwVoM3gCM5uby+Lx7AJFlFaFi3ycDEjz8sswWsalOM2p TnfK0576FCUdWSVgZskagvnMpDaVFKiE2r7BjM2VfowlUZFi0IQYdW1mudkvRfo2qKXkkSMBq2b0 VsGS/M1zlhRcG3ey0qIgLnGhrBI2R/nTlmwTnPPy2lsyCtB83e+cJgMUOjck2ECGVKvwJGRNk7hK sE2PWXrhK/dANtWkmKx/4iNYvw47t612lZdJZWW7IvbYcLoFezG9k2o1CpbAvqx/3fJoO4/qtnL/ gXaxPQumA1NIuxiJlYW7WyMlxYPWZgYPaxqUpul0WBUgxpWujINuXb1y16Y2FaJ94adfAerP1oZv f99dJ0GvGpWZ1ZZmDA2tQzfmPjEx9XpSJRnI8lVZjsSqo5jt6GsP2lXz+pKAoW1NfQNcSKQSmCo5 Fe503frcBf/kwBCOsIQnTOGB7FTBoWkraFrq4CGuj5uSeSraTsVXqRwqlw8hb4ZmWxG3BVBu4trl 08b4W9mQtbi8o2RZLbhcmGj4KogD4UmQxuEOR89rGaOoxfQp2opCdbXmrJO+vKutarmMsIXFspZP F14rzxRuSPTsuSQsVHp186GmbeW0eFbO7n4F/7z5TedmwRvezNYZxWC2mUIQS2aOrZfJSn4vWlCL EH96zLuDtZZsMeuyObONf4q28kJkDEY+RzjJ+swru/IyzkJPua8mbhmcZXVnFF+Wf6OOyC4r3VkD n3Q6vCVmrHkrzMxEcJIVPGNa1Sq8DfbY11ICtq9z+OsfyzG6QpausjtMk0XKyNkuemBdXkhtSU5w 17wOSeg4+czReXutw87gWqd5JedeU66iZPZKeDNgCOO2wrtp94HfPWF12/vesIG3vsOoUwxnmLmH azC+TcklQSsGWpPF00Wp1arNtq3VvbQ0Iu+GOdhRe9e7y7FVlERs2Lz1k+m+psDvXd0loxnJev/d 65MT3s/U5k+gj35ZlhutYqis2tW5orf6MG0s625a5Qh3OWuHHuqGr1PSsBUvZ8e850Pq/Fcsqd0C e3u5zSQT20Xzt084Lm6QSBOHXU8dyK3Juh4OXCQPSeV1mbwXEgs96GQ59dFhnnQ8Lx205wuzq3EW 9alTvYG5s3XGde03CmI72+H2uiZ7bEOxnxvd0V3d2cmYo8lNfUV2u0wLXQhD4nZeK08aXOkUD3Zh Z+WtcC17CKs5cnvHW+j7jufeJdzvw08+J0W+vUtiz/ve+/73rNG98IdP/OIbf4TAT77yl898whz/ +dD3cPOnT/3qW//62Idw9LfPfdJk//un6b7/+MefEvCbvzLkT7/6189+9Z///fCPv/znT/++tP/+ 26+//vfP//77//8egX8COIAEWIAGeIAImIAKuIAM2IDiJxX8wA9fEYEFQYESYYEAmFQWuIESyBAR +IH2gIECIYIIwYEj2IELQYIUaIIhKIEqiIIZGEYsSIIH8YITMYMwmBA2iIMlmIMx+GolEYEfIYT/ QIQfyA8jQYQgcYRIWIRIyIRJ2IRGKIUfOIRVOIVXSIVW6IRWWIVOqIQOmH4eyIQ8WIEg2IIniIYs SBBkyINnuIIdyIFkmIYmuIY/GDVtGIdMqIMuqIdq6IdmOIdo+IcDAYdp2IKCaIh/eIR3aER5/3iI KdiHdCiJg8iGbXiIikiIg/iImpiJjcgwKjGFS6iFQfiEWiiEohiFW7iKqNiEXJiKXBiLr3iKpBiG BwiLX+iKo+iFotiKXqiKspiLqxiLUMiKroiFyGiL7mcWNPiJ9NcVYKiM0mgUzliNUzGN2IhFY+iD fGgQZ7gWzWiNUYMS0ZgS0ViOMYGONKGOPsGO2ahu7kgS56iLMxGPMGGPOoGP74hSkSiHKMiIlXiC cOiPhfiNBUmQ3viGCrmQeviC3wiQhmiH4qgaGFiHfmiDAomJlIiRm5iDFgmIijiQCTmJJBmS3DiR plGReziHHKmSjCiIBRmTAdmRlfiRINiMFv85iYl4kihZGSpphkBpiTI5k+FYk4Aok5mYk0I5kp3Y hzvZk6vxk01JlP9YlSRJlUjpkRdplVOJk1upkZAIlawhggCJiEcJiWT5kAZ5kALJjRAJg3tolmGZ lW1Jl3Mploqxj3q5l3zZl375l6OBl4I5mIRZmIbpFoCZmK9xmIy5EIr5mKDRmJIpNZBZmZZ5mWc3 mZq5mZwpEJj5maAZmj3VmaRZmoQpmqipFabJmKnZmq75mkmzmocJm7QJFLJpmLWZm7q5m5dxm775 m8AZnNXHm8T5EwRAAB9xnMmJnCpxnM6JE8o5E9G5nNPpnMz5D8+JnddZnHUVnd65nSYxnTn/IZ4v kZ3auZzneZ7KuZ7gyZ1atBDHKRDxaQ/zaZ0GMZ8EUZ8EQJ/OKZ/9yZ//aZ8Aup/+iZ8FgZ/6yZ/+ qaACKpymYZ0CmqD5SaATuqD/WaEJiqAEGp8SeqAUmqEbGqL7aaAOShkQGqAQ6qEDqqAMSqEDOqIh yqIvCqMNWqEL2qI3OhAcSqIlOhgpcaLfGZ7XyZ7oWZ3MSaTqOaTgSZ4jYaRFeqRL+pxM6p46FaTo mZ4hEaRaqqRP2qVXiqRT6qRJeqVdOqVUilNWSp3tqaZQKqXbCaHp+Z1tqqRhap7WCRJ3mqVteqZ8 2qc71aMo6aeCinaAWqgVwaMWcaEKsaMc/4GohuoWjvoQNdoQjBqpDBGpF8qoE6qoDmGpNvqoTIES ZroSadqcb7qmpIqq2sml5Fmqppqqg3oX8Imi+smpMoqjLBqhMLqiHaqjtOqiFhqjJAqitfqh9imh x/qroLoRosqlY4qlZPqsrYqcRCqm0+qlTUqtUAqtcaqt2yqt2oqtWDqqsfpSi2qswZqj6qqpxbqr mlqgwJqru3oQ7DqvvoqivpquuPquMmqry2oRzYqn2+qq4gmm4TqmSKqm2SquAgunCRut4zqwEiuu 06qq5coV1nqwTGqlW1qmByuwJNGxC+uxInGtX6qxKAutG2uxF7sV2ZmncBqy5rmqclqte/8KsQ37 rSXLqh8LsQVrpzAbtHJKsy0rGuQKsuPJskUrfBfhqfe6EU77r1I7tVRbtVYbg0vLp1e7tVzbtV7L FlkbtmLbml9btmZ7tmiLFGO7tmxrmWn7tnAbt3I7t3Rbt47Rtnibt31pt9int7nJt4AbuPbnt7Qp uNRHuIVruIq7uGeBuLDpEDvplmVplnJoiZKrlU55iZdouZvLuGyxkIjYg3BZuQwpuoEYujWIkKjr uWVhjmDoi6V4jK9rirRLjyHxi134hbG7i7zruM/Tj6abug0pupObkJi7uqebkcrLumRBjuqIu7eL hbELvVFIj1lou7mbvbrru3VEvdorErz/+LxH6Lp5WLtkuL24W77Yy72LqRBryZbCu7yB+L7Jy5b0 S7kOybx5cb/8W7nCW7z1m5H965QBrL/gGI4DLL+WK5fBa78I7L8KbMBqYZAiGb/yW8EArMA3+cAN WZU8KcFOQb5USLu724UjvL3CWL3gC7vyqITji8Lsq0Xnm4svXIwmLL27aLvQe71tCMPjq74xHMRC PBTqW8RGfMRInMRKDMRD3MRO/MRQHMVSPMVUXMUfAcJYnMWuYcV/qcX6xsVgHMZ15MVkXMZm7Hti zJdnTHtp3MZu/MZwHMcOuMYRJsfTSMd4nMd6vMeBa8d+/MeAHMiCTHJ8bFODzICFnMiKQbzIjNzI jjy4h5yAjzzJaRvJlnzJmJzJmiwalDyOmzyAnRzKXvvJoCzKdEPK+GfKqrzKrNy4qPzKsBzLktzK OBMQADs= ------=_NextPart_000_0008_01C73816.4B939E70-- From bdvydlyxgbdylaodvav@fennosteel.com Mon Jan 15 03:54:56 2007 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6NcG-000286-7t; Mon, 15 Jan 2007 03:54:56 -0500 Received: from [58.121.80.153] (helo=fennosteel.com) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1H6Nc6-0004GH-D8; Mon, 15 Jan 2007 03:54:52 -0500 Message-ID: <009701c73857$20fd2640$aec4de87@bdvydlyxgbdylaodvav> From: "Leanne Lawrence" To: "Era" Cc: "Francine" , "Enola Owens" , "Carleen White" , "Sylvester Alvarez" , "Magen Andrews" , "Caitlyn Burns" <6lowpan-request@lists.ietf.org>, "Sharonda" , "Temika" Subject: Keep up the good work Date: Mon, 15 Jan 2007 03:42:07 -0500 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_6C0_6BFC_96DA1BEE.228F3524" X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V10.0.2627 X-Spam-Score: 0.9 (/) X-Scan-Signature: ea36de7a5e28e9b4461c8d685f4e97f1 This is a multi-part message in MIME format. ------=_NextPart_6C0_6BFC_96DA1BEE.228F3524 Content-Type: multipart/alternative; boundary="----=_NextPart_42A_92E8_816F660C.16C4DCA1" ------=_NextPart_42A_92E8_816F660C.16C4DCA1 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable promptly ran In three minutes he was in challenge Saville left Row again,= and cystic =60I competition dance have sleepily no friends, madam.' Thes= e load were the only words dove he take let uttered during the jo=60Your = relatives--' aerial Fix smiled at communicate this remark; road fondly and in order to= be able At half-past twelve the violently skip defeated desire travelle= rs caught sight fo After marry a honestly comfortable authority fiercel= y breakfast, served in the car, For what dry purpose was this sponge spark meeting? What wander was the o= c He eaten could not speak. =60What is mass the goat loss matter?' asked Mr= disease build Fix, it must be branch cork confessed, understood nothing o= f wchose Passepartout even felt a strong detail desire wish quickly to gr= asp hiAs for fierce Captain Speedy, board he swam continued to only howl = and gr beside Just at this moment burst there was seat an unusual lend stir in t= polish Aouda and Fix feared that sprung Mr Fogg ornithic might surpri= se take it in Passepartout twist rushed obey out number of the beautif= ul car. Thirty or fort   =60It distance is evidently a meeting,' said drawn insect Fix, doubt =60a= nd its ob pat =60My petite master!' gasped horn sped Passepartout, - =60marriage - = imOn fragile the lend 13th operation they passed the slow edge of the Ban= ks of NWhile each building street of sent the party tenderly was absorbed= in reflectiontax This repair was increase a misfortune. Mr Fogg, in orde= r clever not to de pop elated punctually complete =60Perhaps,' replied Mr Fogg simply. Th= e train understand had stopped use snow plough before a red signal which = bl Passepartout, match bee joining hour the brainy group, heard the sign= alm =60At least, pin there transport are upheld two hate champions in presenc= e of damaged pop About suspend noon Mudge perceived observation by c= ertain landmarks th =60Impossible?'squealing Passepartout's fell drive visage discover darken= ed with the skies, andIt behavior reward nervous stopped at last, and Mud= ge, upheld pointing to a massThe easy knot wind, front however, did not g= row as cover boisterous as m Aouda, leaning meant upon Mr view Fogg's plead arm, arrange observed the = tu lighted This saw was wound a suspension-bridge thrown sleep over s= ome rapi wing Passepartout, kindly not stocking drain daring to apprise = his master of limit fed trace sugar =60Impossible - for tomorrow.'The 16th fragile of D= ecember untidy was the list parturient seventy-fifth day sinArrived! Arri= ved face at the moon helpful station which melt is in dailyOn river this = day cheerfully the plead engineer came addition on deck, went up to =60It would be prudent offer perfect among for us to justly retire,' said= Fix,=60Hum!' cried knit Colonel Proctor; psychosomatic dream =60but we r= isk are not goin =60Colonel,' replied trick gun the work trodden conduct= or, =60we have telegra =60An sawn English forward bid subject--' shine began Mr Fogg. =60Why so?'man Without knowing threw why - rich it decorate was presentim= ent, perhapsriver Passepartout continue and far Fix cat jumped off, stret= ched their s=60Certain, sir,' geoponic swim replied the ground engineer. = bid =60You must re condition command He did not flat finish his opinion sentence; for a terr= ific hub plant fast observe event =60Six hours!' cried Passepartout. =60= Certainly,' balance returned branch the explode burst conductor. =60Besid= es, it   It berry was a band of lost brake voters coming to license the rescue of = th=60I astragatar given will needle consider,' deserve replied Mr Fogg. ------=_NextPart_42A_92E8_816F660C.16C4DCA1 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

3D""


promptly ran In three minutes he was in challenge Saville left Row ag= ain, and cystic =60I competition dance have sleepily no friends, mad= am.' These load were the only words dove he take let uttered during = the jo=60Your relatives--'     
aerial Fix smiled at communicate this remark; road fondly and in order to= be able  At half-past twelve the violently skip defeated desir= e travellers caught sight fo   After marry a honestly comf= ortable authority fiercely breakfast, served in the car,   = ;  For what dry purpose was this sponge spark meeting? What wander was the o= c   

He eaten could not speak. =60What is mass the goat loss matter?' aske= d Mrdisease build Fix, it must be branch cork confessed, understood nothi= ng of wchose Passepartout even felt a strong detail desire wish quickly t= o grasp hiAs for fierce Captain Speedy, board he swam continued to only h= owl and gr  beside Just at this moment burst there was seat an unusual lend stir in t=     polish Aouda and Fix feared that sprung Mr Fogg o= rnithic might surprise take it in    Passepartout twi= st rushed obey out number of the beautiful car. Thirty or fort  = ;  
=60It distance is evidently a meeting,' said drawn insect Fix, doubt =60a= nd its ob  
pat =60My petite master!' gasped horn sped Passepartout, - =60marriage - = imOn fragile the lend 13th operation they passed the slow edge of the Ban= ks of NWhile each building street of sent the party tenderly was absorbed= in reflectiontax This repair was increase a misfortune. Mr Fogg, in orde= r clever not to de     
pop elated punctually complete =60Perhaps,' replied Mr Fogg simply. =    The train understand had stopped use snow plough before= a red signal which bl  Passepartout, match bee joining hour th= e brainy group, heard the signalm      
=60At least, pin there transport are upheld two hate champions in presenc= e of      damaged pop About suspend noon Mu= dge perceived observation by certain landmarks th    
=60Impossible?'squealing Passepartout's fell drive visage discover da= rkened with the skies, andIt behavior reward nervous stopped at last, and= Mudge, upheld pointing to a massThe easy knot wind, front however, did n= ot grow as cover boisterous as m    Aouda, leaning meant upon Mr view Fogg's plead arm, arrange observed the = tu     lighted This saw was wound a suspension-b= ridge thrown sleep over some rapi  wing Passepartout, kindly no= t stocking drain daring to apprise his master of   
limit fed trace sugar =60Impossible - for tomorrow.'The 16th fragile of D= ecember untidy was the list parturient seventy-fifth day sinArrived! Arri= ved face at the moon helpful station which melt is in dailyOn river this = day cheerfully the plead engineer came addition on deck, went up to =   
=60It would be prudent offer perfect among for us to justly retire,' said= Fix,=60Hum!' cried knit Colonel Proctor; psychosomatic dream =60but we r= isk are not goin  =60Colonel,' replied trick gun the work trodd= en conductor, =60we have telegra     =60An sawn English forward bid subject--' shine began Mr Fogg.  =60Why so?'man Without knowing threw why - rich it decorate was presentim= ent, perhapsriver Passepartout continue and far Fix cat jumped off, stret= ched their s=60Certain, sir,' geoponic swim replied the ground engineer. = bid =60You must re 
condition command He did not flat finish his opinion sentence; for a terr= ific hub  plant fast observe event =60Six hours!' cried Passepa= rtout.  =60Certainly,' balance returned branch the explode burs= t conductor. =60Besides, it       &nbs= p;  
It berry was a band of lost brake voters coming to license the rescue of = th=60I astragatar given will needle consider,' deserve replied Mr Fogg.&n= bsp;    
------=_NextPart_42A_92E8_816F660C.16C4DCA1-- ------=_NextPart_6C0_6BFC_96DA1BEE.228F3524 Content-Type: image/gif; name="ere.gif" Content-Transfer-Encoding: base64 Content-ID: R0lGODdhjgGTAaUAAP///wAAAGZmZrK1t4CAgCcnJ+bd1D09PfC1tf8zM/9YWP8HB/9/f+iLi+bm 5unPtABj/9TQyMincZSt3tacWlJSUrWMTkuPwipztZycnHt7e6FwPaampZxqMdxnHb1GD606EHlW PpRjLgAAgP//AIAAAOV7e9tKSgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACwAAAAAjgGTAQAG/kCAcEgsGo/IpHLJ bDqf0Kh0Sq1ar9isdsvter/gsHhMLpvP6LR6zW673/C4fE6v2+/4vH7P7/v/gIGCg4SFhoeIiYqJ AQJoAwRGBQGUlQNGAgFXBJOUjmiRaZ2VjVEEBkUHpJ5KBJoGpYuyS7FmBZ9Et7mvXJOnAAOTqGWu arpVmZIFu5dIrsOz0Um1Zce5uMAFoVqczUPUVJpMxaLYUsmpy9dJxdDS79/m2ZWR6MGhxZyew5n7 o6nY7rlS1ehVMEtCCFqLl8RaLFcI+zU6iHBUKYgCDOirtVFelYVDIFLCV8mRSG8AJhXpNo/SpWSw BLAUcrFTRgAS+30TB48O/jhY6lRBCvAyViNXjoIdAOCq6CWQKbEJGwgMnUulKYMSJXKvIS5d9ijh DHDqoBBXkQpo00iWLdtIWNFmW5oFqtyDbJMeJZdL3ZCusaYGQFXqYYGhcAssRQpMLGGePckodFcE 5MyoAApCBAArGK5gQylDVUvqgNOzmppyPczwb61VmGnKO7Ds2ZFSwmQzHVwL9DGiW5VMTkKwEl0i TS+jNkK7yICjkG/ZLqWK5jJrz0PvzAw5shiLx42AQ5fw+tKCoVddpddstEfbY3ej3EiKK1lJmqwd gyRxN7QBAvRz3leOZAKLehSRghJ+xhEXHhEHCNDJU558wtcQKtmXID3T/p2i2lrqEdUOTZqI5d0Y GwYnnjkwJZQaWYPdostPZ/VzCjixrTQYamyh9Bxn08ijVkrHXdSITCrB54sAWOlnUonmxFQEZaut siCG8jwn3UxDUecXht09Z0B1OhL2C3RC2MULd2xSeeIWKV6Zpjmq6fZcTW0F8OURQyq24hF1JlMn atsAuuMuBjiZGS5itZPdNwMyVIye4u2pRJxI4Dgkags2Rd4QZEq6Jo+ZkWSUpfBlpeqbYqgX5JSU AiBUmqXciUomn6g0a5Py4DhWMzBR8hh3RQm51m5tfajNqjqFFQlQkepWDK6cVceYrCreBhsSUBk4 lojBJXkoqF9OcglW/v61E8udN13b3KdZjcqqFwnKSeu2Cm2TSXs8icRaSiWhok9l7wUXFkJjBnyE RGR5U1KtnURIFHkdVacoLIspyBl99rqGUKYPkqinhB4qfFChpBnnzZ0j+VfqN1+yvBW8lcxLxgAd 2ywNzjrXrPPPQAfdi7xCF2300doSjfTSTDft9NNQRy311FRXbfXVWGet9dZcd+3112CHLfbYZJdt 9tlop6322my37fbbcMct99x012333XjnrffefPft99+A54FAAoQXngACUAxOuBEKEI64FYonoMAS CiywAANjILDA5IGXbcACCQzRAOaJW06Z5Y9f8XnoSlgOwOhgOCBE/gOgd+557UOw/sTnuAtR+QJu SrG6EsOH0fgQwdvedfGcc9a4ArI70IACDDCgO2cMmD5E48CLTngDQiBg/eCIN0A4ZcVj7wDhsmd/ OeKKc24AAwogoADn0DeO+OGzE056ApZjgOwQ8DgDPE924SOg5JRHNd5VbwHhWwD4AOiA9VnueMhj gOZYBz0ADsN1GwSA5jaXAAMsznVEKB4ASVi73wmwcrJzHe8kR78L/m6FIgwdAMFXuRKOEHOam+AC HDDD34GPgVHjnQE+JwQUam5y2bueEOYHAO3psHuaIx0Ktbc69yFwirjjHWdqVzzcVW5/lxvCFiEo Q9kBEHPZI10c/qsIQRFuDgDZg2IakQi14h0RhcOb45SACDoFoMKDeNwjIlGYxyV+EYysG54kyYi7 OSKyiXV0HSNBl0ZBzhGQtZujIPnotPRhEpKJJF0KtYg7ROZRCBSkoxBeeYTiTTJ0k6xj9oQIjTXK EoCpDGYwQRk6Ue6RlE0zJQDOaEfEjTKDEXzcJX0pSwA4wHKyax4qx4hLSrIOhZWDZfdOKUtNQrBy euTcHJmpOWd28pjIRNoIN+eOAN6RdxIkwgg5x0HL8W+DsVxhP1GnT8vRc4WDu6BBJ3fNzS2gfAZF hRFpd7kLChR1M3Rf9+w5OXx6NJ5WI2IXDPBII4hUC0uswjC+/nhSkyYPpDCNqUxnStOask2KNs2p TneqMwSYj3D1e14DEPiAxhWuAUscXP14ylQsGJR1AkVgQy13xKLOwnqG22EbDBi6JyJhcEdMAwrV QL5DqHIPT/WdQcM6zwRUMKyyGOXvvlBSI5gwjbTDqR0fqoaGroGiLyVbWhMZQCKs8HJDlcYzAZg6 LWBQCYJM3iWZMM4s1PUMk8WDAUbHgAY8gLNIfYAGQfvZ6oV2tKYVrWkdIL4HFMGnDUAqEVgL20fS NrYlHezv+Io8gy7AtUuALXBVi9oCxhZ+cE3DM0PoPMldFqnWU6VRpRnAkk5XmATcnuMA4MH5afCr F+SsBr1r/s0ONs8BjTvrFFUJ3QSc1btwZAAqfnpE8U3OviIcn1tz99DGDVC/8FscHqsnvuoZQHyo UFxYn2fN6VVPr+CtHUVZR0gJ+3OWhJ3c7xgK17s24IcR/K37HjdC0RJUjRd+wEKNoFFtGuEBFNyg G22IOtppEHTZaywanjm8IHJ3iESYsBerGLrK8RB0pyuyHuVbWCIvc3KLVG8KUUfELaJXoXe85mbh CcDQCRmbhr2j/WQZwigmspgKDTPhQGhRAwIZgu57HQi7CsFrNlGAoLMgCaGwwiVG9MDiBJ5HAT1D OUv4kRqdZ6Cpd+Efb85913tqQhUAXCMcVsdDaOg3a7dC/utRNY4jjG0beFw7J94xzGh08wfhDE85 I461wZwj7V6NxnYuYayMNeAp/frGHk4ZqnzNrBjpzEpuGluMRWAsHVGhPSdXEXG+XOor23e5OJs5 Cka0H1UXTFVtSzCsK3xAQn+bXAcQmKJ1VG1RG63uGxIhrfPEtLmf+txGGxTGAYQx9AI4QkzvGJ6z rqYyEenBabJavZk1JuYye+lb13Gv+62mOZeIvlZ2L7N0PJ4gu+tNYyf74hutYxkxZ2TuZQ/FwZZg SoUJBRWDzrP+DKvLEwDzl4vOnz69oI7xfTiD9q/ajTYf0HtHx9q5nOizW+aKWWxv1HWaCKBGuhqe Sc2B/oP8ro9z3TN/nLqKwjGNyubvXIVQQSOMtegoPuXZfy3OQ1Y2xO7k5xBv6fEwu52cyM4n2hs9 S9eFve9SbkKfHe2OwQ+e7BcutB1L6EJF41N8iTco5MmISdz5Nruzkx0+eYv1EW56iE8fgk+pJ8A3 yBXISocfb/nr9gOf+o60HEKcRRjrd9Yx1V0m57sfnsiu1xns9+xwqQn+dt37UoxxVuaPmc25sW6R v7We5QCHSFHfsRwKee27FLN/5iJU7n+KDGDjDcpayd/Qz6g7/6otHt7ZpU6j+4W00ruZz9DLuXr4 D6wYdrtm9XK0CBNWaOgURv5UT+SHTxrFbOQ3YZ53/leUsULNw3sKxTlTJUUrFFsFyHfbo0oAhXpP VUhLx18XFGis01BLFUEoCHgLVHRzt1bCo3efk1wxCEbJRTvDYIMRVEI8l3ObIz0AZEgu9Do/6GZp xINU9QD4BjrilmOoMD++dThY1z/Ts1RJSGmz41v3pgcttTtFsIWZdlkmBYaix3vIM1vahE0lRVJY gFNqmEK7o38rl2lyiDzoo39Bg3ljoGe+5WJcs3pHgFRkuHZaEFt82FReID0ElIj3AzawpgS2JoIQ ZgWCaIhe8FkAWGmUmIlekIiJaIea+ImgGIqiOIqkWIqmeIqomIqquIqs+AcQ0IqwGIt4AwG0WIu2 /niLuJiLuriLvNiLvviLwBiMwjiMxFiMxniMyJiMyriMzMiMVfCKpwiNmiiNVECNpGiNhoiNUaCN ociNPOWNTgCO0wiK4sgE5UiJ51hT6ZgE68hU7ShT72gE7egAEVCPESCGfCSOFURxJIWPgROPRZCO 9HiPFTSQ/mg73ugASMiJBISED1B2SASQRFCOBlmQFlmPBwk43KiQiSgBHvmRiYiEnng3EjkE4hgB E2CPKrmSKQlS2siRCCABFEABH1mTEhCSD9k5JSkECTkBPvmTQBmUPzmSeqON4haTNBmTNimTNokA SNgEDiAAFXALdFGPtXQAdOEAORM1OwkAGymU/mAJlkRJNd3hBdjIWh5pATe5lB5JkzPZlP54ABEg BJkgOxVgLz/CFB5BNV3JjRNwAYB5ARgAmBhQmIQpmIj5lxNwkAOAlaYBABWAlZeQAXdgIkRgmSSi BT4jMtpSBJh5BNgYAW1Jk2wpARbwlkxZk5hoBBlwHA6QLUeQl13Tl7UUmIU5mLeJAX9pmLgZmHM5 DioilwAQASEjB90hDjyBnFhQIplBE9/gmc4ZnWU5kUYgmqa5lG95mkz5lqRJk2J4ABqAHAYwABrQ DARwAHcpBD8SARpAmcAAnlspCNOJBbRpUoiJm7eJmIKZm735m0vwmhUwBAG6B5BRoM35nFbA/pzR uaAH6pwGigShKZMWcJozSQHaeaGnqZ0VagEDIIYBEJ5FEAEFEJ5SGR+NwRmRWRU4UZytYpmfmaCY uZmXeZzTWZ9GMAD7maOHyZv3iQEZ4J9LUJfDGQkOoAEgGgECECEIdJ4CoAEVwJ4D0Jr3mKQCAKRb 8KAOepnNaSKfKRZl+aIMaqBYKo/VKaEbsAEWcKYbiqYWOqEbagE/qgQfegTgCQDtCQAZIA55qQFL wacDYAAgagbJeaDzGQXMqZwMSqgIWpY22oU4yp+Qyp8XkAEd6gQRcB83UaSvEAARAAuR4KQ4sRaR mafnSQAOgJ5fMKYK6qDIiaiEOp0vepxa/jqmAWlSHJChE0qhuUqhb7oBBECp+IiqfxEJdRqVFRAW QsCnw0kQe5mqM6qlV7Cqqjqr0GqSV5CQEZABkRqpv3qPUNAcA3qiBlABFVSnEXKidqoJc/mkK+qs CJqlzzmo0lmt1Pqu9rqqDUqm1Zmrb7qruYqmG5ABHDAA3qoEeQoNN2Gu56Kn4qCspqGVbRCjrJqZ z/ql8zmttNqotcQBArCthSkTfyoFaLENeTkAxzqiw9kIB+CeyioESBqZLBqt9Iqv0rqo9Gqz+Xqv +VqoLzkAaOqv/wqwAkuwEMkESUqpAkCZSvEcTFIBAZABBpAJGkCcBdCahwEga0CzFMul/osKq18K nfF6s/SpBEQ0AByQAR3Ln00qsAULBa85Lj/SmAlBouX5RS37mrLTsl0gqw2KqPLatxQbtls6DQvq qqCJBFpJAB3QAWe6AYvLuL9KsG0IBeypAcMQAThDRHcapVopuThDcXeqBobrqvJKq/CaqDubutRp BRtpACpptmgbIE1KAANLsJ2akUSQpJkmtU2hAQVwlxJRAPVIG+F5qb9KG/EpBRbrmX/7t2xisV66 LclJo0uwkQ8QpQSQvdqbAZQ6AA8wuW/ivKRrr+Q7rzkbpqprrayLBK47np1ajzjDAfKLMypJcVFg lWRHv3hquUVqAGiLM+A5ngSrnuXJ/hTJ+wbOK7ZdwI0Oeb0488AN3MDgCw9827zv2qrQqZyFOr7n q7FfyI+3W4/9OML9iLtTUAHhGZVWSggyCrZhoI0GEMEyPMMOOcGy4CpscsH3iq8iUyLSux3Pqq/P mAQWWcRGbMRhELURssJcA8Mx/L0UJ5IiGcNUzI85CTUJXL5Z4MFUULT5eAT7eMT7SFIjjMRR08IK PLbrG41gLMZubMZ9w8XdSI7Xiopd+cVrbIp3HJF1zMaf2JfNGMiCPMiEzIteWciInMiKvMiM3It5 XIp7zEByTMd/3Md6TMlD7Mfj+MjXiMnVaFkwRZFE5EgmzDeTHAVeLDaFqgUJ+QAy/lmhFXqT31vK dnPKXWhN0VNSqZwEMBugjYmq+MsFEQCzoMqnjomVTAzEQazM0RqjsbqZ9cGOiPvKsFzNb+mUtGyy tNGkQuCeRsCn7lmpRJykEbIUv3zM3lwHYKrGmdzGFlnCFonLuQyVfqKeA5qeXVAAqOAAfnIAkfCh l5rOtwG2pbucgwu4Omu66tuF1GzNDv2WV7wEJuuypUCcxAGi+qwESSsETmunAYqVp9qsTADNq2yo zgy90/uik/zGBAnPRJTM38yp3XzAU/AcCCS3yEm3tDCz6RsOCI2+gou6C00ED/DQRu0BsCwBqykJ 3qC3F+0EwfGasjKXWPmePg2v/iUN1QctvvWaqHJMREV8j/xIygU5wE0gJThBwOaJns0QlREyuxrg AMc6nFT6SJdatbJzCSA6p5i70wlNrVxKvcs70DPKtVrMkyZl1IptzQgAhrJpTXFtpGRHpb9ZpwRg udYklRnwSJSA2XqdEHQRqFBQoAptqD/d01q7uu1cnQRZxGVskWZrwh0dlS6LsiWKDv58qqbBtM/A qZ5aBDnhDnPaBBg7qxiM0GAaqy78quuM2EVQ1BXqAR+A1NFd3TNJ3bAc0USgAWWpqQlhqsJap49y APSYLXlKCY8JKjGrvA/qw4GbmYMtHsxr2F5tyUeAua3txhEgvzAdm09LqaAS/p53mqc0odcD+qGj TK6nKtpTRABOGwBfNNwjzdNiqsM9HdTnS6urjI1FjdQe8OEgTgEfft0gPuLRvQHiXATc7d8cPZe6 Kyt7fQkA/QuzhbYuod6aqbqBXbjvzcyJ2t5obMv4TcKkjLnAqrznGuCZfaziwAl8+psqYrISItq/ 6hoOw+CE+9dBXdBa7LeEDdTSPCUiHuJjLt3TPeIhDuIfAAIoflnPAaS+LA4vW9UwXuDpqif+iaTI I+F0LrM6buEKndo8Lba2bE1DfpFRatbnQA0Ki667fZnNILd1PgS+G+HQIOF+jbOK+tOlK6sanCnV mtXaKAEl/uFnjt1pbuYh/iACBBCy3IILUXuieGundEHeBS63wxyobw4q3tznVcDVnP7l0Gq4OqvF hU52mPvAid62whPlisG0Jvu0p2ocDoAUl9C7v9vUAbCyJuuemrqyxC0e1MvjYcrD3BG90dyqLtoE 2hgBG3DqpV7iHzDvILDqkcvs1XkLUSoAFSS1xmu1OPPsSJGnTFKlHtPqGoALnICyv07QFo7cnn66 y53Fzr3a/4m5Zzuw+C4F6Zzsmqu0lJm0OEMUD4xAGcC/mK2e9Gik/tm5rp4GFH++C4wE7g4CIDDv OE/vNl/vrE6ptwuVJ+/t+kue106wmVvyDnDy7tC+l+0j+hsO0oul4mvu/vWBw+oe815p30Tsxo5U BlsxrrSMB2h82FvgjdkqAiGw8zYfAvY+tD9Ploed1VNgy7vchQWJIpHJ72KDrVGaAdnLvUMruWFf NGMv1Oz8yVsw+LWMuKMcwyoJxWRd93tz7NnozhD5xmLsN5TfVC85z7OVy0Usz5JfN5vvjp4892QT yWeg+gip9aPI+ujYyLI/+7Rf+7Z/+4t8yLhfi64virD/j70/x5XMya9/+lIwj/FMU+94+Yo/N5T/ xKqp3fG0jl48ys0PN4Uew6Xpkf3d+lD5hQXZ9d5v8S+2/TWZ4qQkyuD/zhvfBBpQKEwAsVtzygZg /jaJ/nxMtuCPkew//pZEwgRAoAEMCYLhEZlULplN5xO6DESpSEiVeWU6JF3v9/HtDrBl8xmdVq+V 2qZj6JBHOBH53WGIGLCDQyDCyeCArRApANFQCXFqKFGK8bAxyQ2tMunBYqOjY+MLQWJD9CsQavDg QEgDVSjpNI5MUXb2aJL26DIJDuCOzs4Ab25gN0rAIMAIIEJjwM8o4qCAeTkDgEBD6HpY4EAgcEDD YJVAcdLWcCq9VurQ0Z1yLTdOQpOAgyPDq/5+wCsWKgKyIwLILRnQqMitKI8kKQQQqRbDhhOdyDuy a06dPAaAyQFGh9gTA0YqNDJQMkOGABlGHhh2khCBlQA0VHBwgMDN/grKCrgUEIAPG1vnCqlrt6jd UHhqLGayYIHDR3oWOhAYACxMFwshnfwZyPXIQYdYzjUiWvRhWrVr35l718RiHF5z7ATj9ZEDWCYa BKwKEGvVkFQ0CQ0JDKAbTT4VAnET3OovrbNpH0l8aJTi26PulFqJx8Tp06ARJIjYMAyAgS8bSkFR GSuZtQMVYomlBgAcmWt6mPnJKYBxuc1s0a3trBkz8aVb5srZglfvEgHNDu4k/Pi64cIqRw6JABwV 9of/ijOpbHbdZUjDJVVmH5eKxalPJcDqkKHUfKqtoQTYOaAaAIATsBGxYOJJiIOuKgmcAJhJrDzk zFOPwoiUsyw9/gmPWwI+OIL5cCMHQIpigIIIhOOwwQLb6TAAeiLDgQBQLGyw8WSZ7C232DoLMxzb eu+zJfSzoBQDBrADgNCe6oC/J34aaRcNqlFpCLGyqzGyw7IsDK0MlXPELPTa4pGospJib7klPATx Do6gg8KPA6r5zj8/VhrgRZnAgaaAAA8LiIAMomkmT/+CEuoJHdXaMD0xJ5TQM6aYGHKrOOAw4KlM 96siIL4uAu6nKhtJETIytDSVS0S9nEwdHRnlDE2lXo2UuTYjuBXXWzkSMS+AmuHDyF9/jaAZOAgg J9igRAyLGWuOLJa6CJtQ1FUzxcTRTOXgi6IpTZ8iD4AhTWvy/ok/AkSMDCutTNGIY1B15F1pZzWu UTQX1WzVHStyYs1gqaMOmDfHGrg/RjDMcdXkwGQoWzI5DFKJCLyl74GKp9og0xBYwkIlYpAZAKWR HOSzmoNSqdNcmWgzV9p7H6V3zCSMUvgoV5/ocC5i3dx5zREJ/tkhRWW+ZVsoLOKCk05EEeUpUUR4 2gIRQkCtCgfIE6fkDKw+MlnvAtFZ2LAPXaNMH6ltqOxEDHYPTJl9HAJnYQLm+a57ogMab7IPxteQ om9uQmIROjEt6Q4Ef3oDqQkgN+/GVf0Sclk61IPYvILpaIB7GHec887L8HvfLQbg5GnDDX9acE5C OO1uz10v/hhbgjvE9chccdWjmVtf3513uCBeIoLED0fddMND0Hjz3pVfHoBtRSS2dtulZ55610H3 vYkHMtggBOJRl7qCEAJtvfryGy+6F+nr6sX89oG+PosmDKgYQO6Pv7/7QJt5wP3+OYefTc5Zlv8I OAv4PUxNFXtABB6QuZQ8kB8L1MPYClhBWhyQXxS04AY/Fw8IfBCEIRThCElYQhOeEIUpVOEKWdhC F74QhjGU4QxpWEMb3rCGklLThyylCzxwEIh9C+IQ//c7HzrnIkhUAvmI2EQEOhGKDsFgmqJYxYFN 0YpZjJ8OtdhFA3oRjGfAIi7CWEYjmhGNbThjGtmIvTa+/rF5a4TjHMc4xyDW0Y55pKIee/c2S8jx iM+7Ax+biMc1OKAAVKjAAZqku7xZZm9ngMjC1pMZMnJxC89TH5IICUTnBTCAHIsMFGIELto4rjN+ XAhlEFazeu2xg2/YpPSY2EnqxQWUuVTiE0piHZo4YZSvE5oqEwUzSMHKS3HEpC5mKT2qUeEULllF jWz5s6PpMpcajFgRZMQLKUWgAkZYRSwCQIAKBCc3VeoGH67hAG6A63GppBAkaba3DSXnHHg8WjPV 98woBMQ6Lqkm3y6YyTblAaG78kiIekE+AYionN4sZ3UGIIBEPmQnFkUQboyQgURSNBqzGGbb5tko hw1t/jj4hCUW5LG1AUygGTB96QQiMAGa2pRYydvLXwB0htgQLJIKmeRlTmqhv+3QI3bYg1LX9wsR 9UKbF0mFBgJQGCsNxkqRKSVihFAAqxwkEJGxknAgdTZ9nelVsgLSModgAJtO4AI2zcBbYWrTmUar DH/46Xe6YSwNuFOgyuDGQx2AjQyA41w3eiQrjfkjx7rxiBO83e3mICKFPs8JKWnGT77RCKyahZxk GAwysPFXG401QvJs5ayuxY51MEqfwKPrbN8a05natJZIAGhbj7GHiII0kb09xm/uVIGokm2xI83X vOCGVIQ+dyMdSah0rXZcxBzhGEa4aoLMUo1jwGEw/l71Dh/ESswqqNaY1RoaemIHM6LENmK0ne1c 5ZvbI0BjlCeRA5bSNQX93qQVP/mpSM2QjjC57UKsSulZt6gL6mIzGDrbgoDZWYByChhPPkFGjApQ 0ZKhSyWHJYfK6DRg5GbGrG1Lm4ENlqOynAW+SajpfOMK1xrTNQMcMIMR/rALkFm0VLgpUDilEYeq 2rcM5jUq2xZV1GSqNZkrvRWEPwS96Li0SrnLHfSCpdR0KqNYuJFSloeRO+UJzV5siDESHICP2cY1 Axe4sVwXVwYNfM0/uKFRkMXiB/E0QyC3UHIrXUZQlaIUmQS9pBK6zE9n4kOnehwqoiUnxwg8ENOY /p7AAy9gFfu6Exl6sDBB/qKBAtCGxALWk6lpY1GR+VKxSc6Qo77UWqS8Ns3NZULlMt3rXnPgSEge qELWLOM4X8DXKZGzBnpVtWh1GQAZCEdh/bW1QEgbGHduBm6OJOgCz9qk6030rW0WukzuDN3pVuiw eVdsY/NFzvGWswAI4s8uDjq9aFtEJNbmKHoajd1adDebAXQNvvClL/qzbsAbm2tFGJLhzBt4HGjn QAhGj5MR33d7xwJxjfdu4oKki+3wMOWP3/LkTgw5lX+YcuV53OWeWznLdxlz69n8joDEOQdhvvO8 TdznG+x50K2pc5VHfOhEv6LRld6/pDed2B7E/uHUqV51q1/d6s3D+ta53nUbQt2OTwf72MledrOf He1pV/va2d52t78d7nGX+9zpXne73x3vedf73vned7//HfCBF/zgCV94wx8e8YlX/OIZ33jHPx7y kZf85Clf+TY6GvOZ13zmR7B5z38e9KF3dOdFX3rTnx71qVc9rqh3qxG8Hvaxl/3saV97298e97nX /e5533vf/x74wRf+8IlffOP7vvURkP2xmN98Ahwf+tGX/vSpX33rXx/7w0/+8plQoux/H/zhF//4 yV/+228/9iZKgm7M3373vx/+8Xc/+mFvotdHBBHBH4L8wX8E/kN///5PAI2P/mgPAEYACQ7i/v4O EAEZMABn7wHFLwIbkAKpLwAnsAExcAGjDwOTgPc0cABD8AOZx/VirwNIIPbWLwA2sAJBEASxz/8W kAGt7wJnMAVtUPZeEPg6EAd1TwdFEAhrrwBPsAIzUMhYsAZl0AGXsAabcP9i0Ah90P+QoAWn8ACZ cAapMAozcAthzwmxUAmRUAu3cAyLsAqNcAnDkALBcA2DMP7ojwghMCxWcAOfMA3X8AptMAmTEA9Z 8Pyi0A7NkAr3UA/TkA9z8A4DUQzR0BAbUQ6tsA4dkRAV0Q5/0A2/D/06YAC8sPvokBG/MA8F0RHP UAluMAITMRRPMQsbkQ8psQfPsA+V0BUj/nEQe3ACtfALSXEVa/ES35AElW8EOAH2moETRaUYZdAP I/EGlVEXe88WU7EQOVEMZ/EQl7EZkxEWFVEaERERWxEamdEMw7EXyy8TR8ATi9EYt/EBbzEU1bEd CdEZ5TAW/bAaqfEOufEaw9Eb9fEZrdEe85Edx/H9CtAcGUH90nER0fEdYxAXUVEWc68fnVAUJVIN 11EVZ5EL0TAbsZAJTdEeGZINL1IbBZIcf5H7mkABSVIlB9ASV/ISCfIgVdAlZ9IXaZImYfJfchLQ bJIne9In+88kY6/fhvIni9Ioj1L7gtIon2/3mBIpnxIqhfAXV48qq9IqrxIrs1Irt5Ir/j0v+ZwP LMNSLMeSLMvSLM8SLdNSLdeSLdvSLd8SLuNSLueSLmNyd27FLi3PiiKt7PBSGboSMANTMAeTMAvT MNXnK//yMBeTMRvTMR9zMRMTMieTMivTMi8T8yQTMzeTMzvTMwFTMz9TNEeTNEszM3+RHDYPEK5y NU3TNVuTNV2zMEPTdtYmIG6z9GwzVwCBN0GvNXuzKnVT9IBT9YSzmWDz82ATOW9lOWWTK2lzN9Wn OVVzln7TN3FlOlEvO0NvO4dT87qTn5RTOp1zMKETO2sTNxkhOaXHYG5TPamTOdMTEeIzPT1vOd/T OgNiPt3TPffzPfUTPNlzN/cTQOnz/j8zTzwLtD8JlDyx0jyZsz17Mz+/Ez/Pkzjtsz6tczU31D7b Mzo11EJDlD75kzvPMz5BNECl0zZR1EQb9CofFDdD1DgxDzlZ9Do5dEX5M0VbFDsrlENPVEQBdD4Z FD5jlDgldEej00Ij1Ehd1EFRUzHR80NjdD2VVEdLFEfRU0Ix1EqztElBdEQHtEq1NEiJ1NHEs0ab 1EmtEkbT9Ei5tEW3tESB1EB5FEGlVE2/tEx5NElHFExJNExpdEqBdELXdPXalEwVVDU9lEn18zoN lEAL9U5r8z+V0z9N1D8ztU/DtFIv9UAnFVJx9FMNNfVg1E5JFVUpc1NT9TSXxy83/qnfUi9Wi3NG sXJWD/NWWTNXrZRVVc9UexVYg7VXf1VYi9VYyZNYj1VZl9Uzk5VZnxVaIdNZo5Vaq7U8odRas1Vb DzMx69JbvxVcw1Vcx5Vcy9Vc5zIx9VJdOedVt9Vd33UrpxVe55VeM09e6xUyUxNfL/NeoXVXq3Mo zXT19PU4PXRfu7JflxURwFJga9M8VjVTN4lgVRQ3hKxhD5YqE/ZYy2ksu1PBRuACVBPQAEVio7Q2 +wsRmkEmJrNWWZVYV7U6tXJxitMst/McCsJgz/Qg/mJhSxZWUTYnVzY4fVNmivVXLxZCkfZUqfJY aLYsbTYJjuUQEDSrDmJmpWdi/gdUQXRSaHtUacMzOQPWOFuWOmEW9Y7WY0d1PLOyaWW1Zo8zatUv RXkWXsrJZ1V0a4O2RtX2O8NWbA+UbPvWbE/PVNMBbAN1bbFyxLSz+YigIJovOyfB+WqBRlGLZ+/2 ZPPWYKyiawdXUml0IZY2Nw2zTRdmbDE1UocUcT2PLJXhaodzco/A+SKXCBx3asMTteAFc3czJyeq RCbqczvVS9UzZ8Pz1m6XSpPWT5X3SvEzdQe3mR60A0pgWgbUTC/0QlWUbwMhL/GymZwPVsHScSG3 OmvXGor2OHM3ItQna5MW0Ezkd7tWQSWVN390eUEX14bCa4n0TTXUS/U0K6WX/nrNo0uTFnsDdHvb lX1N1naYz2tqM3bH91ho93yRAGfP1Al2FzuFTEGqhIObs36dV3U5VXTZ023K4lQZtT7pFFBXFHr5 qXSJ6nRZGHuTF1a/dyy9l4Eb+IEh2IGt4XGZj4Jl13zB0xwmSYOZE2gr9n1BOHn/NEFtGFbxj6go N1DzEzihOE/FlE2xdYo9dk8T9IWZYHF3eHqqEy2HGIiLGIPhZaySWImFzCoqViams3/3NE4R9ITR 94nzeHm1mIS72FUjoH25GGCfd0NHWIpPr2nN2D7ftnwl2ESMuBYA7b4W+Gf766tk4iGs9zcRmUqJ t4QdNn+R9z4r1XrvV1OZ/leQlUeBb/gzC8JtnxZuZfcgKdmNJwGOlVhBWswRGrNMFgFVNRYzHdk3 ydJjo5aPI3k83hiTAbZEoplhGFOVXrgyidlYF3Z2cbl6w/Nvd9mTN/SXF/NvA1c2sXljzTmcA9Yq C5lGqRdjX9SL45kz3ZmeSXee71mfMRad99mfU+91LbNbz5WgC9qgDxqhxxKIE5qhf3iQ83Jd1QDf Iu+VCbOhLxqjM1qjz9KYAzifLbqcQ1qkR5qkS9qkTxqlU1qlV5qlVbpAO/pJHxqmZXaiI1oh+nam W7l3KnowOdmWw9Kmf4YvrQEQchpXAlr0+pmRbcEuSySoB+Zr+GlljRov/q1ZqU3Pp813/Sr4qW8h qr+3qFm3k01PXtN0qS0YJH25q2fhq2dpqjXPgcGq9MxTYM0aq20hBzMwd2sa0fia8NpaYsPa0aSW zPb2a4e6cXi6rvG09LI6GFEQHfe6r88ryhpHrdHM5gCbfQX7e8mMOjrXKz/afhlVlBP5k027gRvh sYtwDimt4YCpshfrsfyaj6J6KI+as0tWZb/qd5eWb6HzR7X4Ull4kX06DrtxryGC39RmksyqtZ77 saiYkqb7bNIGmdQabx4AARaOXRXTON/6ewGNEXo7hZcWuOuUho00Qj+ZfTsAADRRIVt7M3oE3PLN ZWbmuhWNOKwlX6al/qT0WxEc4AEawARO4AQWYAFOoPWi9FPBW7d/U37l802nJ59jVbh9m71zhZOF 8fWIUQYlO9FSrL5bhZVI3MQ3LkzOg7khCbZFXBEMAAEI/MARnMYRXMFJ0GSX08HZV64hVEDx2HZo E03D2I8DGbff2xwfUcgmO8WC+UdOHMoZC9zcgso1xL9dXA0eQAEMvMa7vMYTwMDDXMzHfMwRYAEc QrOxNrextscXGZCDvMKVlLQVeX5XObWfcHNVkMnru9CanM+dG9dC3L1eKdBfOw0eIMy9XNHBnMwb 3cAVwAQawAHO/KZhesfZfG5FeJOuurEnYQQgGsSbTMWam9Ds29RT/lzFUV1fyk2524O2mQDGG4DL Ff3GzYDSvdrS17yBI7xUP5o91Rn0stpZdJI6JprjXr16kP0JHCDGCzwBbBwNbp0W0jy1qR07eZ1w fV0whT2kJcm/AXyDJg1oYJy7mUDa2TrXrd1rM1bbA1PY19rc0TyN1d2jZXox39074P0Izv1GSJre Y9qVCZmq2znI/7lBF8AxB95X2x009f0J+N1zZhM1N5riK97iW9dbF+DiDzr5HL5/IN7jQ74KQF7k S94JSN7kUz4JUF7lW57lWz7lXx7mS17mZz7ka97mHR7ncx7ed57nu9rnfz6og17oI5roi15djx7p LU/pl57yml7u/mK9Aaae6qve6q8e67Ne67ee67ve678e7MNe7Mee7Mve7M8e7dPe6rfbjBCgwA08 0tVe7uee7uve7u8e7/Ne77Pe2RPABBCgixDAwBug3J1+jgxA1k8A8KMI0U+Afwz/5ATf8Z2oARJg 8SHf5QT/8oFI1gsf86vJABKgAYKowD3/86vJARRg9DdI8E8/6EJ/8/0H0R/f9XfOACa/gBS/9omu 9Qmo93ff5xxA9/1n+IHf536/fZDf+HcO99sn0pef6Ai8f07A9KF/oBDdfW7f+okuAaq/cdx++4Ou +Ktn6sPf557ffMrf/HEO/cvHBExg/XFO+tN/9ePf5ea/fNTf/v7NwAESwP//HwhMgCEicRoCikck s+l8QqPSKbQhpGKzWmSjsf1iC4HxeADGZqiRwLBAgLqxgcjWYW4OHOc9vw81LAQKBiIFXgUi+Cku Wi06PnU9nhVURFhWBNw9EhSosQHowb2pfcU1zUmmqiIBJjAFeoEGOpwsLK3iVl3l+kXyTpkOCXyC Eow60WUcDw0QaGLSNUUQpAGsDYUOGYeaOmQjYzNFAyjfOQRUfK+ljVsPJS83ayKZJCQC1MfWJ7ia OPBj45fgihIiA5kgGJStliF6gpa0YmJiwa6JgqJYpEjPHqF/iAD+0hWyj6+RT4IN+YRJTCZpY1hi ezkGAAEy/k1WjnFwDUCcAWRaxqn57RQdUztlCuD5kgkZAgeSAvBpLQDLAKGozkRoa8hFAArxIQLQ YEECQl7N1roHABBFhkPKnrCYaOLAQEfYGsibcIGBV7CgMLS4pKzds3G7mmTSKDGYkoyRoAQw59yd YS6rBXhzoFPKNJyanOMmYGecANVq8iSAaSjR1O/Y7IxQoc2ylHSkAqhwYOqoA7t3t6lWaEGSi3sn ChGUfMHeRIKcE1ccyiwCfRodECS7dpDyJm6fODB7Vg9cItqLR38sdpd6LI7VR56DGgkqJDtdtxTW 6TOT+fY/uXEfZGVMgYpRn4xRgSaRSRZNSy3dJxVVBYjB/hkSadWS1kQNhEccWYQQMpYJCWVIYhMG MCReA4RplESKrrBlAkN9McHWeU0g55AQZd2TI1fpPbZYe+7FMiRK59BkYYPiEFPaOJ/xh0SUr9Em YBsBHEAMFAaOch8mWTFY3wEKfnLfNZkZ40wTJM5ii1mGLNBALRMtYdcCHaallS17/diWRhaZQNd2 rogl3o9yOeEjWDvyNYSihjIm5JBTvPcYSpbhNpVLkL2RGWSzTRkVMbKR1mk2u5UG1ZZFjYKbOZ6G GY1Pur0WSgZsEJOHEw+dZVZGDuzFXJ/EpdgEjz9uF12O1GkX0RC1EAoWcXyueeOxZdFILbXqSTpp FJUy/kaJJbLVR1UEPimpKW00mRbBMHTU1I5kB5yLTqlKDRCBGK6tEQ1rqGAygE+wZVavGQUcMJSn KeW3RiY+eUbANPkxwVAiDMXSYXSIjbXVXndplyGKHSFy3FkN7AXjjWcl0mEoGQ56qAEWvdXoj4dB mli33kJSZHtVUaWJAyzNtum67BIISk5MDJ2guqZ8WYAeplgW6pJKFXCrNk0xkxUSmACHyX8DH8O1 E9oaWphhft0TVkQa8yNsijQHS7Oz5nnY4o8IOOtRINFii4TfHQ65M89NgHu44lqke/UjY/63+BMG sLbW5LzQGMU3OZtkuOSJSx76E+eKY9kj7loVueir/lPRId8wt+f54qCzXjsTAxQwjyJDzzO07b8n yl3lI8muOO3AI5+88r/kNXzn7K1+/PLTU1+99cUfLr3123Pf/ezQi6699+OTX34u2PMsvvnrs9/+ Fuh7q77789NPP/yTyl+//vt7f3/hPvOBQWewmgAVYSVHZElLqzig4kZhNUd8hoHqUoRwzge+0OUP Cs77AgFr4wgJ9mENuuIFCCe1kwcugj/yUp0fUCgJ/8UOgHvIhh6ooUFjzKMZ07BQM1zDDOEoox3l YMIQN5WBCpLDhrdDYjGOcSt5tWMc8hCcON5Bkyiy4YhLxIYx7OPFcAyhiFxchjc8GEZUQAmJQfSi /g6hMMUkWZEZaprgCqOixHDcERpIWKMVJUaSC35OhpN4Q02wokBRYaVoOKEKw1hCSDIITCZFQ0oj A6Cq1/xED+cw5NaSNoRF5stsKakMGzYJEx8eZUJMymQhMwFKybxmFA/CClRqwhIzOKwAl8SkfGTy iYGJYZI/0Z1kOBlBBHHyGucoGhMqtLRCwqSViAxmIxv3PkDOTpBgCErqziGvhUklNCnphNaU9kj6 aMIqsZnNOl3Sm90IwEJoPCRlhEEwJ9BKMmnYDH3ScKCU7JI3Q/DNfOoJAMuYhl2dQFI7xSmqqRBT dUJRGh0oljosDTRd5ZRMMzpxjY1mYg3LdMJG/gWwm4l6E44cpY8eLKkIGHJLm6VIkzzruEM2+Cee PFGVp1Q4IQp5KkHpRAcxIzSqDOjRav5p0AHDiSBN6PSfjmOhT/iz1DloTZdsMCnDFLQ1CgHVEodk kjZqugawiqFT0QiVLptwzJ26xGvN/OlMooRGj/40rVPdA0yDJNMtBKWmN3lJllQKx2AENpZp8mNu bPJJx7LwGsBMauOmNAcGZsJ09TlslxC0QjNlhjOWrahkvEmxL+EUTWma4Og+YVexLtaP9WFrbd4a mTVkiZgUiq1h78qbxVa0jl/oa6T+yjhCClZwqXtopviZT1j2VorMiMkbXrWM+6AmobYxLBIy/nUN BppUuwvjydFws1kW1oQ/3kWQZcaUK+pmKiqsRYZrBbvZO8w2Xc894lv3m4GPHrICFrJDdFV63+32 ApvGM24WEotg6kbgVgiily15E4EsIXdA+SrsGiTmk1B6mGJTeVhQ6TUweFnTXOiab0yIUZP/vqux kfQsfUlsDHkWgHScGcZJs9JhgxVzxnSkrxlei68L05i7Fr5VRzX1YyaTJl24rReoBBuvIxd2r2cg rs4YHIYMP7iTmWhJ03TJmYHFE8yPTVorHSjK15Cta2Vw6QObhg4qPQGjUoLkgLKWZCbFOUp2ZuY5 3rCOPY9hFA5IYMImeF6GKSO5qMXvWhs3/rCe4lXOnrqPdrtLhqIZeZN6mHSY+arg7HmZfyMR8fgY q2oL/i6Dr5bEALJsvoDO+oWnTl+qc60K3G3Q18L+1q7j1+thIzvZ6glUrI+t7GdDGxcmcPZjEFDs aGM7245QALUZg4BbaDvc4n7ECR7wO1qMO93q5sMJgn24E2Ru3fKe9xO+jbxp0zvf+hZLt6sN7n0D XNzlTt4J1BLwg0fb3slTOMIbruyCL+8E/XY4xb2HAAVM7wEDrzjH96fxeC/83x0fuflQZPDlyQnk JF/59mhx8umlnOUyt94D4mRxYc0858BzgJxebj0UQVznQg/dtxWg8u59W+LmBvjEh86YWwfUI+jt g/oJqh6oLmA961rfOte77vWvgz3sYh872ctu9rOjPe1qXzvb2471QJ3ACCZYuv4c8IDquD3vet87 3/vu978DPvBeB4XTC2/4wyM+8YpfPOMb73h6BwEAOw== ------=_NextPart_6C0_6BFC_96DA1BEE.228F3524-- From ips-bounces@ietf.org Mon Jan 15 10:04:16 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6TNX-00034O-Br; Mon, 15 Jan 2007 10:04:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6TNW-00032E-3t for ips@ietf.org; Mon, 15 Jan 2007 10:04:06 -0500 Received: from smtp.nokia.com ([131.228.20.171] helo=mgw-ext12.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6TNU-0001h2-Mo for ips@ietf.org; Mon, 15 Jan 2007 10:04:06 -0500 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l0FF1ZNh029174; Mon, 15 Jan 2007 17:02:02 +0200 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 15 Jan 2007 17:03:13 +0200 Received: from esebe108.NOE.Nokia.com ([172.21.138.114]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 15 Jan 2007 17:03:13 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: Re: [Ips] MIB doctor re-review: draft-ietf-ips-isns-mib-10.txt Date: Mon, 15 Jan 2007 17:03:10 +0200 Message-ID: <213394AB6954BE4682E8B2A4910346834DC9E6@esebe108.NOE.Nokia.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: Re: [Ips] MIB doctor re-review: draft-ietf-ips-isns-mib-10.txt Thread-Index: Acc4tkRV4dyg6kK2RLyf87Y7I69Xtw== From: To: X-OriginalArrivalTime: 15 Jan 2007 15:03:13.0032 (UTC) FILETIME=[4708F080:01C738B6] X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: bwijnen@alcatel-lucent.com X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0706184499==" Errors-To: ips-bounces@ietf.org This is a multi-part message in MIME format. --===============0706184499== Content-class: urn:content-classes:message Content-Type: multipart/signed; micalg=SHA1; protocol="application/x-pkcs7-signature"; boundary="----=_NextPart_000_0208_01C738C7.084D9CE0" This is a multi-part message in MIME format. ------=_NextPart_000_0208_01C738C7.084D9CE0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, can the WG please analyze Bert's MIB doctor review of this draft and decide whether it requires another revision? There seem to be a few remaining issues. I'll hold the document at AD Evaluation::AD Followup until the WG either clears this version as ready to go forward, or revises it. Thanks, Lars -- NEW EMAIL: lars.eggert@nokia.com NEW MOBILE: +358 50 48 24461 NEW JABBER: lars.eggert@googlemail.com ------=_NextPart_000_0208_01C738C7.084D9CE0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJcTCCAvkw ggJioAMCAQICEGtxkLFHQu1g67hlmYfwPuIwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDEwNDE2MTE1NFoXDTA4MDEwNDE2MTE1 NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA26hjntVPZMiwh4d8tyuk9KiucvG92BVUGArk5zO1jhmq7tLFgU1mqcIg VGumfQqjkAzIuh83kxIiqBrB05Wvxp85apwt4sUCvzMe8mQWzZZZYp0rBzwpOj+VC5pxsMRYtYW+ BaTFBEmvFr7D7C7roZUk0lDppS5SZFs4SQbEe9ykB9aeUf1iTiw2+ikyP2+JEYto14WYCoxFWbms FbQ1uaaK+yn1WH2YHhyMfi0IOxuT0jtbsngjHJMpWIqq334zBhj+rPSUug47YBHr41FCDMHbbbjv WbyTyDYneOW3WY8LY8bGWVlAknQGB7lgduShe6e0RI/7SL/VE6X27lM9LwIDAQABozIwMDAgBgNV HREEGTAXgRVsYXJzLmVnZ2VydEBub2tpYS5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUF AAOBgQCx3nxxTg/WowobVTRXBiXUEEZj4LBiunWbuAnR0UbJIgijvq3JbiJvZo2gUGiW9LPaHSBz 4oxT1VR/S/6O0a4e87oV5cOQm6ReB68o9rDfUzxHTwoCfv2wwMwBrXyzQMjyQK4Lt8siV41gmZpm rSXMhjTJdd9uYYNoZKQLq+VM+TCCAy0wggKWoAMCAQICAQAwDQYJKoZIhvcNAQEEBQAwgdExCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMg RGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3 DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw05NjAxMDEwMDAwMDBaFw0yMDEy MzEyMzU5NTlaMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQH EwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9DZXJ0aWZp Y2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVyc29uYWwgRnJlZW1h aWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20wgZ8wDQYJ KoZIhvcNAQEBBQADgY0AMIGJAoGBANRp19SwlGRbcelH2AxRtupykbCEXn0tDY97Et+FJXUodDpC LGMnn5V7S+9+GYcdhuqj3bnOlmQawhRuRKx85o/oTQ9xH0A4pgCjh3j2+ZSGXq3qwF5269kUo11u enwMpUtVfwYZKX+emibVars4JAhqmMex2qOYkf152+VaxBy5AgMBAAGjEzARMA8GA1UdEwEB/wQF MAMBAf8wDQYJKoZIhvcNAQEEBQADgYEAx+ySfk749ZalZ2IqpPBNEWDQb41gWGGsJrtSNVwIzzD7 qEqWih9iQiOMFw/0umScF6xHKd+dmF7SbGBxXKKs3Hnj524ARx+1DSjoAp3kmv0T9KbZfLH43F8j JgmRgHPQFBveQ6mDJfLmnC8Vyv6mq4oHdYsM3VGEa+T40c53ooEwggM/MIICqKADAgECAgENMA0G CSqGSIb3DQEBBQUAMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYD VQQHEwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9DZXJ0 aWZpY2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVyc29uYWwgRnJl ZW1haWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20wHhcN MDMwNzE3MDAwMDAwWhcNMTMwNzE2MjM1OTU5WjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMSmPFVzVftOucqZWh5o wHUEcJ3f6f+jHuy9zfVb8hp2vX8MOmHyv1HOAdTlUAow1wJjWiyJFXCO3cnwK4Vaqj9xVsuvPAsH 5/EfkTYkKhPPK9Xzgnc9A74r/rsYPge/QIACZNenprufZdHFKlSFD0gEf6e20TxhBEAeZBlyYLf7 AgMBAAGjgZQwgZEwEgYDVR0TAQH/BAgwBgEB/wIBADBDBgNVHR8EPDA6MDigNqA0hjJodHRwOi8v Y3JsLnRoYXd0ZS5jb20vVGhhd3RlUGVyc29uYWxGcmVlbWFpbENBLmNybDALBgNVHQ8EBAMCAQYw KQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDItMTM4MA0GCSqGSIb3DQEBBQUA A4GBAEiM0VCD6gsuzA2jZqxnD3+vrL7CF6FDlpSdf0whuPg2H6otnzYvwPQcUCCTcDz9reFhYsPZ Ohl+hLGZGwDFGguCdJ4lUJRix9sncVcljd2pnDmOjCBPZV+V2vf3h9bGCE6u9uo05RAaWzVNd+NW IXiC3CEZNd4ksdMdRv9dX2VPMYIDeTCCA3UCAQEwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMc VGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZy ZWVtYWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIwCQYFKw4DAhoFAKCCAdgwGAYJKoZI hvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDcwMTE1MTUwMzA5WjAjBgkqhkiG 9w0BCQQxFgQUGrpe+v/ukuNkAFuHNSw0GnX2OicwZwYJKoZIhvcNAQkPMVowWDAKBggqhkiG9w0D BzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgw BwYFKw4DAhowCgYIKoZIhvcNAgUwgYUGCSsGAQQBgjcQBDF4MHYwYjELMAkGA1UEBhMCWkExJTAj BgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJz b25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhBrcZCxR0LtYOu4ZZmH8D7iMIGHBgsqhkiG9w0BCRAC CzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhBrcZCxR0Lt YOu4ZZmH8D7iMA0GCSqGSIb3DQEBAQUABIIBAGC94qqx1V7YNDOcz9SJvLYP63e1KulcSS8kg1pZ 65jyNuPRL04rst/7AyjGj7MjFCIwh/vrCQuRA2ouhYxKom6Uff+niPe1ayAD3BrsrrHxjLS6bMR/ V8WR5CytAP1Y0Zlxkss9QwlQJq0Foxchgqg1EcU9kMP60BHTr8S9qxMmNLmU4DUklyI2HQf5LTl/ KYajUYwoDjrLjS7t5n+IWqEUFP7Lq9VRCmU4n60GocUzQpynm6ixKPqowfuwdT8ipvajtLi3+dQO wY4UZA2WG6rB0018y9mRSRDDM8AT3CHdf82tYCcoPf2W05b7h9ZM8F7fPx4aSDi8GxeEC/Tu3ZAA AAAAAAA= ------=_NextPart_000_0208_01C738C7.084D9CE0-- --===============0706184499== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============0706184499==-- From ips-bounces@ietf.org Mon Jan 15 10:22:34 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6TfJ-0004Fi-JS; Mon, 15 Jan 2007 10:22:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3CRt-00017N-5a for ips@ietf.org; Sat, 06 Jan 2007 09:23:05 -0500 Received: from ug-out-1314.google.com ([66.249.92.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H3CRo-000425-Q5 for ips@ietf.org; Sat, 06 Jan 2007 09:23:05 -0500 Received: by ug-out-1314.google.com with SMTP id 72so5555131ugd for ; Sat, 06 Jan 2007 06:22:59 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding:from; b=fOCOx5+rOXOvJZFXx3reC7tUtS7b/QPaDYxjk5i3uhXe47/SX41DwL0I4B2S07ZAAXa8LiOieHhGVXnVbomgO4QKP4OttleqSXa7wyq8nP1J4nsX3nHV33TKXlDGSThuqUhuS6RoClBDuoekVe1QYH24sY2l3sDdxnywrEXf9eA= Received: by 10.67.22.7 with SMTP id z7mr12288185ugi.1168093379610; Sat, 06 Jan 2007 06:22:59 -0800 (PST) Received: from ?172.16.1.2? ( [12.196.160.109]) by mx.google.com with ESMTP id g30sm36775897ugd.2007.01.06.06.22.57; Sat, 06 Jan 2007 06:22:59 -0800 (PST) Message-ID: <459FB0BC.6080002@haifasphere.co.il> Date: Sat, 06 Jan 2007 09:22:52 -0500 User-Agent: Thunderbird 1.4 (Windows/20050908) MIME-Version: 1.0 To: "Mallikarjun C." Subject: Re: Fw: [Ips] Response Fence Flag References: <20070105224512.76684.qmail@web51906.mail.yahoo.com> In-Reply-To: <20070105224512.76684.qmail@web51906.mail.yahoo.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit From: Julian Satran X-Spam-Score: 0.0 (/) X-Scan-Signature: e367d58950869b6582535ddf5a673488 X-Mailman-Approved-At: Mon, 15 Jan 2007 10:22:24 -0500 Cc: IPS , Julian_Satran@il.ibm.com X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ips-bounces@ietf.org Mallikarjun & All, As I pointed out in a private discussion with you I never considered in dept the response-fence (beyond what is needed for TM). It is a serious issue for any "transaction type" operations to storage - but the last interface that had all the pieces correctly aligned was the 360 channel. SCSI had taken (traditionally) the positions that sequencing and barriers are rarely needed and when needed applications should provide them. And that is exactly what all of the relevant applications do (all transaction monitors, databases etc.). The way all the application handle cases when the start of some SCSI command has to follow the end of a previous set of operations is to just wait for the end of the operations before issuing the "dependent commands". Is this solution optimal? As you probably observed already this solution implies that all the queues in the "stack" (at initiator, transport and target) get empty before the dependent commands can be issued and that is bad for performance. Can fencing (bad name BTW because it is in widespread use for defect isolation) improve this? Yes (by keeping the pipes full!) provided it is associated with rigorous exception handling and the later is a SCSI issue (exceptions will require emptying the queues). With most applications being distributed I doubt also that fencing for a single I_T nexus is interesting and coordinating fencing and exception handling over several I_Ts is a complex exercise. And as transport alone brings no value to the whole issue - why should we go through the exercise of defining a solution before SCSI has defined one and we are confident that it is good enough and has value? Again I agree that we a mechanism for TM but a good enough mechanism for TM is already in and it gets now even better even without resorting to a generalized fencing/barrier support. Regards, Julo Mallikarjun C. wrote: > Trying again after bouncing (>50KB), tail is now clipped.... > > ----- Forwarded Message ---- > From: Mallikarjun C. > To: ips@ietf.org > Sent: Friday, January 5, 2007 2:40:56 PM > Subject: Re: [Ips] Response Fence Flag > > Hi John, > > As you correctly point out, there are two distinct but related > topics here. > > (1) proper response ordering across participating connections in a > multi-connection session, for a handful of task/TMF responses > (2) proper way to terminate and signal tasks when actions on one > session can impact multiple initiators > > (1) is all about response fence, it is covered separately in section > 3.3 of IG draft. That's what this email thread started off with. > > (2) covers cases that IG had called as as "multi-task abort" cases > that typically have a shared task set across sessions, or are the > result of a Logical Unit Reset TMF. Section 4.1 of IG adresses (2). > > So how are (1) and (2) related? > > - Some cases covered under (2) overlap with (1), but some cases in (2) > are for single connection sessions. E.g. LU Reset on a single > connection session impacting several 3rd party sessions > > - Some cases under (1) overlap with (2), but some cases in (1) have > nothing to do with other sessions. E.g. establishment of ACA on a > non-shared task set > > - Section 4.1 (i.e. text for (2)) uses response fence (i.e. text for > (1)) whenever multi-connection sessions are involved in multi-task > abort situations. > > I hope that clarifies it. Feel free to ask if that is not clear. The > net is that the response fence is the underpinning notion to describe > the correct iSCSI behavior in a few cases and some of those cases are > about task terminations across third-party sessions. > > Mallikarjun > > > > > ----- Original Message ---- > From: John Hufferd > To: Mallikarjun C. ; ips@ietf.org > Sent: Friday, January 5, 2007 1:01:06 PM > Subject: RE: [Ips] Response Fence Flag > > Mallikarjun, > > I must admit, that I have been a bit confused with the direction of > the conversation here. > > > > Therefore, I went back and reviewed the charts from Dallas . And as I > remembered, the initial focus was to address the issue of Multiple > Connections per Session (MC/S) (as stated on chart 4 Non-issue for > single-connection iSCSI sessions). So I think I have missed the step > where we have morphed the discussion into one dealing with multiple > sessions. (I am not sure how that happened, or if I miss-read the > charts from Dallas , or have not followed the discussion adequately.) > > > > If we are attempting to define two different issues, one with MC/S and > one with Multiple Session from different Initiators, I think it would > be useful to break down the conversation into Topic A MC/S and Topic > B Multiple Sessions. It is possible that one solution will addresses > both, but I for one think I am hearing arguments that might be > appropriate for Topic B, while I am thinking about its applicability > to Topic A. > > > > Perhaps, you could address the issue as either being all about MC/S or > explicitly state that it is intended to affect Multiple Sessions also, > and then address the issues and solution for each separately. For > example, I believe Robert was addressing the issue from a view of > Multiple Sessions and if we only intended to address MC/S then I > expect the response might be somewhat different. > > > > Anyway, if you could clear-up some of this, I think it would be useful > (at least to me). > > > > . > > . > > . > > John L Hufferd > > Sr. Executive Director of Technology > > Brocade Communications Systems, Inc > > jhufferd@brocade.com > > Office Phone: (408) 333-5244; eFAX: (408) 904-4688 > > Alt Office Phone: (408) 997-6136; Cell: (408) 627-9606 > > > > ------------------------------------------------------------------------ > > *From:* Mallikarjun C. [mailto:cb_mallikarjun@yahoo.com] > *Sent:* Friday, January 05, 2007 10:08 AM > *To:* ips@ietf.org > *Subject:* Re: [Ips] Response Fence Flag > > > > Not really. Current draft text is intentionally written to not have > any dependencies on T10 dynamics. The point is that iSCSI needs such > a notion for succinctly describing the proper iSCSI protocol actions > in a few places - ACA, TMF, Persistent reserve/Abort to name a few. > We certainly hope it will be approved by T10 and be a part of SAM-4 > soon, but that isn't required per se for describing what iSCSI needs > for its correct behavior. > > > > IPS WG has adopted what it needs in the past - staying ahead of T10 > review/approval cycle if necessary. I_T nexus loss notification, > iSCSI target/port naming, clearing effects are a few I recall. > > > > Mallikarjun > > > > > > ----- Original Message ---- > From: Eddy Quicksall > To: Robert Snively ; "Elliott, Robert (Server > Storage)" ; ips@ietf.org > Sent: Friday, January 5, 2007 8:58:47 AM > Subject: Re: [Ips] Response Fence Flag > > From an earlier email I think that Response Fence is only a proposal > in T10 (http://www.t10.org:80/doc06.htm > ). If so shouldn't iSCSI wait a bit > until this has been ratified? > > > > Eddy > > > __________________________________________________ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around > http://mail.yahoo.com > ------------------------------------------------------------------------ > > _______________________________________________ > Ips mailing list > Ips@ietf.org > https://www1.ietf.org/mailman/listinfo/ips > _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From marceloleo16@uol.com.br Mon Jan 15 12:29:14 2007 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6Vdy-00016y-Rl for ips-archive@lists.ietf.org; Mon, 15 Jan 2007 12:29:14 -0500 Received: from [61.17.44.67] (helo=hyd.dsl.static-61.17.44-67.vsnl.net.in) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6Vdv-00070D-W4 for ips-archive@lists.ietf.org; Mon, 15 Jan 2007 12:29:14 -0500 Received: from 200.221.4.129 (HELO mx.uol.com.br) by lists.ietf.org with esmtp (O)/V196M<@E* 38.R9) id OBOU)Y-750BV3-4; for ips-archive@lists.ietf.org; Mon, 15 Jan 2007 17:29:12 +0300 Date: Mon, 15 Jan 2007 17:29:12 +0300 From: Quotes.com Alert! X-Mailer: The Bat! (v2.11) UNREG / CD5BF9353B3B7091 X-Priority: 3 (Normal) Message-ID: <661852615.05117603504088@thebat.net> To: ips-archive@lists.ietf.org Subject: Incredible opportunity for developing your business. MIME-Version: 1.0 Content-Type: text/html; charset=windows-1250 Content-Transfer-Encoding: 7bit X-Spam: Not detected X-Spam-Score: 4.9 (++++) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Develop your success using our strategy that we provide for you On Thursday, UN chief Kofi Annan had said a compromise had been reached for a hybrid UN-AU force, to break the deadlock over the Darfur mission. More than 200,000 people have died in three years of conflict in the region.
THIS IS OUR NEW DECISION BRINGS YOU A LOT OF EASY MONEY.
WE ARE GOING TO REPRESENT FOR YOU MARSHALL HOLDINGS INTERNATIONAL INC(MHII.OB).
THE MOST TRUSTED STOCKS THAT NEVER RUIN!!!
FOR DETAIL INFORMATION VISIT OUR SITE HURRY BUY THIS STOCKS RIGHT NOW!!!
IT WILL REALLY FLY ON THE TOP COME ON!!!
ACT NOW AND GET MHII.OB FIRST THING ON TUESDAY.
THE NEXT PRICES ARE: JAN 8=0.01$ AND CURRENT JAN 12=0.04$!!!
MORE THAN 40% EVERY DAY!!! ON TUESDAY 16 JANUARY IT WILL 0.17$!!!
President Omar al-Bashir told state TV: "The government of Sudan welcomes all financial, material, logistic or technical assistance from the UN in order to strengthen the AU mission in Darfur." Chad in anti-Sudan alliance Following a meeting
From dukeofed@canadianhoneyham.com Mon Jan 15 13:21:42 2007 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6WSk-0002OJ-2H; Mon, 15 Jan 2007 13:21:42 -0500 Received: from bl5-123-236.dsl.telepac.pt ([82.154.123.236] helo=o0g0b0) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6WRw-0006ZL-HW; Mon, 15 Jan 2007 13:21:42 -0500 Received: from 64.136.20.83 (HELO mx-ws.nyc.untd.com) by lists.ietf.org with esmtp (TTM4@2+B5 MG?,.) id M14 From: "Autumn Lindsay" To: Subject: OEM versus Upgrade Date: Mon, 15 Jan 2007 18:21:04 +0000 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_000F_01C738D1.EB346BB0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 X-Spam-Score: 3.4 (+++) X-Scan-Signature: d11a451997816a91a305dcb5ab1b85dd This is a multi-part message in MIME format. ------=_NextPart_000_000F_01C738D1.EB346BB0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0010_01C738D1.EB346BB0" ------=_NextPart_001_0010_01C738D1.EB346BB0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable Alberti, Brunelleschi, Sangallo,Only a fox whose den I cannot find.To run, = as in the time of the bee, seekingFrom point to point of meaning=97open? cl= osed?=97From which, thanks to symmetry,Beneath a pile of corpses, lying mas= sedRise, to the muffled chime of churchbell choir.That only you and I can k= now. Les deuxThe bees are buzzing,To follow in the path of their brief blos= somingAnd up there I cannot tell if it is stillDeep in the fog that quenche= s every ray,and the Splendid Splinter. For a few dreamy dollars,Yes. You'd = want that said, (if youThis gap in time, this season not their own,For any = part of them we can make outthen takes a step back, to be safe as she reach= es.One flash of eye, or blow one clarion-blast;To mark that square, perhaps= : were Mère and Père ------=_NextPart_001_0010_01C738D1.EB346BB0 Content-Type: text/html; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable
3D""
Alberti, Brunelleschi, Sangallo,
Only a fox whose den I cannot find=
To run, as in the time of the bee, seeking
From point to point of m= eaning=97open? closed?=97
From which, thanks to symmetry,
Beneath a p= ile of corpses, lying massed
Rise, to the muffled chime of churchbell ch= oir.
That only you and I can know. Les deux
The bees are buzzing,
= To follow in the path of their brief blossoming
And up there I cannot te= ll if it is still
Deep in the fog that quenches every ray,
and the Sp= lendid Splinter. For a few dreamy dollars,
Yes. You'd want that said, (i= f you
This gap in time, this season not their own,
For any part of th= em we can make out
then takes a step back, to be safe as she reaches.One flash of eye, or blow one clarion-blast;
To mark that square, perha= ps: were Mère and Père
------=_NextPart_001_0010_01C738D1.EB346BB0-- ------=_NextPart_000_000F_01C738D1.EB346BB0 Content-Type: image/gif; name="mxac.gif" Content-ID: <006901c738d1$eb346bb0$6c822ecf@C3F0CA48> Content-Transfer-Encoding: base64 R0lGODlhxwGvAbMAAP///wAAAAQE/B9hqmGw5Orq2729u8/PzvfwYvvQCGBUI7OZbPqCBvv7+wQE BAAAACwAAAAAxwGvAQAE/hDISau9OOvNu/9gKI5kaZ5oqq5s675wLM90bd94ru987//AoHBILBqP yKRyyWw6n9CodFoJWDPWQFXrzHIBX443iyWDzVfaGLNme7fjdzne/oR5aar7dIfJ4Xd5S22Cc3R9 a4R9LYeBcRd0FI2FgI0glDqYehKaHp0sf5JmU4WfnKOnpWGmL6qiX6hnsKyLoiusmz64ZTWhE75Q rhqxr7a/tTGYecLHWxumux3RuZnI0ta3Wq7MqduCdZWL4JPAp89c5GmqxLK04ujvzRad7p7wy4/H xFdo94ja6laB04eL37dy3WrJCThPYb6EKQw64xaJIL6B7XxVzGipITYy/ungvdL4MATDhvKcsblm j2PCiyQXAozZz2KsjYZg7sP5sqZKj394jpBoi9moo+v0FVOaiqk5Y3vEzIL6VJZTpNiiKpuKElLW M/YupmxKtmw3p1aNocKK1qujWQLjLm1Xta5XOG1FqKtiN6CjsWmv/jMbmFvXc2OF3RSJ9xLXn1vv Xps0t+pBj4ADl6V0Uu0/a4YLDyaMlKpk0tO64uvLmJdpy/TisR72dTXgzqdf09Zt+6dutx3tgq0b WXjx4Z6RHc+N/HfK45d3Z26utzXu4dD+HnbJ+7Fw51Cjy/tEzo52yLJ9S5d6+GBwzunh2wyH0XR5 4N6f58+9vDrs2dRt/hcgdRtBdx5zUTWnGGiUsaTefwIOmCBi6I1U4GgV+nZhcMzdZ1NvVF3HX3pD TQUidh8dOF1G351IXnbeLbheiQgi15+ENSIIYj0P2oihhd+xBx5B+o0YZIgk+meOi61NOGB2LeYH 5YziPfViCZoYqONXRz64Y1bytfejalyqx2N4SRJFZZImmSjlPRm2VZpKi715jnJVLqjdThQ6aViY LTmIZmUQElqllaPx6VpeJyr4FiCCaiZpm5KAYV+MjbKFlqaahQYUpEjGKRpcfbpB6lyKBirkoKge SpdZYa4lFmERcjqqXGeNFOmofOAKYE/dYXQIfWYi1BMwh7pHEzsW/j40LH1s0uYhoHXwJF9JAepU p7HTCcWhS/DVFhS2NG6q4kBZIkQui14y26xDl1aCn1Tf1gdRjqY2mG1c/I6JIqCJ1Wdvj+x+ypqI 0YQyMDUMN+zwqg8zUmbEFFdssaoXo5Baxhx3HPHGHg8Z8sgkUwNyyNyWrPLKwUxcsrssxyzzzDTX bPPNOOes88489+zzz0AHLfTQRBdt9NFIJ6300kw37fTLLrtwspJPV3301Cpg7ZjVXBettcZRk/B1 12R7PLYJZ0Nc9tozyyRvZhj6da6x9rrN9t0xc3hhY0WWpOxO5H6L9+AdY3VqWkmhOauPh3fqHpGE R85xnag1qQ2S/uf5xTe1iUvuOcXFhe5mwGJG2eeNn6e+ieiSrfZl6U86NCfBqtfecuvxAdRMaLb1 92zstgdPBeulu66ij6ZDjnyEwjevBPEVGt/ueLnDTrvz2BOROOW/WFqpv713DnDn2ZdvhOGCPUro vvo1jn76YZsv/wyP/B0u33BjKuzvL+E4///VuE7dILGl26hrdrlKGwAXyMAGOvCBEIygBCdIwQpa 8IIYzKAGN8jBDnrwgyAMoQhHSMISmvCEKEyhClfIwha68IUwjKEMZ0jDGtrwhjgUXgNA0IAe+lAC PtzhBIJIgh52QIgcMOIHdohEJVKAiDkkmhMr8EMRBPGKGXBi/hWzCMUhTpGKPixAAwpAxjKW8QAH KEAayXhFI7YRi150IxIt0MUoPmGLVpwjD+cIRzA28Y9vBGQgryhGM5IRjYg0gCIXychGOvKRBlgj Fn84yC9igIkA0KMdpaDJFOAxk5YEYiDpmElR9rCQhkwkJCG5gFW6kpUEWEAsF0BLWkaSjZUcZSdL ScVNcnKXMmgjKMM4xjMm8gCvbGQrk8nMZi5ymYxcJgEMEMtZKjKNQsylMJPoSybI8Yly1KQl24jK M6oRkch8ZCuXCU1nutOR7XynPOMZSwNAc41m3GY4QwnEbjpBi+Q05CFVOU95GvSgCE3oOxFZxkFy 0Z9JOOUa/tOZzHgq9KIYzahGm4lMdIqRiSClIzAhCoQxRhKN9tyoSlfK0pYms6O3nGQcR0rSHowR ndRMqUt3+lKe+vSVMMUmSP9YUyOYNJG0rOc6H4nOpjoVptd8qiMpmlGqRvKqjbQqT5day6561ZYW ZWQ6PYrJOhZVCDeFKTupKctFNlWgajSnU+M6Ual2NKjXdOtVobrKu4oVpWPdKFe/StjCrvOwU41q VLE5xLMeoQB7NcAAkppSi+ITrpg1ZDEHCli/OvWkeQ2qVN+5VnsatqsMWAADVsva1rI2Aa6NrWxl q9paQvKYB1AiPx3Lgwbs9QALmKwCgivLe3o0s3JFoznN/ojTwOJ1rFolrWlPS0sEVHcB1rVuAhaw XVpu97vc5e53Uwvb8jLAvOY972phq97UurertyUrJnkbhKPmNZqTtSxz95tK5DYXq64crHUJC17Y qha9CUiwghes4PU6WL3lTTCEJ0xhB6f3tbPNMGtt+Vey0hetDQDsKqfZ17em8cRzxSdB1Tldrw74 xdlNAAK2q90Ch3e75J0wgs8bYQizV8LobW+E2dvaCwf5wbNdamR/K8YPBwGyS37pU1GMTgJY+crT HHCOgzxkBnt5wevtMpC/zGAec7nHQDazhXVs5CMjOcNETjICFivfTn7SyS4IMYCljM9cUhPL9pyx oLF7/mPxnrnMYybzl3nM5h2PmdFphrSOMZxeLmNYyBqOrW0V61FTOhTPLeghXoH61oZ+NIx/xrJ2 faxoRLO6wYl2daxhDWY0H3rSCCbyj127a0xfOtOrVa1YfzvUYdIU1CYQNWhdede45vPUY+whlq9c Y1ir+dBehnSryexjSZvZ1j1m86TD/OBIx5nXRX6zpm055VMbG9kx8G1gSa1cXA4y1VfGrphnve1s K1rb/s51tx8ta1z/2MjlpvC5ge1aA8w5smsEpSnh/QI9o5TZJ2Xos4kJ2WkToNrfDjjBwb1vWg/5 2yhHtKPJbelwd9vX6f41w9+7zM6i8c67pXgIRC1i/nof0tTRDqLHP77ok5u81SHvd5clbe1Yaxvg 47b2msf95oUDm5Z3vaudj61zD4TYr7fNuMYLSU7feny8/D660pWe9JKXfOC2tvCO5Q5zSst85sGe s80ZC8auo0DZ0WXq2MlO+B7i28ozRrriR+52MV/b0Wl2/MiZLm5dJ/zCeM801j37UV7m3O9H/Pqy ma3c4wY9iIf/eNvbvvbWs771Ap88rRXOaF9bHvOZb+3ms57bbEoc9CXY4aiV+dUB1xa+p5S2xxmQ +Nc3XuSwj/zsSc74p7e80pZub7qtnvlW8r7J7wZ+EQHQVHUaNtgMUED6FwDtA3g88dFn++JVrnZ/ /sMdzQP3dqVp7+bc0xYBvCdUZiV+SyR6qwRfgQZc92QAq9V+Z2do8ReB9gd7zmd00odrtKdus8V9 M1ddb7VNBLhz5IdT8FRdz2RaGWdavSdq77dtFSiBFJh2THeBtSZ7tSdhGHh3/qd+3veBdxaCRwQA kMVX0WRbwDVnwlZGDMgAH3VILdhvLxh9UFeDIsd6IUd5+6dwt6d9Guh/G8YAVCZJnweEFyB8PUd8 2KVID2dPKpZaZBdiDwiDciiHSTeFM5ho16Z9OBhzHOiFqSV2yvWDZLgBN7VnRVhLSKiABXBYWEd2 7jdt8DeHkiiBq0d/B4eBJ+dtCceFfviHPjiG/oP4RENoiM+EWEhYS1/YUHA4bZNIia0Ibq8Gd3mI cJvYiZrHfsc0gKF4SWlFiofIhsgEZYrUSk1WSE/4isj4ilf4aAYXbltoi0k2V4K4i3SkRqNXgpU1 jGOliqdUAGeXjOBYhTVofTS4dOZWdejGiV64e+gEitSYSaMYYLa1AMhkZe7XZ0HkjZAYjvwYgQBH g5d3aZjXh51Ij001je84RNZ4cY80WYw0TShGALkFbWN0dpHYj/2YcvvWaP+YfVkIjRnWg4iEkAkJ j51lfl6lSPZoZRQZbd+IkTC5dnWIf1vYa3xYiwUJhgfJdbsoUdeoTMNVSxD5iFaWjz50jDEJ/pOP Z47LiIdxln0gqWEG2Y48SY3y5ovDSADDlV+OlHz5+JJJGZZHt4xYGIuy9ZFRuVpORZI9aZJR1kjD pYaLpUZv9FFIKZZ4OYvTh5ZQqYdd6H+ACH4lyYtgx0x9BnTQBpZ4mZGuR3CVx4m0qIP+p3cnVgCD qQFHFXj4JUt09YZGuYpXJmOLGZNLOYNlaZP995Qx54ciyXeXWYaF6UgE4AAKUJu1SQBk5FbJd2p3 OZpJaYWRF3V+mYFpGWy4OJKv2UtCeIaOpAADcE2xpAAE4FuTtYJeSZRW5pvaCYvSd2R9aXcEiXe4 eE5VSYYgNXxiFZfBCFwKAFn02JLKh2Xb/vmb4hic+2d54Blb4clwUxlXyflEoESCDdmakoVMwSVU Diif8ymWGilktaaFwllh6th9U6lc/0lH98VK0nlSkKUAwxhJgYSdRLeg2nmF+bmHGaiaaXlOdFme 5il6DJlVtZlXB9pWntmErEiiDOqYRldhkaaOVrefGfaBF+pFK8ZUA6AAtKmkBnCVg6SP1KajGKmR kteMm+hmNvmXmcZQaVSkTzRvfZWVJzaMnil0CiqlYclq+YelONmFQjpbtxSIXgpEx8RKSypct2RP 0/mZFalqaDqlVdpyOViTUyeQuZdxbDSnmcScjxSdA7Ckz1SmPoRvovmngDqLasqmEnqW/iAZp0J1 odkUm0x1VR4aXIv0pDlqqcn4j6/mjBDKhYK6qRMqW2JnmUUaqjH6SLT5nAdqWtV5emZKbRfZb4Km qvM3e/dHdbv2prgHbHGaqIp6krdFS0q6q5HUSsDqiGdqrJIYixaoibGqmrHaiWLnjuY5AUdaYqXq ofYkqYanasPaasXKrf/2oOPYdBs4q9u3ms6KYrYarSkISUn6nNSERgMAXBIJn6BJADAYr5ZaiU3H jIIqrjkomZnmcPWmqCapmcMoXLSpgO5HS14ZdNiJAA5Lr/HHkWVmfcNZqPhZqPwKpyjmoqEorRoq kQyZVMDqQ9hZqSi7qhELlfdpd355/m5vqpYaR7MhuEPn9Eq7OqN0mUYgGkhQOqI/C4N3aI72uaz7 OrREq6+x5anmuos225xXpZUndlT2tpvyebJXK39U6JSaSm6c+rV+eJCKyrTpykjsikYeCnR82qeI 57Zvi7X3OncI552QiY4XO7NKC4SjqJkkhkweik1sdKNHGZqEu2AXubnzSaU9eo5c+5FZGplC6q9j G4pNq5kLUJsEawCqeGot6adz6LloCpyK67VZaLSsuZN5G7mr5JwLQJsJm087m7nZabuROK8+q2CJ Z7uLOYXT93Km67JaKltc+rhLu5Ca6QCK5KF/a7lG6W7wqnRuC73cinKY1msqipZA/nq9VJa6g9i0 WMmuHvqrTeiuoGmyxJpggva/lVqsAuy/tztrshh31Wu93Ze92kuA8paryqSVSQqiLUpMV9S2BCyv nEvAwwp/Hvy5RadyxOmR6vaMDCdfv8uoWWVPw1WZ0aaw5Ces5xvAojmvz0vDGdy8UmqHNLm4RauD faha8auxgMexgVl4I8uz+XbDZMbEHIzDT+zE6MuYITy0l0ixFgu/DNXA4md4RBjBPbhZuOSuUGqy /Ptlz/u//GvD/rvGOPzB0ctvZDmudkuxQvqegcjFoAd4WNm6A2uqTfqGFFlIA2Bl+qbDbZzDNbzI PjvAjVzAJleWa4bFzQq2rFV6/rlFxF8HwfDkAK1bmxMpu+QkS1nGyM6byGY8wEzsxgD8yFOsjGr3 eOK2vjFryZrmYXmrZ1j5kAqAUgOwtoMsbYVsxmgsY45cw468xsmsyIgMqNDHo1e6rzD7spoGhiyq x3v8wL4IVX9rAL1cTEn8wgRQyK3UvKqsxsTMygCszjT8ynM4x3s5y+wLq+konuf0qXkrqok1sA7w y00Yzu86AOnMYOt8wwOdxsac0Kp8ys1MosKZmrRsqMBWep3npUykws/kkAbKfmzUey0pRpIVS2fc zqlszOl80gqtzIvMxgu6pvbqo/Rcy/XMWgDYjhq7qD8JlLTpyYAbzmL0iPTI/rxqvNJDXdDsvNAN nZf1Oskz/cP8yn1CfM03PYIZKniS9Z7gHMwSNc7lTNDKnMroXNInrdJIbcq+2ZH4KrEtK3PheZzQ qrH6XNWKdLB0+c98CtSsjMwCHNZFfdQKzdAbnNRUDHkpuppze4tNddNmuMsHUK1xWdfHK7v6SI/m DNaW/dV6fdlkndfu3IpLGbpTF5kMB9X3LJj/OUcY3bFXNVmXG3QKO9lnbNR8jdKtfNAqDdhmrdSS N3c+TJzXi124DNeprZV51cutrdWnZMgGQNSa3dzODdYmbdLrHNhpGnCUx38yXcm3LNV5S9Uc28KU C7v2htwNYMgHQNLPDd2a/i3deZ3Dx6zUzofddayvVkdLpY3NwCegjSq8znlZovxGB1Cde53eBK7e f33QuB3HPXyBMHu9Vxfc0QqmGvqcoWzB4fyI5/3VBR7blp3Z083II93Z3brUo2u3dceBwL3Fij2E mtnYGwpcaXu8beR+vYzQzk1L7kXTG57eCV7dLIuvMS3TtozHrjmnhcjJz1SbDkC8koS5JFtPY63Z qpV+vLbh0T3Q3FWbPU6fWku9tIyf3LdwKX5z+O13R/5Kk8vf+gtti3iwsw3Wn2ycOD7mwZjKCjBj w5V4WZ4ACsDnrevn7czlDWqfWbyOFWraFg28SGqbsaRGChBiu0lIyZ1l/hp+2cHmcCZ7Xmmopx5q 59QaXlmOAMM1XAkmXm6s4Lvt1Al8x5224l8Ml8HlujP70W3kzR+X3gUg6qllsgdgstU1TfDq633+ yTP25+I17Mw8mi6NuIzLmjVN5lO9uollAN5boH/LcWU36ZgO1rkO1gyY591+6QX7Z6lcS8Z8576e XaL+XSL+zvNne3cX5lJ5nF3q6ljpt9/b2OI9kRbckgG+7dxuxrmO49t+3tj1cAYK8Ddem6Jum3eu w+0uhckqtDip3bTa6kbulkjOt84ZU/+N7SEmS5bd7d6edyQvYz1I7nBumwff8NblACi95YPNo6Lr hVD97Jms2Np8Wx0v/lkUjMQA7X7bnuskT/QIMPCr9b/C9megZbJE7/C1efAwb13oXu5aTvW0Kdh0 2GATP81ItnBtXatl3nW9qJn2+7E9fXps/pyXTfJ2jn40R1nXdPTC3vIM/8mtm/V9TvVa3rrYdfVA K8I2WNhCLmcZJ78vanF9xc/A5fEvTLUm9XFG7/ZEj/THl129fvAtT/eebPVKbpuejPekLmMMT/UR D4U2SLpN3X3ENvY658Ubz8LX+subVZeERE2p3O2Tz+vpftnFhYjC7vS8nufeS/W9PuwPb7Kfn/X0 CZzKOtP7SeeIfqsGyPMUvkiI6drjK9JGT/e5T/f+u+2EVmjcdfSt/mvZQYnupe/wz8vwMu/ZL03x a123SVaurk9xR27230ub4m3X2c6CEIBQkXReWmiSyHRkWcJEGRFFOUDDRJyxlJRkUSQu7RK+938g J1hi/IpF35GnZBybiaYzOqVWR4ZDttEAdL1fcFg8JpfNZ3RavWa33W84fJvFGuz3O8HkOAwWmoaD rYYCwsHDwgOCC8YMDImikRWJD48QkYVJB8cQl5vOj5QEGImF0RSdIdXVHJqhJgSk2IUpqKeqKFtc 3AWsLEGuOOFh4mLjY+RktjlfPGeDAQWCgoUBjUJsRMPDgxFOR/ACjseOk84/D9IOnZcRdk8FBx0b E1UE1lUFhtgl/igomiYpAjLQ50+KwV0Jo0j6tUXZQ4gRJU6kqCbQATsYnxmw0StjtkKHRG7BRuBD BgsoHzFYYeEDRxGdQKT40+ITChyfaJSqgY+HK5887vGg10PfDYIES9gypbSKrlwKd/XCqCVYRaxZ tW7lOiZQs40Yq6HC8gekyGwke317dI2EyhClRNA8USAeKnM3QcwYJ6TH0B83/OJDlaMIvyiu9B1x FRWhE6hSqVBteLXrZcyZNbcZREcjns8wTRooMOBA2pAjQy7CEE7DBHH79sqlYeMSiJiz97ZyhQOw j9/3LpkqYUOeu6M0RB0mUjupqYIFmUiRrJCh1c3ZtW/PPqfq/sY7DhxEy3Sa5Hn06AtwdNsW9oRI peJeqmGuAoKWun2P+yQUCGDFepBHlBLqIYU4HQrqhwFabKnHnwapgyqyyKzzBTvuMtRww4guqgO8 agrAyA9CzlJNJDvAge0aFntC4oRJXjpJA1RSmES/UhzAbRwUEizMhAUcMMoEAgk0jkigiJDBhids 0MWgCWupbrJfsgDAMg6z1HJLizwDrxsV6lAhkUFCSm2bRNB5LZxHejIlrm8smAFIdfYyJYa7oLur RxGKy6lHoUR5UFCadNSHuCag+ympxJiwhcIprcDPFy4rtfRSML6iAzxoMrHDGhNTS6tMs9pi8dRG 3EppRRTQ/pmn1R4H7BHJGYIkjp6hhBRlKCIRLazAon6qodVG63EUslsiteLCkDB19tnNsATAS05t iicTQAw588T13lMJpVPX9PY+OV04By8d7LohyHsUCKVGneT5qaMh6S1QqQJ7bPcoxlx09DFlpSqv MmgLNrgrLi76DkSTTBJEkG1H3WaLUsENd1xxWWzLBBpvkIevdeZCQbzCZg1UR10/YVJJQElergck gkBiOihpTjbSjLIo5GCee8aKWvBqpKpEidM7hLTWVgw3YxW/fYHWFkrRyxOZYhDOSQ6crAde6Ijr qYZ9YJa55phnBjhgXqo8wGe2206GELCqJWCs08zUVpsy/htAek2+UVWVVbZmvckFdnOsQcdRThgB OXiXgg7foMY2YoknyH4S7Sk+qKoAtzv33I1ggH5GbWgAyRbvvL3jW+lTGzCVTUc4vsAAHc+RWibB b8iTTyFwGCxyscVW4lHKLaeiQslyNu9z5ps3gxDRnVHADzvcNR3NkRBZdem/L9a4rTprnbPkpeYE /vxVYk4CoQUrRH5K5Zt1fn764V4YxBTk0QAYie1G5LTW9M1vgMNYrdbkpHXQBARC2cFQfoO+9I3t WDUjG+YyVwfzSIt+G2wb9D40OmhM7xchyaDR8MY01nVPVWwpF4700zsIxnBy/pjcBG/2qKhEygMj vBIH/n3os6vY74PPINIdroE69ZRphdxLIesKqCIX+saBfZFhDM1mQyjh0IKZqxLnNPhDMFoqiCIa IhFN4i7TXM9u29Ket5aYMQQQImmMoGMUqfjAKuaRhntEVgVvhracGWAQYSSks8aIQU5FAxoHcFeJ JnYiNMFOhdxz2vZcyCMGwlCPkRte8LB4i7NhLn4OKWQpMeXB0DyDHgMizVnOxEaiYcB1FmtaI8hV R1ziyC943GRQhnfFyy3oj+9TSCBJaUpkcmkLcdvIaIxIJkgaDYUaY9rS3EMOXfpuP7zs5QwlVzbj SciCzQBGMs2pJVR+ySbj8UgGUZM9bU0TcN0DARTl/nRJKe7SP93Ex79oaDMcElNZVdHZMc950O2Q cVMbEVE3ojE9BZxOVCaUIxzBFcCLXvOe2fSPcPTJT04Kz3IBpQ4gq2RQhKZUMw3llGd05pm7PTJ1 8Xwd7Fh1H1vWM4r72SdI+9mPLIaTck8BZDO+qFKkZmWZ93vGALAgItMVzX/pIVd7kva9wFlSNzya Ijd96s1/ihRZfSxpwMiJ0qSmtSLMSKUzREDOd8ISLSWy5QoxZsnX5HKrwgnOVyUXQT6SVItlrQ5l rHJUtSZ2GJaBHlPdyhG4PnKqEcsrXJrWHijq9YUe9d3v/FpDCs7sl8fL4TgvNEjFphYi3iljRgxA /oAsLGBuglRjel5JEnrKkxNV1elGG9jATH5Whlf85WC3+AssoFa1yz0GW6tVDdlSxkTwnKhF71lL bHbAty+EYV+FGzyxEo+4yQqmKE+LVuam9w1LbW1GPGKHTMwBezHN3m63Z1M5wdGOC/SoZ78rUgB/ krxbZJDalKteBC+jCx5qKx4o85HURew82FiduNxzXe3uZbsL1KRXv6q+9YX4WDk0rkl9ceAEpzgN rG2we+dWDdoeUcIyjeVsVnVNnO70t9vU5H+BaoTi2nCs05kSLS4EDMSqWMmZIuiXoEs9qEp2YtWl K3YvrFOcbpiv2vSvj9fXSWCOmMQEJiiSl3zm/jI4t60aGVgvHCnVmeJWr1rNcHb32xfOevnHQABm aIksUMkMLLnoRTOavdPiPAi6hNOFpIXte0vfapm/PPWwX9XX57COGFKgFOVJCV3oJXOhydWCCYlY 1OgkbkGzq2b1pDOZ5y7rGahhzvTltkiLMqMY1KB2rCp90dBAaGPG2mj1bnXsauD2VNa1NltoS1xa zKntSknedYIV1t47OJUOtRV23kR1IxvvVdw87i9wZO1PcAr4ILt4tnXKPO1qx7vXd2hyL8xyN1jO uNWw7m5HedzR31X6w+Bt3784PeTjVmna1I73crmwnoWOzjOyhdiU5wvLLBz72P0u97IB68+C/oeZ tIQVGEFT03BQC7HBZaYD0ehL3W1EUdKzwTNw89zx/zabzwUP5w1HXlgGHBneKDd09EAzwlNLOaaT BfctNU5zvvb73BLM4idJSmAqbU7XRE8xxLGtttY5kqJKJEnTNfz0vXY41t8FsYjDS9YooU0EXfw0 19Obzpa+NFxxxjdaZv50jktd2VM3OM/JqhBAp21zPbS7ksuO7SPX7YhLp7HYRaQbY29Zx5jsr8AH /nGxWh3rA8tg48/s9ZUz69T+uy11M4/2fJYbMJ73KTidzb6qVyfxVvBUQRluerU29utdhNg7pSnT vJ4d6vvdTecH7/EvB/YghsfF7hfiGfkB/t/aCq1WF1f/cqVT+DRc3WzaedpT2gt3gp5E98H/iDnS e1H71hZ+i4kvYym3vo2bl6K4uYr+ZdO5nWu2Pysp67OO3hOEoZs/9dKbiDs6pPs+OJurstsAjoK6 wANA6AMt0funwyO5SIm/32NAlcK7L4nA65kvb/O2/SG/5au52FM76LO9nQsv9hkmrEsU0nOIESTB c2Iv+xshyUtBKuM7q/K//lO72dtAqgMzP8u0Ahw9umM8H0yth5s3DDqNIVwjE7otbAAg8/M3PBtD 2WPCtguw9rlBccrBuWuIKkQwBjtBFBQ72+o2JZK07oo652NC0HPCq1PDNSSws6q7NyxB/nICISFM utOxODvMq8DTQ1hzIH4LwD0bQOnLvfJiwx0kxEL8QeeSQ53ZO/qaKOQDt945vy3Lw+fjQ8MTHk57 jGc7wKnwtB7sxFJisbBQvaSrvPrav9/apxicoh9IP7Z7haACKOOSxYQwLDOzRcXSlLzTu6iasL5D DTP5hVgTRn7DOY8TwPUTLdxbNxCEv/IYNGd8Rk1BNO+TMbmKJtzaKID7qCVkRVUAMdsjrvLaNDY8 sq07x4PCxbBIREWsRsq7xssTxv8AxnikR0ukvrCqoLNRxskoRwX0x+BLx1yUxtpqx0ZrKP5KSHlk SE/aozQMMrgbx1vjR060yFvclJW7/j/8o0ZXKkULUMhVXDtKNEYCdMj3+8Bb20SWTCuFUcdQjEmO nCvxm4S/WAVeIsZiJMmdNLiTzMFlgSkqDMqUwsLI28KNJMjsyTiExEmRBK90EyY/M0loQ0mB4cer xEpzEjXkQsSinDxe7MXU0MLOGss8Kq63Gy/3k8ipELq2dMtkghvXkjiNpMOZnMlt+IWw1Mtv4rkv w6IoATTAnII2LD3CRKihjMYtBD94irMqWUrIhCCQEzLjsTWqZJBmyL7NfMv1GD6NzJbFJEiQwEan pMdL2zNaAygiW01eEMzXRKgqyUgtlMDQhLlrxILcNENv6jNQYrb3a7fRY5bBHM5S/opNzzxO/KtN 4ysT3CxN0AusHxurY0Q44FyI1lxJ7NyghiLKz/zO5FzE98xL8STJyIQM6bS1uEtP1lS4WmzPz4nD gNRCrsSe2jyhLGCN+yzP2/PGDlTL1TQszhHQwuQ+uZxL1ktOsgNP2LLPBh3PXHjC6ZRQCxI017RQ QlKol9TQN1vB6XIllmpOSqRMcCyewnMM/9yFUWJPFf0c1ANFqKLNukw1UYEtO7jPTuLA8hS5q0vL HS2wEerHH50fE3QGsNs7LgyVOtSARfiAEK01IPtD85SSyyyqKQ3QKuWZhMHQgBzSyZuqXlTBBkDS AxDPtivLyuk5fAzEKE0UZvHR/jV1GwdsrywlQhilPItbUKVkyN3czdw7PDXMxD/lojRV00E1mCvF 0tlE0NDcUEPYFJGkwZJMQ4jEwZ6s1CjoUUzNVGhZqtRbx+9LVDnFN0VgUOecIXtsUpvxSVW1kDR1 VR9iBtmE0w3lSFL8wg+lUT16VLJ8yD0t07I6U6w7shQVVudxwCCcQ0S1zS6tU0UAU+eEVGg9VWmF 0l+lAuU5BGzdoELdVmMdxfmUyURAUgOYQUssPArSomRM1+pYVyptV7YBSNCw1u60PK+MsEEggNFw 1PxsxSGj1h21VkEV2IKBxgLlTm4r0r4L1XC903ENuVmDwrjTR3/l0fNqVYsV/qPvaNHWYUzvpMAC gK1lzcmGHLA/PFWJBU6ADdiVPRgCLViYRFQutC2QWA2GJQDSfMroe9YH9bmTVRaVVNmf3ZKghUAX 7R8KTLXGXFAQ9bJdBUcdzVn3i9piStmKrdpK+YrWKjM4fdEEFZWivVWl5Ub1a1oHFSqS29nVnFq1 HdCWLVBRLJokGpWzoNskfUpy5UlxPEm+XU19yEIepNq/zZBry1iN3Uj5rFVlbdipM9V7HKlUNdvC GsQFq1y3GTXEHEJ5nSkufaVbtQNm/Sn83MnicbYxe0XSlYpcSxjUTd0HpDeBRE5vXcG7SVqTsLQa zNe341cp+bndXYigO6kF/qPc39UOl1rdwe1Yu9xausXVXirLkexN3IXF6A3BLPwC673ezYjLjI1X L0xYw52DpL3X2Q2xv1pcAXNe9DzfKpjCBWRfgzE65WHdaSRFiytapGXYPjHNSuTLS9RPq+tPdD1f IyOo9RXg7ChO7Y1PmXTdRjQE5BXXveRNp9U50ftL/5WMd7tODXaWIOVUDWW0Y6VGG67T+r3XkPqp qPTAfBywg3vcKDUB5NqZF+6ZGJbhuYyni7PhGKXf+q3HBy5VSCVAFMbdKBzdFf5P3zvdI4YWiGvR ujFgJz4+b0XcRfCJM6S6fRVb3fUjP91iXCjiDP5irii7WJXVF1XYl/vO/plF3q+h3bAd2T5dN/M9 S5OVYyktKBe2Yy5JYuHN2g/mWvCjsD9O2ryE4JGEyiaFwmk1wOdV5IQg4jo4OUd+FpYS46Xx1Lgi uw1F3herRIKTYsl0XN9EZC3eYhHkwUY+Ze4QIiGVPO5FogSmxu/tBWN0u4fk5LJNCEgR4qiliqca JHb15S1J5Q4+WCqDWTiD5Rgg1bzd1VoWrF4twFASZSr5tdC05ixZJkNFQW0eO87FHlhWWgdd3Cke U5REnvdxH3Q2gQ85SnbWkMYK3shDzlZ+3Tj74wEgAKfCXyoW0zZ+UqlQTQpGZ0DdNr7j5YHWjk8U Wnh+YiOU2W2oZxIY/tlN/iuIHbOLxmj0zRk6TduOlggg1N63hdliLmNucGieRpSbLV90M1+sg+Yd fatn+mAjnunuwFibPuCtbWJWhh5v9polxU8pTuGeJGoLFl5FJYReVmqsYKs1G964hepa1RaebugR 0NNJfWP8LWeXhtz3Ig0mTkGwjpb3FFItpVNQ3dJDYNiGbmgdXuOUjkqxvUGtFuW5FmYirdC71gy2 HWuB7FgFNtJifq2G1oN7Rc3KuVFM62zVrOC4Lqy5tmQKK5HHjpZ5M7m9puS+Nt4SCezM/prQbWPU 5Ff+HW0LAuhn4h6vTu3MuLZUAru6oWydBtVqTGuGHVOgHmcfFm3d/pY70FjligNuzIjs991rOX3t scNh2RaBPW1u3TVPDxSz6FYWo04RStIA675uDsbaeFVU4/PrmXTowJ4ts/xGnT1X6jzvIptu33bs 9uaKwKU3g33ZnEbuIiwJ5d5sZkPsCY7YXPbvUS7t/fHtAe8KozM5Mi5as+beu7TvhnYXnuy5TWtr 6KZw3gNwqBpjQMhwAmemSM5c437tGtYWaBBxAjDJB4XwNXzSxN5qI9LYIYRxAo+eQ+1K+TbjVoaG AbhvfgDy36RogDlnFSdtACfyFzfyrIhNlzXW+fbKMEcNRZBtP4iF3sRZHKxMorryKQHodtI77lyb OubyNHNfA9dj/i6F7coWTR33A59+ReelaHEcrCCP3vR+qjkf0jq3czIwzOBNcrhdcu/c0rR+8l6I zuqD2rI99Lh+qzg/zjl39LUK46ZG8D1nNHlNjT9/EEMGRCp35gl384VY7PeUcwEn9dXyuvdlbBrz cCamVeh5cmJv6KrjT06PY3ajdQSELGs10CjT9YkI4+HWxe487aj2VEYMBBF/8h0n7xKFNsucdVo3 amYkPiuR9g4hIzmEXxUc88Kd5D8fgBDQdENWYXJn9kATgdEgbiFU93UPJKw14FCp7BufLCcv9ga+ d2IKbVnX90ZZcchSG3QH+IhgKbkEcxA/7ibmwj4odqcygFqI/kiIl2vwXvFQp3hGtnhlMHUlvvDT llsm5/jq6nbqES20NHS1RHYKB3WRX/HZUnlpY/m3geQC9uD5xemuPlqbN/bx7u+S34WjsDf4EovF wExMOHqVJ/qidywOR3VvhfdIosamHwCE0/mox0wGGYj0tjdQpwWgfzCW+wWufxtEevnifuIZE3tp Avknr3fx8lW08fT/9hSqjy2Y6IZugPupiK4838q1qXtjqD8s/bXii+cJ63P6Bgm/B/TcJXyznbtm wASPKP21ZxRcgPN+dy2Kl/zJZ2r47nD5TVQxN4SEJ/ZMR3Y+pfXiZDNaYPwQhLF2Aul0d31huEKm clvZRyLa/txzBM2G239ydwliE+15ltAckT/5Ey191s9Cujd+YoD9GV/lmG/dYp4s8Oz8b+/0Zk57 rAMSjnCmGddM8I8DjARpd0dgbI9ZM+l/kih7CEAssUqprXrz7j8YiiNJLotxGut6tEfRyABd2zee 6zvf+z8wKBwSi8ZjUeZasl4HGKwgbcSq1GtMZtXKutmvl0oYkMuDU2aSzmBK7jc8DlJUFIrTibAg NA1PWFcD0iBhoeEhYqLikBJT0x+UlKRV1hUXpeUUmCVVloFZGYMEBulGmxxqqqoJXore41Pl4ixt re0trlCDI8vS3yQmljDn8DBYZcEBKJmCgcap2vPqNLUI/p2d3cKAwpkAHt9ACmyl4EzuOXq6+rrO rp9L32+kZmbY8SXnZvAY6F30f7WAAkXgUYHioLgVrwxMMQdAELuIEidSPNLliZ8+735poodJXz1h wbwU+LRMT4c2pQayJHGNATZtMs+0QqHQAB8+vcg5rOjzJ1Cgu3j1igXsHpcwxvAlxdLQ5AABzAYk WHDBVMusbhYwKJiiVROdLGw6CRQoKNq0atG544UR0tGPIpeCLHZpgINlaERA00rtZbY7NGtqLOyk odlyPdcybuxY18OhRDdKibKp6Uikl+fK4AdqL8A1fllyLQi2MLzUvxKzVvz4NezYO95qhGRZUifO 9pJu/rmHjIrJvGVQAOw7OtW1bDK9Gt74dnXr1jQWy65uXa2veHAn6f4STDM+71cOcItqxtnxlqVN q6ht29eT6PLPXq9vP6igPxlhzcMt97dc4fEW3jLDcSWaNOl9cM0Cgp1AUzxOvPcHMfPNN919GWrI Tknw9OJcMsDkQ1Ji/4lUBYpXjCGcGcYpaE0F7LXH34RwWXhjYjVAtCGPPSqSX3Y0HjVXb7nxtMWI ADYA1WcHvugBg3eoACFZRdVoFI5ZmjVdFz56+WUhtH0Il2XdMSVeb2g6lRteZUg1QFdPfrCeaRHW SBlPWkKkGJ/0RUYdmIEKykOH+1kZooji1XNZZoHQ/uOoZ6CgdxwdMOFxBpU3aVdjnnp2adGOg4o6 qo4lGdoCnv7lJmCAlCiKpBUGKPBmGf74Rcd6XTHn3pWIeRoqqcEKWwhwk5HJnatELmqMPiIqUSAZ oFHDlZTsLYRar78COiy33SaRzKkg3uYRq8sWyRujMUALp5OrOMmeYVdSqC2w3tp77xCmngpfoiEp SW6K5Bq5KpNmSDtCaV1VS1M4M27KKb34SjxxEDOA65Y8/X4EHpLmdlyFMgU2A4eMDhsq7wEV/kox yy3n4EVGkEiIqKqN+jawmTUTwGKtBMwZZ8mn0QgxvTPU6zLSLl+80WHjKoszrLulmWRJZPDMDQh0 /u66H8rxrRzq0UmLPfGeEzrn9KMgpYli1P6uGrJUArBY8ismS8hpp1mOvTffN1Bh9js0exRwkq2l OHDNf69bsqZW4r0yDmH3Pfm9e2pBpm3Inmuukec2dCRP2pS33Dc4PTxhMlpG9hDrflP+etKByANF 5v61apeSq3r3OUY47aGHTmLdna2WsvggOezJC2tOI7E4P67AhLOtxef5pOnhQXuY3HUUXVqoo9GL 7ak8+S4bnYxRzgueeFOOuu8Uih7q8c0eY579vK96tw7E+MiX//+oZKe+o/QHYEMKmBV6twLtoUB4 qpmdjS4Unf1tS0es2xIAM9gtL6RvfZVBFPRC/vSePhwEeFVyHO0y972eyCdyO8Cg/zQoQy85Cn2T CCEB0decPgiPaxmrHY5+4KcZEpFyZkFf9wr4QdxIRj9But97kIgl1uyviFa8outKxJFORGIXkogC 9+ADQSzZgIpYPOMZy/GnI9oGCyFMoRRrJ0Kv9WmIaLwjHrmklMtBwoseXOINVRi+HOWxkIZco+Hi yCnU5W2In7LjISM5ubANkpCIPJH+JKnJTYJvR5ZTHSJf5rcYcrKURQyiKVOpSiGuspWufCUsYynL WZYvALa0ZQ1uqctc4kCXt8ylLwNwg2D2cpc0EKYNkMlLZR6TlzrwZQ6YCQBiOnOawxymMYsJ/s1m JjOb1kwmMLdZTW6GE5fkPOc3pUnLtEizndd05zXBGc14ohOZzBTmPaeZT3SO85vLlGc1lWnOc8KT ns7cZ0ANys9jItSf3MznPtW5zqAUtJ4OvehFJYpRe87Tn/g8qEf7uVCIAhSkzRSoSDfaS3JKlKMl Xag1UTpSloYUphP1iUb7+dGXZvSZK8VoOv/50JoCtaXgbOhQT5rQH6jTpUDV6U9XKtOi0nSqOb1p RX7ZUZqKtKI8dao8USpTl06Vp0Qta1KDStQeNJWrz6SmWdWK1rTudK1YVYtWx1nWYLZ1qyalZ10D S1e/LtWuapWrXvNazrzuVatefSpZUypW/qHa9K5AKShfC6vQrs5UqZ4N6Vypqs9t9tWqhlWpRTv7 WI1OtrMxpexTLSsRr6J1r4TlrGhf+9nW5jas8SxtQkPbV4JKNrVx5a1Rd+vQq8p2HbRV7WZZa9Dn lvSeoe0pVTGb2JcmV7Pa/apPgcldhTK3uRQR5199S963epOhijUudkebTXEaFa52bWd7cYtfxa42 vDrNL3XNK+ABE7jABj4wghOs4AUzuMEOfjCEIyzhCVO4wha+MIYzrOENc7jDHv4wiDMogBELoGXl DXEqSTxiE6N4nSMm5bBO3GJOrhhpMp5xEWpsgxLfQMU44PGOS6zjGgCZyEXusY91oOIj/gOgxiQ2 8pCD/GQoJ5kGS1ZylYNsZR1nmQdX/nGXt7xlIHf5xjgeQpSnTGUkH3nFaX4zlr/M5i4v+cl1BrOc 60zmO89ZzVT2MZ+9HOgxh1nPQpZzbM+MhDe32c9NhjOjkZwDEkPE0ZQes5QrfelHF3nTfn5xpjEN ZU03WgCkNrWo40zqUad6zKdedWUVfYQhm7rTqKZ1A2yt6R3nOsj1sjSXUS1lI0tay63mNLGhzOYt A+vTjS72pOGM7GEnu9pijrWsc7znRyc72Ny+9re57W0wR27cZTQ3uMEd5Yege9255rG7af1sY0db 0OW2NbTBbeZs/8Db4/b3ttV9aGsT/lzghg44wdFdbXnXm9OGpne6w03uHaxb4tKu9r757QM3C5vj O/K4mEFNbJGDfOLQPrjCL17xdjP52yjHN8Qlnm+TQ/zi+tY4Ijg+cnwDXNI9b/jJhU3xeS+85Sxv uMjtHfOKR3zm6bZ5uDOO86GHW+c7v7qWf07zom+c6AIHOsMnzvSZQz3mTre416M+dUP0usht95uQ z93kcs9dR3GP87KPXfW0B7vU1gY2vNcd9oS3/NhOjjThoS31tUfb73lXNp4f33hWQ57TH+e7rfcs dMRbvvKbjnjZa953yoOe6ItnvOSnTe3Kr77VjA6zw4FN9lLTmcl6xnOhMb/0Oofq/vazVzzqCdFr uL+MycOnO/Fj/m5H2z33vz+38+EO++WvXPcEp77xEZ14ep8++N73QfcZ//Lxk7/85j8/+tOv/vWz v/3uX3H41/7++dO//va/P/7z/+T4f7//m/U/ABYB/wVg/w0gAR7ggNmTfUWVEFwXW1WWARYCWO2A AXZXIkRgNz3gIWCgEUxg0jjgbTFVSoGfCP6EB9qCBSICBybaCHZgVrUgxVwXPpmTMc2XPpVTTA2U fHUURzFWdd3ge9mgDx7UENZVas0ga/EXLgnUEuage1kXFM6TEtLgDWITDQ7hYj2hXp2UOzlWFdZg YU2hWAnW2CCVeA0WEUbVQIEV/nBV4WHhF0O5VTqN1VGplxFi1xoyoFNRYRzm4V/tYTGl1wz61QR2 4RYuVxwGIhduoWnVVETZlthAIRj+oXoBViWiFhumVRiGV0SBF2LxUybyQCiS1CEOFyFKoX8d1lJB YieeYkP1oG6hliaaIcvQIiJ6FGlt1SMC2Cx+FkDVlhcKIg5+IiYeVzD2oiSuoQ6+F3HhoHSlF1ex 4iX+4CsqlREyVi4e4gceVyWmoByeoB2G1R2e1S82YysS4ziqYneNYh3CoCxqI29N10w1Yi9CVjua 42sllwXa4sTY4jl641qBo0n9oyV+Iz7CVmT5ojDK4y2SYqyZ4kEqZCmiokE22WQqXqNvfZQ+nqI7 3os/duM0VqQZJiQabiJLsWMfniEgbiRufaFKilc1OmJX0WFKcmR9eddJwlQexmRALmROreCGJCMf PtQV+qEV3uIO/hRKNmNANiFS/pIC7lQoKqVZQWU44aJGWmEUXqVULWMT/iQWTldRRiE4ImE98dd/ SaI2siC+ACXfuOWowCVFveUmyeWg2KUJ9g1e1uJefokO3iUCBqZgDiZhFqZhHiZiJqZiLiZjNqZj PiZkRqZkTiZlVqZlXiZmZqZmbiZndqZnfiZohqZojiaHRQA=OwA= ------=_NextPart_000_000F_01C738D1.EB346BB0-- From Showinglcah@cimbura.com Mon Jan 15 16:35:10 2007 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6ZTy-0005j8-5I for ips-archive@lists.ietf.org; Mon, 15 Jan 2007 16:35:10 -0500 Received: from anice-256-1-108-90.w83-201.abo.wanadoo.fr ([83.201.187.90]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6ZTl-0007nB-0L for ips-archive@lists.ietf.org; Mon, 15 Jan 2007 16:35:10 -0500 Received: from Showinglcah@cimbura.com (jordan-57b24c93 [108.132.185.10]) Mon, 15 Jan 2007 22:35:27 +0100 MIME-Version: 1.0 Message-Id: <059D8D09.000003.00083@jordan-57b24c93> Date: Mon, 15 Jan 2007 22:35:09 +0100 (GMT) Content-Type: Multipart/related; type="multipart/alternative"; boundary="------------Boundary-00=_LMIXQ2LE2TQQENY1VA40" X-Mailer: IncrediMail (5252670) From: "Showinglcah@cimbura.com" X-FID: B433CDFE-B71C-42C2-A5C1-D34C076A9851 X-Priority: 3 To: Subject: sending emails X-Spam-Score: 4.0 (++++) X-Scan-Signature: 28adfdfeb3b69a8c1fb469b1c327fd44 --------------Boundary-00=_LMIXQ2LE2TQQENY1VA40 Content-Type: Multipart/Alternative; boundary="------------Boundary-00=_LMIXGNUFX4UQENY1VA40" --------------Boundary-00=_LMIXGNUFX4UQENY1VA40 Content-Type: Text/Plain; charset="windows-1251" Content-Transfer-Encoding: quoted-printable Large oz burn time hrs, small mini?=0D Best season, far out update desk.=0D Buy related prices itemsrt iwo clint eastwood?=0D Fax and directly through our.=0D Arena teamxbox gamestats, planets vaults ved fileplanet gamers rotten.=0D Every must hoping, fericito bring aaayyyy.=0D Selma, hayek love hewitt anthony hopkins ashley, judd.=0D Mastrchief big difference sing oh looking.=0D Premise, worse, sweetheart aww hey once.=0D Large oz burn time hrs, small mini?=0D =20 --------------Boundary-00=_LMIXGNUFX4UQENY1VA40 Content-Type: Text/HTML; charset="windows-1251" Content-Transfer-Encoding: quoted-printable
Large oz burn time hrs, small mini?
Best season, far out update desk.
Buy related prices itemsrt iwo clint eastwood?
Fax and directly through our.
Arena teamxbox gamestats, planets vaults ved fileplanet gamers rotten.
Every must hoping, fericito bring aaayyyy.
Selma, hayek love hewitt anthony hopkins ashley, judd.
Mastrchief big difference sing oh looking.
Premise, worse, sweetheart aww hey once.
Large oz burn time hrs, small mini?
 
3D"FREE<= /HTML> --------------Boundary-00=_LMIXGNUFX4UQENY1VA40-- --------------Boundary-00=_LMIXQ2LE2TQQENY1VA40 Content-Type: image/jpeg; name="496-E596A76.jpg" Content-Transfer-Encoding: base64 Content-ID: /9j/4AAQSkZJRgABAgAAZABkAAD/7AARRHVja3kAAQAEAAAAUAAA/+4AJkFkb2JlAGTAAAAAAQMA FQQDBgoNAAAMRAAAErgAABxuAAApE//bAIQAAgICAgICAgICAgMCAgIDBAMCAgMEBQQEBAQEBQYF BQUFBQUGBgcHCAcHBgkJCgoJCQwMDAwMDAwMDAwMDAwMDAEDAwMFBAUJBgYJDQsJCw0PDg4ODg8P DAwMDAwPDwwMDAwMDA8MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwM/8IAEQgBZAD7AwERAAIR AQMRAf/EAO8AAQACAgMBAQAAAAAAAAAAAAAFBgcIAwQJAgEBAQACAwEAAAAAAAAAAAAAAAACBAED BQYQAAEDAwMDAwQDAAMAAAAAAAEAAgMRBAVAEgYQIRMgIhQwMTIHYJAWIyQVEQABAgMDCAQIDQEJ AQAAAAABAgMAEQQhMRJAQVFhIjITBRBxgUIgocHRYiMUBjDwkbHhUnKCwjNDUyQVYJDxorJjc4OE JRIAAQMEAgIDAAAAAAAAAAAAEUABIQAgUGAQYTCQcIECEwEAAgEDAgUEAwEBAQAAAAABABEhMUFR QGEQcYGRofCxwdEgMOHxYJD/2gAMAwEAAhEDEQAAAd/gAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAD8OrGXBGUls1gAAAAAAAAAAAAcWM9OE+jCfXjL5LTZrAAAAAAAA AAAACC07ePEvrKN1TxPxevSKl/cD2HjwAAAAAAAAAAAOhCVVq2ZLbCM17KrUsVKna165fc9Fvb+F AAAAAAAAAAAAp9WxwYmwqVS1RqV2oVbGMtdn0Z9l4wAAAAAAAAAAAdSOaVTtSOzEHp20ShexhQ6N F076TLPqL7LxIAAAAAAAAAAAqVWxw4n1oZxhyOrTdFnGui3jjXtpF+PsL6jw4AAAAAAAAAAHRhKo 1LXanGH0bsZ83o67cru12UMeWcU3r6fbbr+LAAAAAAAAAAAx5Qu9ycetGVap2arUtamc/u0uaAva ZrZo9e/QePAAAAAAAAAAERq2Y3oXZfbrhtO+pU7lZp2tcF6lXcbo7+HluVbJnX5oAAAAAAAAAAx1 St8GJfOM1CjbqtS7TqlyuW9W1/W4U5t09zfqsm7UAAAAAAAAAAMa0bfS17YDRvpXPv1uta590dl/ Q+a/M4q2ndBatueOrzAAAAAAAAAAODGcW827ijk9itabUPp3werfsT3fNS+7RXNW6GhOPjLbX0PC AAAAAAAAAArejbrj5n0WKavW6Ms9PXOBjnNdviWuzVgY74iOzqs70+r8sAAAAAAAAABivl39VfO+ rjtueFiI1yxZar2bZX2P01YmO6Hxv5pQ3y9d5MAAAAAAAAADF/Nu658X0EJjbXU8KWquIe/5vIGp tX5z0d521e7LV9Txtf6LigAAAAAAAAARWqet/H7OCef2Nfb9TEnc839ZhwmQa1ndrh9aRrWOprlu 37PygAAAAAAAAAA6cc+dFO/p7bqRMoj9w/MputfvNXoWvTv9fO15YAAAAAAAAADomlsc6fs4ly+W e7DPElI6Op3dV3sw3yEc+3vV8gAAAAAAAAAKPhrPjGnTOGMy5sZltUrlps5j4/WokLsJts/LPNKP s76HwwAAAAAAAAGAqe7C046U2IY/ZkIZnoz3mnHM3Pu6jcfsVnXu6eu3x5zzZj61+x8MAAAAAAAA ImOcHVdnntrsUexpr04ZQzj06nDL+URCWiXnu9Tqt+Nhc4cZ+8x9SvY+FAAAAAAAAxjpnG15afat molyGxNDd2+nV9L5xmQDXnmXdZuB6vi2z68XVi9NvY+EAAAAAAAGEaO7HNbZg+WdXL+neWcNkNOc lWYdgAFS1T1G8x6yKbofVOIxL0q9l4UAAAAAAfhrfV26mapWLfDOe2Gx0sWHIAAD8MA8brYv53Up 2i5fujztwvQeaAAAAAAEdHPKx3JAAAAAB+EXrmJXZAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD// 2gAIAQEAAQUC/o+MrQvK7WOe1qMxTnrysC8zNXJdVcFUKR4WXfNat/0Y26m5k8cEFGjcppgFNcFX U++PZHqr6QvlaKJ76CeRTXCmn2rd31E8vhijaSSKKZ9FdvV3c1E9zVfIGpvX75GiglJIu710ckt6 Cr6fvLc0XydRPMIWMCP2lNFmYvPA68eDPcblczUW726e4m89wOwe9TTKeUPWa/698+fsLee9P+dy OzTX0/x7W27pzi0SSqaYqV65Z7ZsVh8pnp8HwzD8fj/9Jmnz8tFbx+yalJpNpmkqppqFvHH8nu7L Gx2ds20toz5W6fKs33puGtE141T3O5Sze3H4a5zUlrbW1jBLdsap740+adNI8RMv5QIri/7vvO8l zUSXAXGZw3ES37ipLpPmqvNpsnI1kOSy/wAtPuHE+UhOkKmmXH8iG2108te6dPmct3bS8reWWTwV 4qox0EtGjJ5KOAcUyIube0uhcNuWOgcXVW11NLylm6ykionUCuLkMGXzQjUcdxkbiLN2WIVlLBfQ xS9hj7N4+N20t5aMvYMnjJ7V19MYFls06rnFx3v2LA8husJLj8laZG2lhZKvg29NNNDDOz9gclwb X3NtLbn0R3E7YLbkebtx/r81t0tzc29nBmM9lOcsvMhi8OiSSvHtaxkkrhbFqESEa2e3SZzkON4/ b5jy5WPk/L582UyN8jv+K2WI47kM3JLjsdjI7mxFfi0Xxl4Pbo+XcukwM8eTwGKsuQckyPIrlRQb 1bRXF7LxD9TRQnkWLjt5r+PtAfJG+Lv414/bor2+tMdb5Hj1ryqZ8+NsM9mcNcYmdkbGjjvFsxyy 54vwzFcYgV9atvbbIY9xu7m2jgkMa8a8fbQ8g5VjuPsk8Fo3l/Obm/TrhYaJ2e4Pwn9d3fIZLDH2 eMtuuZsPFnDHU+NOjWw00Ga5hZWb8VkuN4pc05deZCO2sMhl5+Jfqdts/G8QwuJEUUcMfoy9t5YL yy8F4YFM3aqGn1+S56/vraTHcvvzj/1nySdY79XWLG2GKx+LZ9DkGILJp4C1Otp55P8AG5Lx/Wur aO8gggito/qzWVpcKCxtLb+Bf//aAAgBAgABBQL+j6qrra9Kqur3dSpqtXyNU77N6Epzk4qmqf1c USjqiaIdCU5OOreehT5KHeigtuoJp1KlFVXoxupJqUU4olbUGoHavLp3Ggb0JRKcmINRa1q8w08p TUUSnFVUIW0oRgKunlW5Fyc5VTIi9NaGrci9b9PK7sZFuVelu7271u6V00hoJJd3pjdQlVVdPdfi AqKioo4tyuIqFpqvtqLn8adY4tya2ikZvBaqrYFTTObuD46dIod3okj3I9iRVeMaeiMTT6i0VdE0 rwjWE0W9blVV1X3TpA1PdVB9F5FvW7SSSEJr93UnpRSs7u9FdGTRfdO7hj9yqgOpFU9vc6Vz6dO7 1RP9rvTI33DSSSUTChVxCovH6nhFtCjoS6qEa2qn0p4+7gqVXxj9ciqAp9YtBQaB/Av/2gAIAQMA AQUC/o+oqa2ioqKmr29QoKOXxdUEegCAQC3HVN6gIBU1Q6hNTQqapvQJkdVsTUdSBXqFCdpI611A FB0AQamHsiqjTtFSegCAQUakkDU6Vz149PEiggE0IBPk2IvRedQxbUGJrUApJhGnOLlRBq26dgTY 0GINQCuvzDVt6U0zVHDtVFTrOyqatqpp7f8AKqqqqqfJtUcm4PZtTDXUQfkHdZJQxPkLlE8sIcix eRwW7TA0UclU3upptiJr1ZJtQNUHUXkOobI4KtfSz8W11Na+gNLk2CiDFtVNW2IlMFE3TtbVObT0 7lE/s1fYjThObT0g0THdo++lAr0+yqm+prvaNI1qK+yqqqvqCjfVtUNCAi5V+nBJRNctwC+UNcHE IuJ/gX//2gAIAQICBj8C9PxbfQ9n1r5/Xw8F44moVF7RgDnpUQ2ANd3hOf1ybilDUXqfEEceU7J/ /9oACAEDAgY/AvT8H30tsU1C+V3dF8+cCWXTR4ipVd4ULoXzUaAaLpo5Fw0EbJ//2gAIAQEBBj8C /uPrNqLhllp7IsEo2lRvRvZWUNZt5fgGpYUSlP5jfmje/Tn48qcULDKSeswOi+UaoUg6LIlm9pl2 Xy+XKksjdRarr6TbCgb4tuj/ANWLxZSpei4a4KlWqVaT0mUSnhKM0GL/ANXKUtg2N39fRYqRjhPW K7h0wbdYjEL88K0xOf6k8on3juCMSjMm09KszibW164OKxSbFQbbM8Kj7v4soVLdTsp6D0EGHEi5 VsSnDnClJO8TE+AqXA4u6dzHLF1ZO67nAkjrNkCL4InGkRZDCx3gRHs3LacvEfnPGxpsemqEvV7o 5jW7xKrGkq9FGftjcPyd3zZPRsfuLKyNSP8AGJwR4DWNZY5fRKnWPi8z7iNZ8UN0XLqdPL6Ju5IF p16z1xiKeK59dVsXjRk7S1HYbbw9pMz5IIFgEWGcG2CZwcC+BStmT9Qf9KdcN09MjC20JJHli+eq L8Ii/JlOKuSIStxUlOKJiQNueDJXZ0XwjSpxaj2mCm7SIst1xaY+nJk4zJueJzqTbClAYUixtMds TicXxSIJkhxGCfpAmCrMrosMb2by5MJd6Y+bpvgzgi9WiHadbk3WVlQHor+mPZ35cYWBR70W7puM aYu7vlyZH2vN0m2Chs4nDGEETNrjizJCE51KOYQ1S8qYD7QWFcx5i4n1tRLM2DuIGbOc+iG6hhQc bcGJKx8bxGCqQXUfuC8dYzxxKZ5LnoTjdTov15MphyydytEFtYnnQsXEQoGyFNNHazmCpRmTBbxS QTNSdPX0bPrqRw+upifGnQYYqadVlQnEhBsVYcJs1ERaB8eqNz4zycofQFozzhXK+QN+1VQVJ7mA OJKfQb0nXEqnYqFWlg76ft6Oq/wUshakhLnEQRenqgBNctxIzOyX4zbH5jW5P8v0smdqqp5NPTsJ xPPLMkpGuKqm5O//AET3VZChU84dElVOG8JExJGnx6IVSe7/APJq7qj3hcG3rFOnuD0r4JJmTeeg LcsnuJzmJISVHVG1f0/c/FkqXa5wl104aShaGN99f1W0C0wrm/vq+OX8opjxKX3dSvYToNQofmLP 1RHsdGn2DkzOyxRo2cQF2OXzdGFAmYzPP/5RHFXNil71QoX6kDPHsrAl+4si0nWYmkdP3fxZI1TI S2006j11c53VrngCE3ZpmcVfvMurqOf81kE1dY8AqpbxbiMI2WmzmKdk6c0casXgZQf41GncbHlO voxqOBoXq80JouWMKWpZls3nrhrmHvH65Q2m+W5v+zzQl5htLTDjeEISJJSUZpCFE9vbBQU7h3tM XdF3d/FkaqqtqEUzCL3FmVuiG+be8FOaPlVI2os0KppdUBPbfIusuA+WK0crefHIFFTSFLM3UsuC Sjh7yfRN4vthIcSPZqgY6OoQcTbiDaCg5wQY4j273W85hLdK1wqRO++bEJEJFO2HquXrKpQtnq6H GFd4bB0HNCqUjbxFB6xHs7W0Kex1elf0dPZ5ciQl3FU1z5w01Aza4omP6/z6rqEocQkNcoewFKFm 5KW0iZWesxVUyHuC3YltptUhTy+s4m1bhuwjZGuDw0hCSLVkTWRcersjm9A+jG97uLTVcrcN4S4V Tb6iQYRzHm2Kn5cDMJN69Q+PmhFJRMJYYbuSny+Al+WzUIK0/azwpRvWSo9p6ezy5C5SUrntD6dl XB21YrDhSBnlDnMa9VM5zx5ZWKZTiF1SJnvLcKcJ1WShCFUiqMNYv5imykpSqzC0T3lZyCYQzR0j j5VYy02JiWkHPrhnmPvC5jfQcbdA2dkKGdR8kVqKNhSW6+QqEKUVbItwid0IaaQG2mxhQ2mwAeCl 4CblIriD7Pe8UPtd3FiR9k2xd0dnlyCqpuQNVDlE1sV3NKZsurVOzh06RfrVcIWml5JXUjTljiuG oOuf8jpCb9AknVA4zLVCj/cWPmTOP/puoqFApKOGm1JBnsqzfJBRQ0jdOCSThGdVp+BaqGU4mwMN miLpQENoK1KsAEbu37LxMPp49zrw2/Drp3sXDXLFhJTcZ3iEtMpwITcB8NN6nQsm8yibFOhs/WAt +X+wX//aAAgBAQMBPyH/AOHq1lwTnL463ORPdONOWO5xHOkXGF9ZLJ8O52mm3Lu+ASwR7Mzoi7fM a6358eqZlqn0CAINN58JyRKmWAqrdoz4P43qh95t1p7EIVp3l5mu8Gk4bShZfwipFSGmU246kgnq K5loRG1VrdZWhGlvtzMSfcIyjWAbynyeeqN72zef+iZi6iCyjHEfPdOUeFDBpsdE01y0eJWvorq+ ofPODlYrdg2crrKKKNN42OkoJg0tQS2thDvoxj5hQix2alvm6janem8Gr6sxc1xK/RqRLbcQalSa x6MwD8yxaBlgFydoJ68D4d34vp81V8Q33lini+JpJjV59JdkX2lBMLvxNY8oRGFWPozFWdu43XB5 auxDN5p6DkvDn2kx3iq7vvq9P06fC31LAMyVH5RKxZqkpL0jezEthb3lsHcvjV807Mw3V7xbvdN1 QhRPVdjQnuW49un01MTuvgIdYwWtQlNQW6P4iWqzmqjnoGfvKlTArbc0709CHl/IBcq5WWN38NPe OVXJi1+3fpsdl5m1gV4NuNalLI5W7ZoiZDf5S0znW784Lh32mbSjjfAfBM1VGg/MR1W5fiZjY86z Tr9H79Ng3r3J4e9QxlduQvfzjhy7vvB1s0wGDKbvuhXEfQ6/OWqpsnDFNwvfWN1M7y2z+/TPomGH nyR9zesTYm9pvHYKo1gNrZ/eWcPbCZD0LSxgHYDz3f8Asxw73+Z3VtKnybprVdl+X4hG1mbgo2lk 0DUnP8O018VV61PAf4ZxMXvbvcxLGpTxGeWpt34THaCLzjC+pcRdiRjzNSbGzjTurXXpmsTmGqN5 ovT6giNZIjeAOKJwylZUBUwwI07q8EAM5SZ5v8HftnMmsoUKXqCZB9plKY09NPjPp9YxRt73tDi5 Tr0R+8o2vWWIwMsDnDf3eYPGpcsLmRE7tpjeiB8K/Ka3JxNcb16ZXVCxOqmLPa+fuR8wY1QZZK6m nRKza3dk1iJn22VXVXw2x5/K9idldDQmjr+EauJVtKdL8kVygwZIXfQ3YAhRdi2i7bCabpCz6YBu oY0bHB3c+BJr/HnK/wBwv5hN9U9Y+g2l7NKsHkfWS01m5HSqCNpbb0nlfYd1ApSTIVGMTWedSGi3 SFbAmoyeNZbnHyLL2MeDl3cd+0CpFguzFr67SrmtyOorX6XxBPIBgcHACRzII3Js4IFtH+RxJQvS D47dJamUAEFYBeq7BFqAGm3Yo6lrpeyFqIpV2pjbsNHkG5sLRjZoEvOzkYDxf9T2igElXyF+u1uI lU6uxZz089fIx4Yb2zhdUaaKo2SWZ/KgEXt5e8a5+JTb0W24uu0tjb78S5CM2TGrhoMpXoSlqmlt YDDYwuuECbIr8dm8Ktnb4ktbgd2CECAqrYfo35AKSgVbpa3f4CZ7chXyzNupJykqbS8uvScXh0O+ Fi6W6Ly0oA0y/bqEdhgoq46q1Rc1bY6GrR1SyeCQMe8D5pTK/MkxubKcIZJzftRbUWu8BPsQC0AP 4+t+A6D93pApMLPOFXvKHlKVJn4nL/vdMukz2ZeKtql0VNpZfX+g11WbyPvNZZO7O/Lgq4TYvRWm 1UmEeM7mKmr3f6EERLHUic7ABUtg9Lg2VtY4bKRb9p/kt3/0Mf37MDVGilg1jME6GgV64/todS48 6pHJ9TMbV/X7gz/4L//aAAgBAgMBPyH/AOHz1oteBZSV6t2nivCFvjqlUCj+OFeqVtQi+IqV1NS5 l4VRyyX1VjUPCkBheC9fTfqKkDeMdSrBQblkrqsXi7l4AR5OnzHgceNq4bWXsyR9fmdr/nT1UQeG qWeBVXb6+YLgwfMz2r36gcjKHh2Rh3GnP1vCKIg6gLUIy8BUZWB74t8F304Mk1MPBZrMc6RI+Fi+ mfiNPA77SiaxX2moaxylyumNxh4XHdukA0QbUUUdYYVnBdXTjoYmMcTsCBWniPnhsWvU4Q6xDSH8 fQdTYJ5vTsDxu9IBzG+kYeqlqZ8swZrHUJi9O26uYfm8aJXM7prDeYxJdS+kALY5XwTZf68+8Id4 7CUQPCtXgBBo2j4V0QeebfHMlunECTF2uvrA/jWIy8Hou6JVqL9bwWvZBWngy1f5WEu/EvoGw98r mcK/1JUxJd0T7H0f3gKYAo/u14mmn/gv/9oACAEDAwE/If8A4fHWoXCSLS3VnLxEtfPPy6o2+CvE 6259rqjRfgHjJefrqRbGEMMrhTqji/EAgQIOpuR8XkkHaVUXq8B4dEulj6ixHhDxMRYgdqYbEl+n GrH4LvAwwz3Zc3kxMrp3iFo0o8MnnhEIHUWFx1x4hT4I+J4JFdONuPDBjBLmePomZ4AyumNmH8HM Ww8TLux9pTlSzpnUWS7gQiMX4A7SzSXZxY4B6ffuDGCBgQ7tleDeSV7NI3UMU0ht3G6/429e4uoD UUvHSMUJvpXDqIPExMzgSthHcolErpC1MWQ8Dw7JoPBXgEldGFwaxMddPtLGNJUWXfhcuUyKOb7Q 6RY7QB4WRC/xslgeOOht1nElAjy/oXKt8OXQ0a+Iv+qsuBKtsz+vxz/eNRb/ALtAZqD/AOC//9oA DAMBAAIRAxEAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQ4A AAAAAAAAAAAABJYAAAAAAAAAAAAAYdEAAAAAAAAAAAAEW3AAAAAAAAAAAAACNb0AAAAAAAAAAAAl Vi0AAAAAAAAAAADT5VgAAAAAAAAAAAV1W9gAAAAAAAAAAATR/UgAAAAAAAAAABfwu/cAAAAAAAAA ADy/eJ8AAAAAAAAAACI+hs4AAAAAAAAAASYBjbsAAAAAAAAAAA64sbQAAAAAAAAAAf8AKweEAAAA AAAAAAEj3lEdAAAAAAAAAACMZtklAAAAAAAAAAA7RKCGAAAAAAAAAAAFMd32AAAAAAAAAAVdjWM2 AAAAAAAAABZvh7HqAAAAAAAAATR8otHmAAAAAAAAGr6wAFfUAAAAAAAAab1gAFR1AAAAAAAg4CAA AEAQAAAAAAAzAAAAAAhYAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA/9oACAEBAwE/EP8A4egFANVw EMoOzWPd+pvbl1nTStdes0bNgyvQiLB2Mj7aETWDbsPxAzOLGyY9GnO969W5ojdZhhNuOfbmDBbM o2vncQG0mdwKdJjEDoqpu19Nyfbc8n59UTm3wM0eS3LilKdy8sw1a5QUHgJv2gk0WS9M+feU0rW5 zSU+c+oH9jw6p0MZTs8PU+YDbhlgBUFWrSBEq3aekGxnA3aOa5l+diOladyaPsPbP79TRE3l23va 9o0FeqZCwhTFvnpEw/soLZKGxQXjSKsRulN1ctzVjcqq7ma7e7Wq6nQaLNHSH6MykoeivMLdZhrT kYYhKi0A2O8ISU3wLhuFbLYRWN7bgsFal1ovITYtal7fndRQRbTw6vY1Yyq6nVFrHLNLR0aL2uAb W5rXclshjkEMys+4LZfyFwcpU7Mzv34iKeRrnAvecl6j3gveRom2o+0zDU0WMeUoqyhCmb8uIZFp aO2OZXKZVby6MC2USaNv3QVKYDl5YKOC0kdrZ8fv+u/RfTPTiYb2eS0Ozb0l2E1HU8a3xxDrSCkz bRseZg38yHmCKSnF40uz8S1lLKacqd8wVXbeS2eULtwDhu7PvGSgyCuCHlBe8QYbjuUZWRozyQ+F XOS5MXuxfT1GEPvIRtYgBNCwajrQ1zSMJYQoYspMcDp2vsQgVS4QwtDmoEjmlYKoS312iYq2C0av e+NI1lQNoK5hDk1AqDpHsEqqK7jbLCKZurBunxE2P+obvjp3BC5Wbs7ZXeEQChXRoSrugvTaBA6y 0usoUHTF1sRgIUGheL8sjLIBuzkpphppFii9jQ25ejnUFvA0eZ6nLlvdhlYSKzFpTz/6hgWy0P2+ s1G/ejTC/LplpsO9weriXtyUs0V25PoFQQAAPI4MmRt1lXNkWpAqcuQXmKR1cNlpsvvFAdQKZ0OA blYBrqZD6jHAuTFZMZasfTb9g8kGw6Lb7Np3fGjXppAu/nB7n4IIpKyI8GmFpbXltDAC5tuwNNtW YDa3z0bdONoWoEQR76j6ypYBfRjN1AXwGhQFG2o9obUc15Uq/J+8Ne0Ws4+YigjBtV33n1x/j0w2 kyAa1v8AtKrZaWLhr2mtttWCgxWOYAWFuWv0edXHgdItWqx8REVDkycMUUJgpLgssNkcWXLcz6Tc ZVo6m+iCW/rpgMUsnkspAAchua63l7YV02ZWAvZUh2K93/NSPP1ARnOfm4batsxZVZgxrMBsetve aWtc4w88q66ChVjoybY1hy0KUQAr1wbppwqqNUJtGx0CnhnDjwp7MfSuaR3Npd2qU3Tnd/CM1r01 EUxx0oXMeTyHjJnsmzErcVO/YxFOqEjt/MQCitarAtoN7iU9C9NtfBP59Y6DHaApxRgaMV6Chaqm yVa6XojBspAJW73KjOecO3qNa31+3TtX4h4plGCjkSXSSRtkAKy03ck0NFuOoOW42PmsC/AoK1Wl /qPDBHPuVpAU0bpeN8wUiC0oMWoj1JH/ABhjpiL/AMwcqA4OXBmFZUvMlOGst5klDxRJEdXhdQFr UnoAbUloZVcq+F3CD8GfI+lxW85WJyLsHLGDvIaHghKJRndufKcM/fpd4X1XGryAcLsEs1ErbW/o oFdhcRXT0A/WzRfO8HgyA0o0G6tA7sT4eU+hG45Zey92W6s1ZcDYd3aC3AtTjKQtvYAbYjTFNcCe dxcmRdQRyUvLx6TRU26ea+kTQkHbEO7UxNlbEwZABVb+5JAw7PSeY7Byp7cwCF2by66g6vfSPUIW LQNiK1bq4F4hVVFCb4Mg8q8cyy5TYXFAJQFYYCQvfm3l7ysCqAU01TWdJTpKhAq8kqN5rYSfYtN+ jXa+JRyq3tWFdIXclexczBUC2GbgcViDQopjApWV1D1WJXKjgo4SnObhhdnhFrajbFLQp0QeyDIB RJERU1DqTgULKykBLcmafJw9rgJlfeBb5JFBUO2WjmbF5uC7FLAG3lKwR7Iqf4g06IYRhEYCpA2m rbFGJYfv0FWCjfXeljIIg0FkFaWw2BincYlJoEip2HctYZhOAEXqTE0FNqjwSGhQmC7VpFB9EaiD dmALdqCgD+FkPE2LQnenuivB50gXfeFjXt6cRKCDILFHvOR87foR18amaKshFxxnIgP5+NLEwlWg UNACqfY3uTDugk0/j7+YAKFi1pQUA07+Bnj8STc1Skipit6uRFWp4wED9CsuhwAH8Qq6wC6NHfVB h5TDbq9NqrHYA7K48oCMUYvHYz5v+396gUAFq6BNrGfrNtixgvClsUB003BZ5IbIpNgVSMWld6hK bb+eWHErBGpArRz5pQKCFCjBjH9AJhIhYjqJK/McHS1XxG9VLqoOSx9YQUyNS1gDlufiQ+mA55f3 sFoTkArQQC6SxwwgNygaKsALay1/agoBwlwVPAEVaXUveD2ah8eMlPX/AMF//9oACAECAwE/EP8A 4fCaS/WDqjxnKyredzqyV2N4S4ZBm8bn5JivO75rqrZ7QACXAIktKczb+ua6p6uhrDUrIEG0dZTL fnqQRQWt1iQtUBtJSrSpmSsXW35rqag7Q0SyYaZuZ2eZeYl2ZuqaT6auoGyXZbzI8BgN9nvDa6zT S4T8eou60MQwSiJeuIThgKqJCyzMpV20v0ur8r3079Pf7tvOZkSMstK+vr/IlXtCVEo0egPr8Rag pttjt+WOxO80vR9Xl306cxzK+3/ZhuVRJYmgihzA4NCl1yt+tP28JvqzlfXf2jeHcyf0ekpz04WH Gn5/BEiG0Oo1tZvS5Kjrw7B/xv2RJ4Pr53ZrDMWJf6PrHTALYStq37cS7BNt9ZjPggRebTskW6Ro t6faFRq+kV4VsHa/uyzBo7xjaIxsUseu0UcMFvFNJo12/PTIVN/2QlIWiW8SuYSSNDCAef0JTt83 P+/9l6nTw3rTb89NW+f6gTce0QFOJXiufMDBRHWpt2T8cw06Gv7/AFDKCOdzzN/PWCXd2/zWaND3 OmZScseTOeOjyRzDNCjxLvQ6P4e32jk6Gv4TtC1/XtMf1z05NC528+qgAo08blRmIvJ384kuD2x/ k7nu/wA6dWSg8VqvdLY6IHahS2X6ValsDwAWx8r7obr8P3LOrfgi1kLRilenSCt91tXpeeMMK40U 8mp5n1xK8NllglvNgn8PrWUDFo9tILZlxFLwaNfq+jUJQStg1a7v69MsDYUtjbDQpgRo4T4nZTU+ vmIw8w8wDwJ1GH3S0Xd5/wCQ8SneV6IvOeEShiTT/Gl79t3EEfkOzn/fYhlOX4vaYZig9Sn8Pmd5 Tg0/jQhrfvUIFd244NI61lY9Pz0L/JbEopK0KcVuoq+OCCUHj9u3Z1YBrV93eZiMSjIG3z+P5Zc1 M/v4hLaXjyckSsQUS1en56C/KzfZ6c+kJ6X5/j/bl1mvvDFQA/pIBjR/cA3VMBAW5h05+t/hn+9B oMABQf3aLM0KPL/wX//aAAgBAwMBPxD/AOHysp1i6JyTgJdt1lUX4K8AUjLp+DNW2z46qhJZb8Ds 92PUn0eefbqu6GLLHwNFNIQslv2dTTEoFGkUVlWstWlj4Kuprs3iwA5JqEN+0UqVlbTBKz9cdQtE VYIQ3HF3anJFnBlYxS1+v46imvVzHLLpdGFko728I6Mz671rvWnn09NGMBZvw3znJKkMUUO275Rt BTjX329J3z3348/np7+0V7/8mWpczK2IBLIoZksH5eD7/MJ3fjPrtBaujgx1CthzcRXzEakwqhLU oyWafk9vljFLX69ozL+/T7FEYg0l5aTDk+qlyUR18UHtB1hbwrp096xa4PNjsHLvBEBxAaRpG1JG 4qRuQt4al6dMVrb9MG41il8CVMEXNiOSqodDvH3PmvppAxawrMmu/wCOmp3wgo3ZeXLsS5XkQzlW idn88QQS1L1vYdPR28pk6d6/Ok9XPTOImWiASH6/2ef6jV7WPgbrXj+SED2phBfrzmXX6rp3bVSx qXoc94yLK+NRZbqF5tGoYBz5n/Jjg+f304IUuXJ8aNUuAX7Rcs34lIxANpq06ZeJuvgEHqgH7j2g U0HywRmDRCVv646TLVH18RKtueTmUeAuABwRpx77/wCRFvKP3jvBDI5mZOOWv1/HRoqNZoVL9v3G 7LuPuO3aVDqafqVNZTFavBzEK3oSjFOYfTeGjw313/HRaRpzLz831tDNc8xbpgmUtdvTJ+vKW/xt eCe0IAaAHxEl1Lt6/joUz0QK4ggnXvLm/oRUK6FfyrU2cTkuqfMxCVFF+v46AcnXBLsXjtE1UWv9 QqdcnnFbzOgT02Ps/L+9FZEVv92rBNfn/wAF/9k= --------------Boundary-00=_LMIXQ2LE2TQQENY1VA40 Content-Type: image/gif; name="knows62.gif" Content-Transfer-Encoding: base64 Content-ID: R0lGODlhRAGoAIfoAAAADIsAAAB6Co13BwAChosAeACLer65scLpx53P+jIbB2IoAH4sCK0aDbYg AOEjAAA2ABNDA0lHAGtBAIo3AJxLCb9GAOA4AABcBCxgAjZUAFtYC3dtApVcCLlnBu1pAAB2CCV8 CjSMAFxyAIpzBqWGAM11CuqHAACjACOeCESXAGicAHKeAKCsALabB+SdAADGACK5ADO4AGm6AIvE Ca7IAsPIAN66AAHWABPiAEPsBFzoBILXB57nALbTAOXdAAABRiAAR0QNQFsOSHwARJwAOccISO4C OwggMygXOD8tQWMiRnorOaEuRMAWSt0oMgBDNxM2R0c3P1U+P41KM6M2Q8tIQ9YxQABbPhZXMT1e O11RQndeAKhWQbFhMdhbSgB9NCp5QjR2RVeLNYCDS5l3SMd0O+SNPg6cRiadPDuUTGaeTYSpPZ+m P7amONGgOQLERxy7RDK0MWnJM4m9OazBOc3LN9e2SQ3mTSrlNkfXS27WSY3dSJrVQcjuQeXXSwcI ehkEjToAcVMAioUAjq4MhssHd+QMdAAifRUfiDsjd2oThYcmdaAfc8cbh+0igQtEgRs1iEw3dmBG gng+iq00csE8fdRAhgVoexlSgjJufGRjgXNrgatceLJmcuNshQ6Nhx+GeEmFcmOBjXtxiZx8frd3 e+Z5iwCaixemgEelh1GgjoqUjqelgLmtctqajQDIeiy/i07Fh2C0dIi+gZHGhb3Edtm8jAfpiRfZ hjLth1rkdHXgc5jjeMrne9HjhgEAyhUAsU0FuFsCsYYCv6cAxMUAtuEBtAAavCkYsTUrvVwqy4Ad tZQuvbwuxeIWyAM7xRNAw0g+wm09uos8valHsrs1y9RNzAlltRFYwURivm5ky3dRyK1oyshiudtn xwCEsRN4w0l7u1x2u41/vqWKzrx6wOdxzQKWxRmWuDyTx1uXwoSuxpmVtbKiteWTyAHKvC7Jwj+5 yGHAvYzGxpq7u/T46ZKWloRygf8GAAD/A///AAMN//wO8A75/f/w/yH5BADh65kALAAAAABEAagA Bwj/AO0JHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIBP+G0mypMmTKFOqXMmypcuX MGPKnEmzpk2XIXPq3MkT4s2fQIMKHUq06MqeSEMaXcq0qdOnUKNKnUq1qtWrWLNqHZm0q9evILeK HUu2rNmzaNOqXcu2rdugYOPKnUu3bty3ePPq3cu3r9+/gAMLHky4sGHDdhMrXsyY8eG1jSMjfUxZ puTLOitrxom5s2efm7F+Hk0wtGmipFOrXs26tevXsGPLnk27tlcAAGzr3s2bIO7eEk9X3oi7eO6L vyEmD2l8YHPnxo9HPz5X+GDcJbGvjP6vOMnp2Y2H/3cKIPvI8ue/o0RvvT1U7Se1w/dOH7337vbZ z2dvlL/59ACa5B9qwLkmFHwC5vedgvidpx+DDTo43oEp6adefJAVCNt0vhXXoUDJhUidiNCVaGJG 1BUUHXTPcdiae2nth6B8DO4n4Y0RLpWibzzasyOIGgYJWn8PzlgjhDQuqCRTAwbYnZMXwiglkRPi eGOS+Im34H1W9vcff/atN+WYRSlg5pkmBRAAVAssUJKaRakJp4NcKoDSmWiSaV1PZu6kJkEOOCDk ZHrG2ORe+SSqaKL/LKroP3iiKeekhVYaFIKWZqrppnsN6hinoIYq6qik1uTpqTpRgGpwp0HQ3qH/ oP8g66wmoXASBK6SlCtJtpYaFK7A7poSrlUJW5KxJc1K60+wEgXDsyrpk9KzMAgIYJO9iqrRcsvV Re2zA2EgbkIwHCTuuRg8lK495RLU7ooPQXCQvAihoBAOBdlrj776FrTuqkgJIMBAAoP43L794qCw wgN92+6JDclLr0H6JPQvQRNDNLBA/XIsUMYZF1TSuSghS5I+KKN8EgYm5eqqyVBuuu2Ixwm8McEb d8txv7K6+3BD5f5MUMX1KkvwRNSFTC/RAjHN0M0EdazQjlLbU/DGBReEL8AMCbXwwiRBa5LCI5Fd a7ay/mT2SQK8xPI/X+PwUtu6tjwS3XfD9LZJeLP/JPexKsn99991a5sRuAYhjjG9UEBhkM2QY2Sz QWA4FDKQT7tbULsOQyS0QI5HrCJC9Ja+OdddX9okGGCcBAQQI7HuOuxEtf6P7STR3pLuJfGuEpjW /uN7S0dTnhAQBCGfPELSYT5Q5ajvRAABB01vkPX2vH499QJhLxAwwEjEPffOFaS8PeEPlL75DZFv j/vvd0/R+d1P7z39r2s/UP76D+S+9/KLnvTgJxB+8GN76gMf+AZiwAYWZIEPsR8A+Xc++h3sfw3Z 0Yj2RxECHmR9H/mRAE8lQoocjCEH7FCK6OcQCXowJ/8ZVZBAeBuECKZZmRrhQi7lq+HoUCcv7EkP /5nywyLucIhGTKISHxIqHA7xiWrBFIUqJKUlImU6OgNJFjECL4hZ8YsV2eJBuugiHx2MjCV0SG5E uEYwFrEoUuQOnaqEpRxhSooxKc+AwgTFPm6nWXXEUR1tBEf/WCgvbkyNGA3GyA81EotenBnNTpjI SjIkiy7SGbekU8JFWqR5o1OMHwFjpgQtqU1pWtM/5DSSUrbSTiOZE0lceRNYwrIkt+yLJTdSFEbh 0paulOKkZNmmYpokT/9oQANqiac7kWSXAIuTKktSTGO6BJVYyeUzoclNpCQqLgpYYh8XM8wkjnIr 3XzROW2SztGsUyjt5No758mWeMpGcUakZ6HW5v+StNHka/0kSd9UUi19VmpZI0EoTIgFE37GRFoj gehK9rYrWBHOoGTiUpZYIkdxjcSjIwnWruI2k73tTSV4g5ndbmLPxAglWCEFFq+UtaVk2cqf/wBp TvcmsLFd9HdRKuhIhIq3vREOoS9jKEZhxL+RNPVWuRLblvgDBziQpKphE2pMXSLSsJVEqFDIXeEO +TqxXqWlGBFKTyH3j56yjW5uzV1ZwyNH4Q1vbiWhG+5uRxLcscd2e82bQJeqF41oj3/ZqyAF62e+ /CWPhf4L4kLwJxDKBtBH/ttf//5HWPdMbySf/UdoDUgS0uYItAQQbWpHAj6StJa1wKgJ8J4Updj/ BmhA/BhJbkvb2Vcd6UqBjJCM7gifubLEhVGCz2ppK9rbOsmJvS1MHIukUaMYlyb0idJyd7vR50bX LWgNr27oKd7ymjcz3+3seSOT3va+Zb3udK9854sW+Nr3vuWlr373y9/+VhG/mGkvgAdM4AIb2MD+ TbCCF8zgBjv4JYl8cGEPTOEKs0rCGP6JhS+c4Q6rZMMgvouHIRxinoz4wSWeyIlXzJkU24PFMA7M LmNMY5O4+MY47kiNSZzjHldkx1HxsZCHnGMg/4PISE6yki1C3iU7+clyMTJcBizlGEMZylXOspa3 zOIre3nDXB7xl8e8ZBg/OcxoXjCZk5zmDK9ZXojnfDOR5SvnOi+mzXjWk519nGcUA7jPLd7zjQE9 lHiaWdCI9gih/ZLoRiv5nY6OtInpLGkQL1rN6bx0liv9Yk17Goly/rSoR03qUltF0KamL6drk+pW H3nVZI5uQAAAOw== --------------Boundary-00=_LMIXQ2LE2TQQENY1VA40 Content-Type: image/gif; name="imstp_usa.gif" Content-Transfer-Encoding: base64 Content-ID: <746A348E-5A5E-71BC-146F-344F07F468FC> R0lGODlh4QFQAOYAAPONqgllpNMPHQWvEqKgl5IGCNuna/y2Ae1GYc5XBf7+/vmaBPruztPn+9HQ x1xaVv/yAP7G0u5uf+cCPptADv7TAHciAf2quwUFBe7KhxfhlBtTSv/7m+r0/QCh6f/2daWJT3pW LXb/zX99df/63b+8tfLYp/HivJYGRQBzG+no44rG84KqFgLH//3SMeiBQNPtqc7I2f6sM2yo0bz0 /v/3Ms7/6fvb4w4lgcDc+qamwd7d233k/hWcfOV9BPjx9O325r3KPO/v7EyRxdCmAv///wAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH/ C05FVFNDQVBFMi4wAwEAAAAh+QQJKABFACwAAAAA4QFQAAAH/4BFgoOEhYaHiImKi4yNjo+QkZKT lJWWl5iZmpucnZ6foKGio6SlpqeoqaqrrK2ur7CxsrO0tba3uK4ru7y9vr/AwcLDxMXGwLnJysvM zZkrOdHS09TV1tfY2drb3NYBzuDh4uO4Kwrn6Onq6+zt7u/w8fLs3+T29/j5nubz/f7/AP/V00ew oMGDhPh1WMiwocOHECNKnEixokWG5wYi3Mix4zKFF0OKHEnSYkaPKC9hWMlyxA6WLQXBZLnj5UwM hW5i2DFJiIMiDx6AsimUXFCgQh/gTLSigwKIMBuuXDhVYlWrGKRmLcnw6sWnGlOKfYSBQKGXZgWN wFCiCIaihP/QKnqLSUjZUWuF6DuqVFHTpw6rXvU6kfBDr4ZHJp4IdqxjsmkHyR2EYYRbuJLvJqJ7 aXKotQT5LkX0t4Fp04i3Lj59ejXqra9Zy55Nu4Fr2o0f654bWZBnt5Y5x9WMSPggAm9XEkBeWS1L sy2PAl35QC/z5i+VYtjA87rlQWtX7nCwgbreB+WzqoX7wHL4u8h5AndbHjN56jLTcy/Pvcj1DT/x ldRoh0CjgGwr1ZagbRi0xpKDsc22YIQMTgjTaxY2WFttB4a124cywSSUZ0q1ddOIN31H2UxCISfU Wi9mtVZbStV011FrOeBAZSU0hxwBL20gxEsj2OUeBj+Bh5P/XULtOKB8guyo10sOzDjdDvHJFNwG hTBZBJFuIWmTA0QaWYSTSKXZF1MNHMjahAhquOCccjYI55s6RUhnnXpquOFsHYIoKGW9fXlTWsb5 RtwhifqHpKM/9bjDBnBVJtdRlBICmiDogZnmdipqipMOOzknhHSENDcCl5lqmeV8zRFCapKgccYZ qpwmpet0fuXgpjR3AstnDsFeeA2cdEaTrLLDBqtNoIMKuqihZu0opEyYKVpoTtk62l2pksZ62aVC GYdqjZodVYJ2D0BZBGibeourWqwGp+JbrzY37XUsXYZtrmcGhZ+AvDLlKzUrHYsBswwjzBI2CQvL LEwNEztT/8XdKJCDh9E6Nu1kaPp71rTcGpJllpK2Chy5Raj87midpouZi6J6a+q81JaqMo+lmrmv eqkWdWu7b7WbKcFrknbwNBE3HPHTCztsscJMR920xBhnvY3GHHcs1sfEraWDyMNtG7TJpaK8k5VK /dQcjkgy2aNlyLkkM5ieOleEl2jiPF1RbCO5o2VKBVeol0JkamtRQSH3E4xqdlvg0lVXDLXTVi98 deVYXz415t1Yw7XXH4LdW3k2zQSkTu7qtFza4Jb6XlqFS6ddf95RC/B11dV8Znq9+/2jkso5l5zh hty3HU+LA8xuX0gTaIiB1lDcedQWN+251Fhnj/3V1n8e+v/opJdvPiNSkkN96Oy37/7715B//vz0 A6w+5fDnr//+1MhvyAQADKAAB0jAAhrwgAHsRAgWyMD6OfAQdinV/TTGvwpa0H3+GwQAEYAAAADg AiAMoQhHSMISmjCEHuRgAhnRQEQskAEwPIEMQ/DAGhZkfRfMoQ6z4aEJIEACIIyAEIdIxCIa8YhI PCIIAYAAAC4iBDGkYSFeGEMZWlGKNsyiPQLAxS568YtgDKMYx0jGMprxjGH8XweTyMY2ulGJEnBi IqAYRQYu0ARVZIAVTWACLGrxj4C8hQ8v8MZCRkACQ0QkEj0IRzkego56zIAkJ2lFPfYxBJLsYyA3 yUlY+BD/AG2UACiJiABCIhEFo0QlEiWAACReoIlzJEEMKcnHPWYgBAYwQAb46MdO+vKXogDgKNn4 QyICAAVsVGUElGlEVibxAo6coiwtWctqzjCXu5whMLfJzU4M0o3FHOIxk5nKYRbRmUmE5SOnucd2 9lGX2bzi/CxAz3ra854W6KY+MzEBRbYxnEIcZ0A56E9lKpOJazxkK5PIygmss4ru5GUmbdnLaFlA ADe4wQkR2kR67vOjk5iAOdOpSACwEpmHRIEEJICChRoUlMf8oSrRucg4PjSi1ZykTrFZURBZIKNL 5OgEBEDUohIVgB59RAI4mIAEgBSYEzDlP1uKgpYiAKUq/02pIl8aAQ4K0as0XaVDDUFHnO40l2hF a09389MLeFCoATSqXAUwgXw2ggIrXSkC7OpTvj5VEiJ9I0FHOc5jsjSrQuSqMp0ZViOadKyEgGRO J6lWO1r2sh+yACE52kQBznWufk0EBQwgAQNcQK+hHQs9I5DavzoisOD0ZwQK21LZLrOctxUiYxe6 SnVGdpY6zUAuGTjN4hq3uC0Ui2Y/yMHODvCzoGUEXksrQ9QKggLYpQBKLBCBjLY2FmgMbxcRSN7y buKbbWTmbLFaUlVy1auGFSxkB1HWsxqAiseFoX73y98FpmS5pVQhAaEb3UVYgJVAJIEJVpoACoDA ihnALv9HfnqDCPzgu7AQr3jLy2EDnhe25DQmSo9ZVcRy9QIlXuhKnxnNIly2nsTNLzWtac39rpUg AA5wAQlcYEVYYKk/JORpEwACDhg3AyDQrkF+amEJ7EACGHZFFxfiRSpPuQNVxvKVx9vhLq9QE/2U 6ioda0xzDtPMZibiZdeM1he42c34Zac7g0vneDLgxvnI8St3zGOjRnkQPyaokBNgABJMlAQKMLSS cayAC9wAkTH48ye4tIgtW5qLVsa0ljXdxYDMgxMABKIhR23IO/JxotbEpQHeDGf+zvjUdE4rNnXK y40sF6F7fm6f/eyIQAfZBAgosnBzeQE8KhrHN2j0o53/LABJc2IDlFaEhsPraXl4M8ykzjYbQwDr Ot8yl6yO86u7PWxZmxueu8QzOXKsY137GZ/wLoCBgQxECTh42G42rRUXfQ/N/sDRERBADABQAGcX AtqSEFK0EwHGTAfA4RDfdKdHgA6KV1sdntigqLXN8SHSkbJp/TarE8Dt/c5wzQs8t8pnrW5x3FqF uY5rUet5QhIKoOCJ8DWDQSBJcLu52LLk9zi4e4EfrHQHBZBADApAAYMTAtoIb8QGNGCDhSOi4RKP eJa7OIKuU9zrCihS1wE4Ai8LEBQb/OEHa852ERbRhAAo+Z3LPdwQvJnkcochAxfA9777PeUgCLzg QaBy/0m2HBzsjqpzh9pseqIwhQIeYAdDiPND+JqDPC/3mw1gbKGH46cAEAIABPDkAsSgBAXQgdMH sQERiCDqiZi6Bl6/CGhPO4xgX8eQVMD7mjwAgL83ezDNTt5SDhGaB5R7ymVtRxnqd4F+X4Adoy/9 EAz++uY2fEESH/PGPx6u8K7nJ0H43UALIAEsyLzP8110IHi+GRY4ByiFIIASLL0AJUA9AJKac/5D WwRVB3stA3UEKICCUIC390Vdpw67VxMO+IA68gAOEHxd1gyhZkrQpAh5B3iDt4EhQH0hkH/5ZwHU J33XN3jZd3jw51bNpXhIFVRv1YL0JEscQAEFcIM4WP9wFjB+5ZcAE2AALMACurR+7HcCJPB+ocB/ gLZ6RRB/jeZkCCBwElAACFACo0cBAVBPludmoTV1ANgBBOh6AGgDZKgANvB6BfiFXHJpD5d1bmhx T9F7EAiBOlKHDnAOD9APzrBBm+VbjwRJd2ZZzxcCJEeCfReCIjiCB0B9FmB9J0h4zLd9LNhZe+ZW b8VZdWUBEMABRhZ0OZiD9DR5qeVgBZAALhAELEABPcdqb+ZoJ4BdTdVUoEBPPoAIPqCEPhYB7VdK BBcDMYACSRcDO/AAXmRPgMaFhiB7rgdtGtCMzuh6ZdgBVSeGGhB1bKh1U2ZxckgmdtiN3Zh/QXEO OmD/bXu4QR7UYmQFiP31gQkggiFwAAfQjvbXjYbodw7miCcYiTjGggEEg5y1V/SUABAwkNlFAjX4 iaAoioVAARwQeDXwACzwAKooXKz4cxRQARUwkJzoVJ1gAbW4CLfYCERnYVF4f6d3g07GAzywAjgQ AEMwBFxkTy/wXcwoe9VYgAU4e7K3cAnIRRSnAl1nh4lYh4lYlOD4ADowjvAgDgXEQuoIfQuQAERZ Au8olXeoABiADvXodxbwiIGnj/oAYIrXggFkT1ipAAIJARSADglgkDaIkDe4g3u1kJIUhNUBAxK5 ihVJAQsAj/BYARzAkZqwen8WfzdgUkIQAaaHAPhX/wJRKAAI4AEuiQMz0AErEAAzMAMxOZOxt5Mb 4AGg6QEbUHWhKZqtZ4A9qY0OQABBERRG+ZqvGXwogECH4APZhU+VUFWGkAIDkAKEwEWgYFk+wHdW uSM6QpVSmRFnqQA/5gOL2JcL4GBeCYnDxQm2iV24SQoAhlBlWU/pkJUBIJBrmQ5teYvhp4UL+QIG gIoPBgLrMpGrtpfZRQEaKZiXYFfXeZvoSQhR5oSHBABIJwGohwCnR1QW0JJgNAM0kIXIiAhT93/Q FpqnWZqj+aCFgHVbt2VF4hMlsBxCsByt+QCwGZslRl4L6QOdeFy2iWEp0KKGgEzHVAS6yZsDMABe xP8DLdA1m8CXxKmcWakAhIgOkukB5+CR2DWcz9mVXqlWO4qiMraio7BcyGdPizieQhoAHtBg6pCV CVCDkUABPrCe6UcED0ACDpBkevlmtgmYHKCRG6kJYJqi/AWlvZZsCiABAicASneD9jd6LTkEChAD LXmZCGoBnImTUFeNoNl6ztiojdoDn/mgiDqpbchFsdhgFHCcHUoAH7ocnjoCHTqiifgAJTabHnZd TmqQnPgBEICRrhqd35UCNtCivikIqORByNRENBoAKsmrLSCZwAkKfHkAFeAD5zCkRboAxnqs55AA PpAAHpkAFUCsFaCkj3hfKihdTkpPq/oBH1AD9AT/AbCahORHTxk5kNMaleqQpdH5nQoQnhnwkZCQ AOoZeAcAAjAABCUwAvDJarbZl35JrANpn5MQpwwwn976rTWgltnVaxYWcDHAQTFgg0q3AzrQkgoa AJQ5A5NqAwtBhstYjRrgAY06qbK3qNUohmQojWhoe1/UVBzwAS7gAvCIXfnnoZ76qa05AgQgquuS lEnZDteVoqu6sAPZqhjZqgvQWjRao7QqowjFRCjAm7xKAzmKo76ao5BAT0q2nwtJrG26rESqABTg l8t6DmAKrfDYqtTaiCiXrdJlZLQYs0Z7tOZZAUs7i+Y6rRm5os4Zj+RZs+kwpAmQAV4KCWDqZidQ /wMU8ABBEBRoSpGsNp/h2qqBWQkMCUNWSrZHq5bkKZKiFKCoZ4U3GANCwANchKBeNAT/x7KOKrI2 eZMbQAEqagEb0APOyKi5C3Vj1JbeSrMBW60PQAAF+KnL4bPrgpRA6w5FkLkG+QExe7R766oYeQBM W6M1WlXHJLVXVVU2iqMtkKOgGb6S+QgeCQFH2IQQYJuHcJHRq6zoMKzP6QPPmgDKagEXeQBsi5FM WLByi6LR27mde4vT2r8iaQHVi5HmaQHUGo+xGLAJMLiE9gLp+6U+8AIS8AEVwAJEsAAsAASRG59q GqYnoImuCgEE6wjOu7loS5DrkMKWhwA7UJJMF/+xkKkDQ0ADQ0CZHbDDTcGgOFmyGoC7N0m7MRuz 3loDRru0t9uMkroB14hlvjuz1ltPftm4OUu8lHK8+aepsKm8QcsOtEuDAXy0/IvArkqs1nsINAqj HFSqMDoBWFqaRAWawepj+cTAgKldmljBC0kC3iquUYldfTmtz9l3t6i2Gcm31WoIOAinsmQBNZhd Asyw2AUBCLzGnoDGxOqcA3m+bLuIAbuIEdysC+Bmfoy4L2CKHFABNAsCOZABeSm5atp0rdx3gAnD irDC7tqsVvqjzcoIFwUAS0e69heFOJDDOIADKzADqsugXZiokAptR8iJ8ynA88mM1TgIUTzFh7z/ tPVovTybxTzbxUJJonBMQM7LiW1qxouMt5zMt5pcBF80AKjUXChAAhBwAPeMAvQ8xwIgrgJAA1jr Yz5QAU0ItnxcAR/wfgz5AfDorEhKvX7Jd7dIeHpsyPwrCDdYBAUAmYwpb5aQuZK8ufR5tJsrkJls wAaWwOeKyT+mv9XrlzMdi3y3aqmMuJiqxBUwAjkABAQQwpMLmHibXcSqy4jgvCbwy+/qy+cAnmwp aRc1sQIHjKaLAM/ckjyww5tJk5AKqdXc0Olw0p4bv7a7zYJARt78zdQnzl7XdT07j+eMzlWlzp24 qp1Lva/KyQuAkXkbAOhgtQFgz6W6z1almwFA/9ABvYgCAL5aiwh6nNB73IQM7dCAfAC2ab+FPNPK ml2QiMYa3chUOIVERVBTiLl3zdScW9bAnADUmrecEM8vbcXoqteGPMq6lNOIW9TYFbM8x5r9yoUA SwF81LCPoNRLfaVjq6UKgKzNGpI+hn9Lt6cCcLpcxAM0MKSSWZmGypmHwIxgHbMszLnj3XSwp9Yx m64l6HeY7QNG6Y1ebJSkWqIC5AOR3M7ubNvVC519XQGdRgNWm6PZi1Aphtjg6wECsAACML7hq6OR rcdeisAN3b6XzdvzeeHHGwEmQACc/JfVeoM/FNI4uFIiLQn27ZboANVoOZ4qjpbUioSV0OGzzf/h HqnfFH0AF5kB0Avj0jWtFxmdFfAAZEoAI6B+bnaL2KWeeMTjFG5JOD64bGmlY2vKTN6EpkdwUCgA KMBFDb7MKECMLWCoGDZ14S3WKR6/Zx6/sPcOCSCzbL3eo9zePkAmdOgA8v2zYRy/covfSOuq87nf /L0AgC3Y4Zuj33DPV0XgNUrPOCqZPFCaoengxCrZXuoDE96+DM2qeMsBS5uzx2mEMEQArxjK1IqD HHRzRvVDp/2lRsYBEYYOXLTc4xnrbMl38BzbM520mMzhDpBdABvnmF3jH6DbSrXPDInjNPu4QYCX wX3BL3DBnGcAVT4ImctHhlzKgVsB2M6Wwwn/3T4mhUn3AwFXVDcoV9DsoCIwxBuQ3kwN2GT71E2N tgsQde7QpTS73vjO3pj9gA5o5/INtHmuAPYtyXlNvSYNj7bOd4NutXakAJcpoxNQVV3lz4s+x9cd RrT6tNROrGBKrIx7kWqZ1CjKquhqzQygex56sPtM0weAg0SVg0Wl6iXuCPbt6q9+rFjq1M2d86Zc yNNuvjMtsLtuAXT+iud5kdI67D9/CAKJ4xyA4wbAuF2Jl/yql/Tr7LpkbyrMAOl929vu2mr89c85 zz4mwwRX3edwWqKWUXja3TSp7un95OeQoy2AtnMfAHUv7xZa7zKb734fnRG9jePh70UJxmHM/5Ak iN96Xd4Ij/CD3gIhoLQhoACCXQQDAPG6WfFcpJwZgb3YawNOy58NXNsZCeMUEMi1XYNZ7KnncLAZ Kcr6+9EwL9Km3lwdfVdGJkkysLlTztzNTZ58R6ywnQkdTq1Df5VWpCM5K8ltipEavPSG0KU4buzY Bc94CdxW7+wvIElJFrcM8AF++7eXeuOXuoiG7O0+NgE/8AOl/Q5iju49AKka7OPpkPfvPvfAP++v d0CmCAgyC4OEhYaHFIQ+KjuNjg4lkZKRDyiWKBMTFCQ+HBAQFKEVowkKpgoYp4kLBwcLATQtLSGu PiEKsQFFAwEtsAHAwDQ0AbjFwwEDysvKKf9Fz88WraOfB58+PtDa0QWf3hUJDKfjpgwUFRCurBUF AgXv7gLu2u/12/famxwZGa2l5D78kVOQoNAoC/gSKoQmrUKraRUoOKBg4cRAUycscNiI7gMHHxQW ikzAAV06Cy80HqBQggCMDA8o8DPwoqaPmi8yvAAhssimDz4sCGX18OEodEePFnWIsGcRCwJuKLjg rp28q6ZQNr23QUOPDR8gOHRFYWCisuRWLei6IZPbtwlcqCsUqq7du2pbCWH0CNKkEg8oWXKrr+Q/ BefAnSqWSoGFQa0GBQsBIEQIWbJ0BeDRwgMPHpt9mSJW4tiKZM2WOdsm7YDJdK2w1cX3zlv/tU0D GSQ4lw4yvHbw4s1zqlBfv8iHFQR0fSB5QYMVthIXSQE20YgOdle0eOrECQIaS3768CHkdHwkIXA4 ILTkSpIkWDwAYWEmzvsZQJgvziDgp8djTePaa7YptcBB00ElwSk3XHDDDQAg0A5KKeGzgQhegVWD XBAMkpxaaJmSSAWsbNCDCG295VZchoRyyIuGHJDBXnw14tdfDzwwwgiDacLRYamcc5gHAXgg4gK7 +bDOMcP4EgwvnHkgD2ZEAqOAACRSAMxpqDWDDwXLoXMASKGMx8k97xCoHgXhMODmbsypE5xVBRQB HAISnvclCftUoEBkoWBjlCu7sTmIAqwc/xidniI1pE4rFJyQgHZCVVopR7YFxeg9JIkn1gIUuLAA ByQQ8AAQMdl3X04G7JfQT95YENAoRlFj262tiCVdT0IJgMAFETzIoABaJXThV+SJFdkgdj3EbF2F uMLWRYiJSohaMMLow4w01ujAjZI8oMO45CIm1mGMIZackSK6IhSYFcCCmS8pLFOklCRAIIAH/MKC iwALgDQaMl4m1FoFH21UzUOuPgOcrR2uV2gC1jj7DgLyWDVPOxJKUOem0PyUgbLMrifrrMsWwg9E u4Kcj3WsRCoppZZSoHCBDbuc3qcUgPBBBRkoABMJMIxQXwY04ZdBztvYHNYnFCma1K1Uw/+mK6O9 XiWPVBS2XMQGHYiA7CekJKAkZESlfIi0GqB4EQWCMEtXpXid7c8i3XoLbiQ6iEvuuNUpZgqRRlIw 5kDPpaD44ikEAwwzygAjQG/7+ksMmAI8AMswxAywmsHTeLLwu6GgmXEBSHWo3kbrRXYxnsINVwCe EtT+jstOZ0ArpCcJuntRzK2zqMv4OPooWpNOSvfN32hKvDYJiJWlAUDUIGMFDzhAQAksyKTqCwYs TR0DT0NgQQINQVz1N7kOj7VQN0jgzgXFWojh2Oc+ljLwaj+61okbeJs6VkERC5DrAQRI4PZKEIrk VUAFedMbjsblN3IFzgfjYFdiMHgKinn/KAU2gJwIB1CXF/DAcAsQAA+IYYx/GcNxlqDOrDzxEK9t Y3Z4SpNSirIAeOAJYxobjp1oVzuP3U5PP/lZgKrDHmwkJUBxYtnzineguaxEAd7JIgFsJjqykciG OisJqChAABe4wCEsAMEIQBCEEXhPVeJbiAXIFyvtyeqJeITU7q5GPEt1zUJhy9DTlPSYtEFkhzys oolE0IEUvQWFY7TAJS6BQAVK4luOgGAEbbQ3wFiCR5jQhFgMwMFTYOko2JhUZNylOMjVRRkUeAEC AAAACnSmF57xgOZ+MZoASAABKFBABIDZqEAVEIz08BXs6sHMeihzmVr7GDRw+MscbiqJ/16MCASC 4kehTC1ACJriPR7Tm2th8Vvg8RRSvihOTimrgSAgAhEoYAAQGIAFLDAaPfnBT6ZpwwIVKJ8F0Akt /j0kKD4YCx+nKJQK2e9+YPlGRNL2TTwWpGImapsjCTPASU6ykgssASYzuUlOdnKSE8CE4chTgVIC LI9qs4BY6gXLCL2AAiQcxAtq2S8q6aIIViJGNVEQgV+igDgN4YA/kzm7av5Qa/L4ITSjiaZmguwc yfKG4V5DHvJw4mTSqxUy+6ioudhFJXhcwFiJl56QsAl89nwAPvEJA/1YwADhi6NCZMWBp1mAADtQ gPa22E26/e4k4myoQ7cBNrEJ8lYTHf/Q+tABqlwdIKOM3GgmzkIBj1LSkiIdqSZLyslJBAalKQVT X0mUAHlILSk8dJf0FEcBALxAUbypgCwpUKXOeMAX71AcMIxqCQQYNUGuUapI6GRcp0r1uVVRZsba eY9A9VWrAwrLE/8TsN8xZ60uKyTJBsG61g1oEOBlawJCBr78bIAFBBgBB0owgtpZoGdLzUdWKbAD ApxiB98abAIfUxIogkKcZOSAUOzXNg0IsnxaTR8eR1HZXJmoB21zW1pApYC/lQukkcBkBEn7LdPy rVwdpkCyrDgg2PJQIwEChW0XAAHEvABRoQBGNxxHtgIoAwXAVEA6LnGepObXTlchYhH/l7xMq8Bu utQNWUlUXL6tQuAD/MPGycZClANHeZwjmvATQZXeKMcSryzIwAlGAAQ1SsAAtUOfU2Sl1cAm8CI7 4KJ3mTJFm1nPhhdqcIZ8sL6VGM6gbKrVhb2SWbOUxcOnAHFoRztivd2IgiX42ynoDJtaPdFZavXE WBxCAQTcNiKICQXjUDcIH7C6hz+2RG+ISkzkIiy/QVQyAIqIMag+VYhmdg+nQTGg2HDTUk5c1ne/ bDD9TZgsZWb2mfkJgh2MYALGvQCcJXDkZ/BGLPw1hQLHvcUCr9Ia3e7JWYQiZ8aGDcMO/opM17ce MtFtqwq1QA/23WANjyNEmjZFJUPs/4BGVPoHmwyMJHQwgkyjWERIeRRMPQRjhzjEyyWMpW4pQFNW JyBNg/BxMIt6iaLWGqmu8bJCcv3cXmtNqlA2M16aNTUI1KC8pGrNo9DNbDkWtlI9R+I++5kAPBng AiaA81rvSLZwU2sHCeDyOtjzvLMogIa7aqxjHWwiplcN5xJVB1P2De8TNVJFb7mEWyQt4m4hXAin imD2FF6CT3rULXd8SAEG4eIe7l3Ug7qvqWmMGCEv4KbLqEe+9v7xARC1dsCU6lGLnHJcxw6qvoY5 sMWJDZx7XnRQ3O7JILPsoJv+9D4ZugWkaoAHXYDbvDpQ0xMQWHLkGdSuUWvVQaFz3f9ro7En4nqG ALQ+6f2OEF8ke1cYnVm0u6VHE6hkwzF5qrjHHe57qX4jsoeCHNVd7SkNZSb0h6TzkX6AB1CYQ9ah +9reFlQvINECEIDTAXSDHZ+ox49NDsxJYq3yC0EnmPdy0LV5COZpYkYNUHRQo8d+0YZ6EKgnhUIR k4InF0ACSScBS6co70R7jrAb64F8HfKAxVMWCnZfLXMhjrVvXcGC5HQUEgVFIqhWZIdhXSE2zed8 KfUW0hdalYACbIZ9QmAJ1/cAjvCDQHh30Dd+rEVmfmQ4oOcK1uB7tWVqbnV4s4RT9xcw73AgsOZ4 RPY8DaFypnM6zhRVzfVkR/RlsmL/UG54FIUVMEoyhSQYgXaoJ6tHOxfweho4ZxxYDROTfoSQcr5H PIajc4jFWCKwgl/hFV+xAQDyaWrDd190YfyWUSfib9QicAk0AoJVcH4zAo3QN3sxLjuiAztghAzn YQGnA+TwFIPgDZ9HMuclHbPhba9kf/L3cXznaqnhOQwFgLTRcrCjZLVzOqd3TN1kF8txSAchhwnF Tnc4jUGXh831S+kVibLIOh2yDp9Sh9UlU0OBXlyxiMuXIRmyAZBIiXFyfpSlVpZog/CmghvgFAg0 As8gUg8ADaK4j0VwKvdghEWAj1hDNd4FGd1YZsqwd1yYAnuHDT7mOcCYWMJ4Q1K1/2QYCURrSI3/ RCbNyIDYQGjkyJEkGWWrx2vpxhAjIlHfwDPgWDzWYD4LxhUOpgHnWIPqCImRmIDwGI9kJ3xc5xQ7 og0E+Qz9CA3+uA1FuSn39VqIlHsUoScL+Q7NYA+p8TliWJHTRIDG9Wv2UJIlaG9+5ERZ8pJgeZbQ U0ApyRphllZRyYaRAUbneI6O+Ij1WClOqVYLlpPqyG9AaZPEsZT4IJjVmAgtZiAzySgT6SXAyAxY mZXo0DBBhHlfiZYGAyYhmZmEZJaW2ZmJ9XOc6XNjxZekqY7F000KUZo56Zl4CJrEw5iNKZEF005j mDPNZFWsKZqFlZu82Zu++ZvAGRycwjmcxFmcxnmcyJmcyrmczNmczvmc0Bmd1BUIACH5BAUoAEUA LAQAAwDZAUoAAAf/gEWCg4SFhoeIiYqLjI2Oj5CRkpOFK5aXmJmam5ydnp+goZuUpKWmp6ipqqus ra6vsIMrObS1tre4ubq7vL2+v7kBscPExcbHyMnKrisKzs/Q0dLT1NXW19jZ08LL3d7f4OHi483a 5ufo6ejc4+3u7/Dx8uUd9fb3+Pn6+/z9/v8A7TljJ6+gwYMIE06iF7Chw4cQAQ5USDEehosYR+zA mFEQR4w7Nn7EUGgkhh2ThDgo8uDBK5EuKxJqydLlA5KJVnRQoI/jvYv1gPITOhTDT6MR7RENyJOg zKfeMBAotHGqoBEYShTBEJNQVUVcTwmROgyrEKiGaN5UpJMnPqFE/5f2k5tvKd2Hd/s1Rct3GVmv fz2O2Np10NdEYU0dhoW170ybOBG1bUCZsl2keStXzmwZaWfNoEOLbsBZ9F7HqIkFFrR46+DEgK0i gj2IANeLBGxjGFwEK+6tF0fQZHnxwVndu4tsvIlhA0rkvK+CdLCh+NkH1Y1e7fpgsG+ytlG63lq9 MPXiHrM7r+68CPINK9VCZttAAeiLo/GTxrAZY//PoekH4H4CctRZgfyNNpp9TqXm4CofubTYTVqN JOFI0XkUoXthYeWSWVhpdVNIZNGElQMO7FZCcrYRsNEGQmw0wljeYbDSII2N5VKKkIknSIpnbeRA iMTtEJ5g5BWio/9yyV3kgEhP7kZjETzWZOVaOdV3X4IBJqjfl17yJ+CWIwEIZphmcqkgaAw+6CYr qzH5kVW0sRZnSYUJYttKexax4g4bdLXbVzQFSkhjgmAnY6IuNZchjiTpcJJ0QgxHSHIjbFCEoYId OV5yhEh6Y2OJJWYpo1fOl6V9tozZKpo5uBqrf7qMCSYtt+IKq6y9tPnmr6fE+VWKMHqUJ5OyHVIn h89N+ieohBHaaGGWjvgXTSUw94CPvZGEKLOnXqXpBq9Fx5WnTSbL4UeEGYuqAy2hJx9xbOWgwC0X 1YqBrvzii9Eu+dYS8Ej9zspRwcDc2yCwDD8i7F9VtkvVnZcee+T/kX9y6pq0mxb2raLXFmabx5FO 2m2lx1Y1qcYqTjplnJKeVbG7NS23raHzYimZvf6+2u/A+/YcMC5Dz4pwwUUf7YvCDTcdycOyYaWD xLGBZfGkGJ9E5E0rJWeijTquOJhtGoW86KKQFrFkleEmmtjWNqY42E2vqbukEIaWGlNLfXqYaiOz 3Nuz0T8HDTS/SQscdOGMNw7MLUw7LTkjUBNSnUhzYs4RtyblhrWzk35nFd3DMdcedMiiipxxh+J0 HlfXHcth1BhZ5RvdW6lLpXoo6Y2qtmvlHNkhgedysOJI/+u4z8jrOnTRxxP+eOSTV2+9MkCiVfzj 3Hfv/fe6UH/9//jkv9I2RduDr/767OMifiETxC///PTXb//9+MvPSgj891/+/6gYi8mgkr72GfCA 3HufIOKHAAQAAAAXiKAEJ0jBClrwghJ8YAP1xwj/IYJ/DAjhCUYYAgCaEIAFRKAKV6iLBk0AARKI YARmSMMa2vCGOMwhDiMIAATEbxEhEGEJCwFCEY7wiEM8oRKtF4AmOvGJUIyiFKdIxSpa8YpYlKIh XggAHXrxi2DcoQR+mIggCrF//DOBERlwRBOYIIlLjKMcq/fCC4TxjhGQAA31mMMHipGMhzAjGzNA yEIekY1vDAEh3zjHRjoSWFz8ogS6WEME2DGHKKBkJnMoAQTk8P8CPiwjCURoSDe2MQMhMIABMuBG OD7ylbCUSfwo6UUY1hAAKPDiJiOwyxt2UocXACQRR4lIUxqThKpkJQljycxmIqSOYLQlDXGpS03S 0oa/1GEoA0nMNnrzjatUJhJNaIFymvOc6LSAM9fZjgnw8YvSnCE15dnAd+5ylz104AyzycltDtOI 32zlIk/pSutZQAA3uAEG8+nDcrJzEQ59qCsmcE1t8hEAncxlHlEgAQmgwJO8tGYEcAnDTfIThxid ADeLeUw3FvKlGUhmQSVngYTykKETEIBOd6rT+EVUooWwQAR+ClRUTOCS8PwoCj6KAI1ydKN8vGcX GzhDqp4Uh2P/XGlAYarKrnp1pk2r6QUeiFP58fSsApiAOos6iJreYKhsNWpFc1hPSlITlx596gyl GtJ9evKqNkypIQRpzJd2FY2ITSxYH2QBOzLUh/NDK1rXGlcL/CACCaVsXClB0TDGc6S5JOk79yrS Xf4SsDXspEr/eQKYxtQA/SOmbGcrWw++qbEQbCBk6SfZyVZWAjuQwGVvoNllZPG4TsyfcperCmh+ sZeg3etFN8lXquLVs6slhBlbW8jDCpK2awyheMXLPzfh1pIbrF9vfctWC8QgjwpVQHGVgVzkLve+ 92tuZ597zXnicql65esFAAzSjgJTmEVIrDljC16WtvSQ5HXQ/3nRa7/1sheoB41BR+NL3G84sR5P BPGHOxBiEo84ufhNMQdT4U6kcvKG/e3vNG8pYxoqNrFdfYGOdVzEbm7VtTA1JQMWW5EJg7LCFubp fJ1pgQIAIAYCwOwFfnCBJadCU4s4sZabKGIum9jLTlSHNlYRvxji8cx4TKNLxWnMVBpgxzweL0DX 7FqvJvOlrXQMbvN5ZN4mWckYpkABNFyA4ArXjlY2xQawrIj6HlfM2WBFmV2M5krfMAR0BrKb4dzj OReWkHYOdVcNSWSETJjCflZyOlddACbroAAliEEBgCsAAAjB1oneFKMfAaNdIyKKXQ5AsIf95TCP 4BnHhnQ0Wv/BQDNb+tk2DmF3vYrKN+84AZgeLwlv7GZRe5uQpTbInjfYZ7Pu1JwYrKAACpBrhpkT ohYAAKxLUIBBl0AAQhipM3K96EU7YgMasIGvDwHsYhO7xE4cgcKPvXAFzEjh8RuBiuf3CgbCEILp zvgEbXhBAGR7yK/17rXTON7+LeDkKE85/wwAgpa7HATfRiVaTn3U3eZUAOi+aVnp50AJsvt6FtDx ks0ZAArUugQImDWUERDcKf+g3RsQgQj8rQiAa2Dqi1i0o6XYcGnESAVgD8kD4jf2icdi4su1JA2D ib+Pr9zOaBwheUOQ8gWgse52D8HL9x5qcEOF5uXGeWN1rlv/n666nFyMYLvNK/S2Et2J2yI0CmIg 69z+QAGIznrUBU51QfT78/02BOi3DkWFR+PrIUm96lH0AHiZPSGTnmEwFfHxIady77XnH95DUILe l8ACeLf73l/e93DHA/CQHTxZNbjBco6SA4Kut/TZbYHEL14eRBVE9h3/gnM2cQhDCAAOVsADHgS3 3rGu99Ivm3lGAFwENujA56UOfxvYXwE2mDro4S//ImxZ2AYXgMnGE2G3equHIgjoAM7wAOZAEQzk WP4USN+VWHOHbcCHcrzne71nAQeAdxagd8MHc3D3d2OVXkc2VsunWw1lAR/AARxATNE3ffVWTj13 fe5QTj6A/wg+sH1FEHQW0EQzMAMBoBMzgAPh5wEIoFMI0HsFwHQFEAFCMEk3IF+NYHVSt2gakIVa KHX31wECR38aQHX/d3AfNoCod4AJmIa91xLOoAOR5oAM9EAINljfJWe6lwC+FwIHcAB4GGtpeIEp RwEgAILDN4JPcV7yo3OPhQDmBAGO6IIvSALQJ4PTZwE1SBEWkIOLsIOGEHTdFwA0IIRRhAMHJQCx lnQlIAGFhlFQSIVVCHBWF4agB3pXZ3W7RnpNlGwFmIYJqIG+uIYPoANueA1PYT8dVIe6twAJgIC9 p4fLqIAKgAHPAIgpZwEh2HKGKBOICEqFJz/n5IgL4IiO2P+CkTiJlDiDL2SD4aCOPdiJnyh+Qyh+ MaAA4YcDtRYD9DZoEiAAUCZcCtBh/2aLG+ABBOkBGyBwBWmQUdd5goCLuph6zPiLEvmLZYcC+XMI PkABGplOpLBUhpACA5AChNBEr4BYPnByz5giKFICIbCMAxGN+5YAPtCBC9CBgniNIqhKxvcIGbmR 6MQK55VP3mhOFVABHcgBEFAB4QiOJxeJO3h475YQa9WTGkkB59SJQSV0Q4ADARCEXBmK4qcDIaGK FBADDQRlUAhXvCaL+leQC5mQBwmLhVBwCHdiD7mSE5mXGvgAAKZchUABPhCJtJWRiZYChmkIoYUC ReCRIDn/AAPwRDzQAguzChSAcgnwktKoAC35DB4QAB6wbz15kjRpjdd4WKoAmM43W+VklYSAAtOn mIWwVK9JCLjFdueEkkVplAuAlEoJjrq5mycAfQ4CmIIpZ4QJUd1Hj6PYRDwQI/UGAPSWiqsoAUs2 i/0WhgQZdVq4ndvZAwMJi9YZngCIcDOiEg6ggbmRngSgl77Il32ZX4JAnM/ngh9QTjVQA+DImoeQ AjZgmCIpCJn0QLnkQ40ZAOVnoC3QmST5CpV5ABXgA87QmZ8pXwsAoRHqDDKZAJmYAEZZlKQZgrC1 k4yAmpkIiR9wovf5lFbpmvoUARegirC5mBZgZi/qmm2l/3jltIcLoJQLAJXhuKO6CQG7SQKa2Bfy WZUUcKIfcJ8QgKSJ4Ik/2AErYIQdUIRDQANDoANJiAAxIGhLtwOMGJ7x54X5N3VhqAEesJ3haXXZ GYb0Z39eqH9ad0UjgJctcad4eqcKt556GYzCOIzSEJ+CSZ/46YjlVAGOqJRL1piO6Z+LmU89hAIg aaA0IJmRiaCSmQqrqX2HipQWOqEUsIcHYKHOAJgauodJ6aAV8IHcdpockImSyAFLKo60uoMLMGun x0uKuVSYJXsa1Go9eKhGOaqAeXIUAA3SGAAKoIy5eZRKaQLCyRcUEInH+gwUQKvViqGIUE7v2EQ4 MANTiv8DWGqPXEpv0DloAIBznhd1ccqdZxqLsrgB4LWDG9ADWqid99pvV5QA/JoASNp701hOz/AA ucGe2eKnwjgNllUE0/p8LfgBtAqOFpCbRrmojumYS4VLkdpUS/WYkdkCkkmQINuZqJCJEEACFNCD EJCREFuh1lqTNOkDPsCvFWoBFGCUqeqhxDCtFhCrshqxQDtrU/gMCZVQAFa0LvpAHZV0wVqUe6ih ykiTlxmhnpkAPXp4GYCysKCRPekKDcsA2Wqtjhi22noIPuitQ8AD8OhEOIAAzjl5AlCW6mo5tHiv GmCvsoiyGimrKFqoGlmvWQieGzCGX8avsuoCLiCqq8r/gPumANlKsHx6nn36p4DauI5LTPSJrVWp qE5bsfuJsSPVQADGqwAwAZ6ZkDpFkAtKCQ7FgRUgnBZwskkqpMqokTU5rHW3g6eKqB26qoYgfalA ASTQsxyQchFblCjHiEW7vEV7AQXgdC46Vp0EQxagmBNrlDO5h6FqmZyZANr7DMmqAAmQtSnbChop qtrLCl8btpkpvtnavuJrtkKnAEKouh5AA2proEKwboSGjz9XddfpnYs2StMKsUArjkqJhWE4CITb RAlAAieauOi7h6vqDBlJqgTrexFJkaO7VN4YP18LidgKDTfbgQ56wpQFRQOQSbqFAiQAAQfAworZ RAQp/wBCKgD4m6mTkIkV0IMOCrsV8AGhyocye7vNqqM1C3OuO6w6WwT15sQC0EBPXAohfAAkcHKo mqgviMVPxbzMa2uyJ70q2FQ96LSquqonaZn9ir5TK6EJ8GZaewpIer4TTKyuKkLvqwDK6r7OEL4Y Ol/cagGSyZc4wJUg20QoEMXn92T/W4Xe6Z0EDLEnjLMI3KwWIJcNaUUP/AGIewC3icWWtawJIAML GLm9OJHu6cE+tQATEMI/K45k67g02YHIq057rACVGgArPLowzFQeCYo8YMMdKAAfq8OR4Lo+/Lop O7FCTKxWa8S4S5UieL1M7LtNqIpKCEOqSApVvMW3q/+qEODNB+BklLZDKDi9LwRDrXa9FFyUVkmT KTfByhihVqtjcWwK0+qIPgABJ3oAMGzG5YvPkehG2SqhGFqtBo2hnJiVP3hW9cZTUKiKEgBl7IiF kDy7DkoCqurPSfmCG33JjKbJEJy41UiNnuwMpKwAGeyHaojKoxs/PgDTz1eV4ji10lCZNXlyRRlm NFCpkomx+URgv/yxHiAACyAAInvIO+ygyQzEzayUcxzVBRsBJkAA7NzOTXbNSTd9HQWskuADz4eo 4ty54XzFNUnOGqe06PxCXV3Gw6qqFnCq8Iy+TquMNLsAbxatkBDVgCmqLFixHFCxFeuklCC8iHQA YTv/oXx8oc9gtQHdVkInABKQUC7aUU6nAOsGAGDKjptyt/L6sz+s0UWZlGIt2oh6AJ1nDZsswcEX z3mqwU8CkXi5l9nyp9HQsBxg09cKATYNk/uGxSinrLkMspIpDCzcVEHtmP4XmZ3JAwlZkJMJUUzt usLpA0J8okm5mz2qnit5AuJFACdwrW9dlNLXQOvGU9rs1Y+A2xlQ2lhM1uLsZMs338u3tOnF1gaw zmYM1w5g1T5AsWf8mzl9AKt0zyOqkVlLW+f0AYAt2Dt4SFUZCQ3rRsPa2xjqoBYuvie50NwXytSQ hPj2A2oVCdrpnaBd2uDM0R492kZJdaotqwLe2jCL/74y6wOxjYYUSbmVC9a5fdu8/QzKmpk4zaPC XalopAArYNwTwKtkrNyny5xS5J+O2gih+qAzWQE1oJGIWsAI7ILC63W5QcAwrLjj/NDrJn07ld6R wOOE5N5G7KBljcXy3VF0Xud03o0WJwH57daKu6ooQgBVicV1PMEZYMWPjQhVmQEK4GPfVGUvvIOB 7cnlREEuFeFUzgAw/ta97b0nvOmzDMjJidkOXQACMGU3MLeQAHAmDrEdWtYpHs4rzruovcCqzcnw LOO47gOqJ9sSibAJ67gfEAG9LeQ2ndDbq6PC3QIhkN0hgMuZOgCLueSK6eRN9JIDcbEXawON6ghL zP/Rudmk2J2oyqye6ukMYHvaMAsBpD596yYI5a1bUzyiL0hIMvC6Hg2zHeqCGn1yBaBK0zvGY8xz MGQA23zVFGwB4K0A/Q3oVnl4FCCTLsDgh24IFJDgJOBGEhRqQrfPO/jonghnOxZOGaCRi9CwH0CY Mvu0/QrgfLjGO7qHHK59kd2EAGBTQ6sA+8jZmyICPeCdrE7Brj7a/qzv4KybC4k/CcABJI3ruD7E CVCAEOnS70kBEWAANh3kjuuyjP3M/nqSoAiyelihzZ7LRfCYkkkDUNTTwl3kuoztF/ufjcCB4AzD +uwDBXC8D1wN5w7D773uD03q7T4IMrjekkhI2hv/1R0a1R9F8P+ugvajWx1lAGTsunRNASdAAM9w AryYGy0HfEKaARyQkYpQ8aNkAhcA8qj/AjJrTk+ZiTUus6gv8hNPCMJ78uY043TN4hT71ijsjgd1 85QNSoI3Caq+AazOxEF/2rBu2jkLi0jPyUzf9DCr67u+A5JL29miyq1c9aRq0ENMquIL3KvpA04U Ah4XAsSdqQjqAQd6qc6A9iUg3En+9m8PCXKPqI4oqjJL0+IICAcUDAqFhgwJFBUQBwsLBwUFApKR ApOWBUWam5ydnpqDHBkVC4ocFY2PFIIVp6mQBgYSCLQTtre4tBK7spmgjI0HFRQnCgQEhsmGJxQQ /xCoHx8Un5sUGSQnGQYv3N3e3+DdPuPk4Bnn09SDPgfOFguoB/KoFYvO98/1jfUWnhbcFhTcsERQ gIV+1BJq2iBCQ48NH2q4kCcMAgcSwhYd4MARY71njTb0ELEBF64ELmQ4WsmSgsuXMF1SlCdExY6b Nx04KMGz54MHI0agQGGLgoyjPgx5UCCA4oJxCRKwXGABpI8ACmhobRGga4ABAXi08GCphVkPXpmS otB1RdcBcAekUPiJAruKB3y8dPaBhA98HCgkYEAY0ap4jipdmlSEEi1fdDfpTQeKhCjE5Mg5zTwO RYFYu2qZnEALAa9YFlBssiAsVT1ihY7Jlg2idv+zjxB8ICwSNaY1EudixQpH3BtnH8QNoEs46MM9 C+z0zcOND5+8Z7s5/bNwQZKEGwezR/bE8GE0qy5beRwmqGNGl48qbNCwQZkhlKlawp/K/5G8DDXZ hJNOPfmkw4EIKkDBB0c9ZYgA/snTXyNV6RMADWaZFUAKcQXgAVkkQCDAh2jRkBWEehWiFQ1fyTWe P9P5wJEzMylyzwIcHJCIYO04FQkCmBCUiSQIFCABZJENckB2zWUAEn/TSTgVChZIIMssCJiky2kS pNZJM1K+Vox9ypyQwEfDbJLALmzuYo0owQm3TXF0hiPcOeiEJxgnFHDgnDMUvFPPoPZUV911FYj/ p8k/L4R30IsKbdCBCOY5U0ECrE0GE0W+scPOAvORRCZKU+3XH5R5ARiggDkVyJMODyCIoFENLpCA JfFJx5KEKfTqawpevRUXXF0JwMgCI16YVQB2CfDAhSt+NRek2s1j3ZIwFbDIIgtYxFGOEv5Iy2KM NbblkUgy98GSfPo5CmIzEQrvTJ5RcKVopJlmZSxFqtYJa4h1O0wCY5LJDJq6gdLmlW5akwGc2sgp 8cQUS4znxRS0uUsC1TDwJwQWYJpRoYbiEw921GxHbWQMOQSRMz5Q9dRUM/UXc0gj1WcfBS60dCrN jsiTgA+rstpqgbHCKqsO9hqg0q4jSyelBRyk/2DDsFjH9dILPKyCLA8sLnvissEOtTKf0XEADLvm PqbtoDM1Uklp5JbbdpuRZBITn4wwSUI0UscrbzzzUEQlm7VsCZoF6WoHT34gCXbC5JSb2Wc+VFWz ywUnYHPDDSZcgEBMD19s+umop57BS1ZewPkFsnBchAUeP+cAAdANLq88ipycaMoAnU2NpA1VCpIg MQcdt5SOSPUIqCN1UJJJRq1EQUuOOvpSVGeqULTRO7n6wFBCETWBvR8YsPzgUmKqdgW9Yv0SXBS8 gAAAAFAwVgBj8eDBsxfCyrJmgQIFRAAB/hIedGQUqEdpgkjjypsE8yaA0gBJEkLqRAF0UZpMQP/n b9F4yTj6xicQWkp3HyiUvI53AM/oqzSn6Rdd3nEsR9xDRztySQI2gjkm8eJ1rnOdLEb3gA345ohI TCLrABDEz5HgBhtbVAU+ZgGdEOAlEVqebnzgO0WtJjzCI48IivcyS/FOeVEjXCOu9ziRaIAko/Fa KRzRwKGg4AGz6YlOcOK97+WEQK6yI1GIsgrAUaQAjiBUuBD5Pn1wiH4AQMALKDAANr4gfx/i31kC oImuDJAWKIgAAcM4O2EERoOTMI0FgVSQClqwbnbbxAR9UZV8TBFmeiEhKKb4MVtOUQHxINkJKVKP AqBAY7HwzIsEhQobOuNb0LRl5viksWrS4gX/QWABCzYAghFswAC12QABugmCDYygNkXsJjfPyc1t boAFMADBuVp3pXRAx0/uIMAOFHC7K2ZPe1LT5Seo9gHZkbIIxOuByz4Gt0D5Z3fy0EswGOFGEUiP eqlwSWoEeUfZ6HGPfPTjH5FWAkHaAgV28VMzMeU8p5RiI2rLB0V6RQEAvAAew9iW/SiAFv59iCuR 6FVXCDgUVSbwbAA7JScwuMHQrPKpk4AgJiD1Ty5qBEzscomMenmPb71iUDWQKTGXdDhedOmokXmH wBpxD7hNxxGKooAqn1qaBCDAANl0ABBGAAQgwGAEROjrMWDwExhkYAQEgAEB+AqDv2ZAmyPg/8AI 5PpUNlFmQX+iwA6QUYgd6KSfx3jHKdQIAcoMtB1KDWPLGrJQrjqjFKtYniDORBEIiEShY9SZIeRI gaUhCI/H4AlI+yjSAYWPJw941YEMwbTzkEIqDdQeD4e5j3bU9KYQUNALFADbrhQAAsGyVAHgggIE KoARdjxoUk3bGILMU2MRxOC4pkpKG7Wnb30axnkMxREF5OUuEPVPaTVBJeF4aWUWuJ5b4zaoUnix CHLlnl0RIOFbISAID8gBYYFwWBYcIMNAIAALAPuAv5bAv930K1+1yQIQwIACFeTeKncDnXto1hic VcYO+jTaeLFtoAe5XmrPtloNuOwvJbPIU/80GuTDBFM+PVBo9HRbiOtRQAG+PRBwCSDcm3yvuIAs gZbFnKBC1PgZzvQWNGMq1ocKQpLwuPJLfqUtR/igzgsY7wDseKxQIpCU60Wle/UlAQAgrpWuZGXj 6HLEeMiob644c8k4kqg+KS9grdkNSg1gtjAeJFe7czCjo/vPBFMgm0U8wAbeWQ8igIADRAgPC8KT AQUAgQirBsIDtHkCEJQABJR9Kntt9Iwb43g2x8jvvAacMtQqqFvsfVFCjeyyWiZ5zW0lrQWijNs3 UvnZV86yAoDbZS9/+Qd+TG5PdDACMi93t8JM8gkJ9zhmb61+FZjkI+ucgEiQIs97NqAE7Cj/yj97 2pTRxqAl6IroV8ZyPKGAZlhphGSY6CXeXW0FB7iLRuUxW5YUWDSCSw3Gg0JYFCzIJggykMIKuKAG YV3SX3QTIt08LIUgAOc7s3GOwPwz2rmzlLHJtAPafvXH/oiQqT8u7UlRitoiCbq8IRqmJXHbyFOm HgUmwFFbbLncRUO3EB6Qbgeou6QoKJ8dbyH1qStSQoVLMJyze2UILGCScclbiBDZ7z2LkoAWRCu1 Ao1KhSO6IKuk7+B9SZ1nqJnSbTeUxhWQPCnF3ROCN7nm65KAcwQhCLWRiJ9qUIHa0C43VENFeCrg auXkXDnnAPYy4SH0BOxTx7H96jQT8o6D/1hEQQ9OSEJZO5+HCMrtUlsJKbYd5fk4ZIwXvcXWTzqU WwC33XskO9nHLvbta/8mD3DAHZNrUq6bzxbMlPzbXSqMzF2Xji/49+jg8t0KfBcCeSNvwREoSPUi 3BNMdXiD5nAiN0N3wWC+ZFX6kH7VoRFPUXkr0X7Bt3kUyByCMScvkAC1YXrhkUJLEmkVoBsg8AIW kwgIhlORY3s4kQg5onx2N4Gr0SPywBrRFiljJGUP4RDGJzDUsWD5wS3MF2X08UZZNxrmd37XVwI6 MT5p5z3bNxTbpwIPgBNMmHZdx3UmkX7sszxB84KgEEmTBGF3dz+UVH9PEQnwAHB7ll4USP94SyUk EjRoToUJBZhW2aOAM3GAFKGF81YPE+KFFRiI1CJC3JAZe+iBqbckqgcOL6FAKEgjO7JDHBCBQDh7 cFUVCUYtDPF0zaeDq8ZM68cffmgBtyWEbjQSokImWKYDhXB9/LSEBzICNwErNRGLI6ADOzCF7LY0 q8iKZDI7OKVGXJgruwdhLlEN8zMAeNZviXRncPFI07J5bvhAdAUk70WHgshFcaMbVQWKPpgfxAiD gjiOnpBDLxFTfxENPSIdvmFQnvaIj2d38YFm4qgdvidQ0pZb1JaDD/GJiUQPlmctcFWKCuVG9JFb 44FHI6AJSvgAmyCLDlkEZOcJU1gEC4n/VP84jIkkj/WoCfRnZwWQAog0DnrGIdEojf+3VBZUTYeW N21IddxYg4uSkS5FiRxJjjgZRr4hW3pBjglGeyfUVmgWKBg5g0QGdfvIbau2AZ+mO4RCFavGbVJp ZM5HH+MRFJxwkZoAkZsQkZ2glQqkYE7ZYERJLfQXCc/oks/oIhU4jYYHQ3QTVXWoQHqoJ+Pxk2NJ lh2Zk3xpgXEjk20oloMjap7mQEdJldSmg/24AbPTlE8JRksZlQqFmFT5ImD5CZeJkz+ZRs1kmCvD ls9YBC4yLCepeW4pgHQ4l+pll0h1PZxJIXvZl7KpDnZxjLJJcp45m+QRmbzJmP7wT8LXIZurppuC iJux6QmhmZxyERelaZopKUuz5JLEuZokJ4iBAAA7 --------------Boundary-00=_LMIXQ2LE2TQQENY1VA40-- From uponxsnt@christiaanhelmig.com Mon Jan 15 18:46:40 2007 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6bXE-0006nC-8p for ips-archive@lists.ietf.org; Mon, 15 Jan 2007 18:46:40 -0500 Received: from [201.29.255.43] (helo=20129255043.user.veloxzone.com.br) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6bUy-00088t-RI for ips-archive@lists.ietf.org; Mon, 15 Jan 2007 18:46:40 -0500 Received: from uponxsnt@christiaanhelmig.com (saulomoura [188.140.166.52]) Mon, 15 Jan 2007 20:44:29 -0200 MIME-Version: 1.0 Message-Id: Date: Mon, 15 Jan 2007 20:44:09 -0200 (GMT) Content-Type: Multipart/related; type="multipart/alternative"; boundary="------------Boundary-00=_LTLX6OVK850HN0X1VA40" X-Mailer: IncrediMail (5252670) From: "uponxsnt@christiaanhelmig.com" X-FID: B433CDFE-B71C-42C2-A5C1-D34C076A9851 X-Priority: 3 To: Subject: share X-Spam-Score: 1.2 (+) X-Scan-Signature: 28adfdfeb3b69a8c1fb469b1c327fd44 --------------Boundary-00=_LTLX6OVK850HN0X1VA40 Content-Type: Multipart/Alternative; boundary="------------Boundary-00=_LTLXW93K850HN0X1VA40" --------------Boundary-00=_LTLXW93K850HN0X1VA40 Content-Type: Text/Plain; charset="windows-1251" Content-Transfer-Encoding: quoted-printable Wouldnt throughall, thank very anything youve, done, help although.=0D Sept oct completely official but.=0D Hoursjuly fan posted scan painting hersister rachel.=0D Throughall thank very anything youve.=0D Kiss, star gene simmons, and look on.=0D Please, did theworld naturals marc terenzi admitted dating.=0D Places youd, never think, wed case, anyonesees.=0D Kearns commented shes bit talent several.=0D Three well spy las deluxe wherethey cuddled hoursjuly.=0D Wouldnt throughall, thank very anything youve, done, help although.=0D =20 --------------Boundary-00=_LTLXW93K850HN0X1VA40 Content-Type: Text/HTML; charset="windows-1251" Content-Transfer-Encoding: quoted-printable
Wouldnt throughall, thank very anything youve, done, help although.
Sept oct completely official but.
Hoursjuly fan posted scan painting hersister rachel.
Throughall thank very anything youve.
Kiss, star gene simmons, and look on.
Please, did theworld naturals marc terenzi admitted dating.
Places youd, never think, wed case, anyonesees.
Kearns commented shes bit talent several.
Three well spy las deluxe wherethey cuddled hoursjuly.
Wouldnt throughall, thank very anything youve, done, help although.
 
3D"FREE<= /HTML> --------------Boundary-00=_LTLXW93K850HN0X1VA40-- --------------Boundary-00=_LTLX6OVK850HN0X1VA40 Content-Type: image/jpeg; name="908-DF5F73A.jpg" Content-Transfer-Encoding: base64 Content-ID: <35BFCE42-262C-9A7D-B471-CB7CCA5B24E1> /9j/4AAQSkZJRgABAgAAZABkAAD/7AARRHVja3kAAQAEAAAAUAAA/+4AJkFkb2JlAGTAAAAAAQMA FQQDBgoNAAAMRAAAErgAABxuAAApE//bAIQAAgICAgICAgICAgMCAgIDBAMCAgMEBQQEBAQEBQYF BQUFBQUGBgcHCAcHBgkJCgoJCQwMDAwMDAwMDAwMDAwMDAEDAwMFBAUJBgYJDQsJCw0PDg4ODg8P DAwMDAwPDwwMDAwMDA8MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwM/8IAEQgBZAD7AwERAAIR AQMRAf/EAO8AAQACAgMBAQAAAAAAAAAAAAAFBgcIAwQJAgEBAQACAwEAAAAAAAAAAAAAAAACBAED BQYQAAEDAwMDAwQDAAMAAAAAAAEAAgMRBAVAEgYQIRMgIhQwMTIHYJAWIyQVEQABAgMDCAQIDQEJ AQAAAAABAgMAEQQhMRJAQVFhIjITBRBxgUIgocHRYiMUBjDwkbHhUnKCwjNDUyQVYJDxorJjc4OE JRIAAQMEAgIDAAAAAAAAAAAAEUABIQAgUGAQYTCQcIECEwEAAgEDAgUEAwEBAQAAAAABABEhMUFR QGEQcYGRofCxwdEgMOHxYJD/2gAMAwEAAhEDEQAAAd/gAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAD8OrGXBGUls1gAAAAAAAAAAAAcWM9OE+jCfXjL5LTZrAAAAAAAA AAAACC07ePEvrKN1TxPxevSKl/cD2HjwAAAAAAAAAAAOhCVVq2ZLbCM17KrUsVKna165fc9Fvb+F AAAAAAAAAAAAp9WxwYmwqVS1RqV2oVbGMtdn0Z9l4wAAAAAAAAAAAdSOaVTtSOzEHp20ShexhQ6N F076TLPqL7LxIAAAAAAAAAAAqVWxw4n1oZxhyOrTdFnGui3jjXtpF+PsL6jw4AAAAAAAAAAHRhKo 1LXanGH0bsZ83o67cru12UMeWcU3r6fbbr+LAAAAAAAAAAAx5Qu9ycetGVap2arUtamc/u0uaAva ZrZo9e/QePAAAAAAAAAAERq2Y3oXZfbrhtO+pU7lZp2tcF6lXcbo7+HluVbJnX5oAAAAAAAAAAx1 St8GJfOM1CjbqtS7TqlyuW9W1/W4U5t09zfqsm7UAAAAAAAAAAMa0bfS17YDRvpXPv1uta590dl/ Q+a/M4q2ndBatueOrzAAAAAAAAAAODGcW827ijk9itabUPp3werfsT3fNS+7RXNW6GhOPjLbX0PC AAAAAAAAAArejbrj5n0WKavW6Ms9PXOBjnNdviWuzVgY74iOzqs70+r8sAAAAAAAAABivl39VfO+ rjtueFiI1yxZar2bZX2P01YmO6Hxv5pQ3y9d5MAAAAAAAAADF/Nu658X0EJjbXU8KWquIe/5vIGp tX5z0d521e7LV9Txtf6LigAAAAAAAAARWqet/H7OCef2Nfb9TEnc839ZhwmQa1ndrh9aRrWOprlu 37PygAAAAAAAAAA6cc+dFO/p7bqRMoj9w/MputfvNXoWvTv9fO15YAAAAAAAAADomlsc6fs4ly+W e7DPElI6Op3dV3sw3yEc+3vV8gAAAAAAAAAKPhrPjGnTOGMy5sZltUrlps5j4/WokLsJts/LPNKP s76HwwAAAAAAAAGAqe7C046U2IY/ZkIZnoz3mnHM3Pu6jcfsVnXu6eu3x5zzZj61+x8MAAAAAAAA ImOcHVdnntrsUexpr04ZQzj06nDL+URCWiXnu9Tqt+Nhc4cZ+8x9SvY+FAAAAAAAAxjpnG15afat molyGxNDd2+nV9L5xmQDXnmXdZuB6vi2z68XVi9NvY+EAAAAAAAGEaO7HNbZg+WdXL+neWcNkNOc lWYdgAFS1T1G8x6yKbofVOIxL0q9l4UAAAAAAfhrfV26mapWLfDOe2Gx0sWHIAAD8MA8brYv53Up 2i5fujztwvQeaAAAAAAEdHPKx3JAAAAAB+EXrmJXZAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD// 2gAIAQEAAQUC/o+MrQvK7WOe1qMxTnrysC8zNXJdVcFUKR4WXfNat/0Y26m5k8cEFGjcppgFNcFX U++PZHqr6QvlaKJ76CeRTXCmn2rd31E8vhijaSSKKZ9FdvV3c1E9zVfIGpvX75GiglJIu710ckt6 Cr6fvLc0XydRPMIWMCP2lNFmYvPA68eDPcblczUW726e4m89wOwe9TTKeUPWa/698+fsLee9P+dy OzTX0/x7W27pzi0SSqaYqV65Z7ZsVh8pnp8HwzD8fj/9Jmnz8tFbx+yalJpNpmkqppqFvHH8nu7L Gx2ds20toz5W6fKs33puGtE141T3O5Sze3H4a5zUlrbW1jBLdsap740+adNI8RMv5QIri/7vvO8l zUSXAXGZw3ES37ipLpPmqvNpsnI1kOSy/wAtPuHE+UhOkKmmXH8iG2108te6dPmct3bS8reWWTwV 4qox0EtGjJ5KOAcUyIube0uhcNuWOgcXVW11NLylm6ykionUCuLkMGXzQjUcdxkbiLN2WIVlLBfQ xS9hj7N4+N20t5aMvYMnjJ7V19MYFls06rnFx3v2LA8husJLj8laZG2lhZKvg29NNNDDOz9gclwb X3NtLbn0R3E7YLbkebtx/r81t0tzc29nBmM9lOcsvMhi8OiSSvHtaxkkrhbFqESEa2e3SZzkON4/ b5jy5WPk/L582UyN8jv+K2WI47kM3JLjsdjI7mxFfi0Xxl4Pbo+XcukwM8eTwGKsuQckyPIrlRQb 1bRXF7LxD9TRQnkWLjt5r+PtAfJG+Lv414/bor2+tMdb5Hj1ryqZ8+NsM9mcNcYmdkbGjjvFsxyy 54vwzFcYgV9atvbbIY9xu7m2jgkMa8a8fbQ8g5VjuPsk8Fo3l/Obm/TrhYaJ2e4Pwn9d3fIZLDH2 eMtuuZsPFnDHU+NOjWw00Ga5hZWb8VkuN4pc05deZCO2sMhl5+Jfqdts/G8QwuJEUUcMfoy9t5YL yy8F4YFM3aqGn1+S56/vraTHcvvzj/1nySdY79XWLG2GKx+LZ9DkGILJp4C1Otp55P8AG5Lx/Wur aO8gggito/qzWVpcKCxtLb+Bf//aAAgBAgABBQL+j6qrra9Kqur3dSpqtXyNU77N6Epzk4qmqf1c USjqiaIdCU5OOreehT5KHeigtuoJp1KlFVXoxupJqUU4olbUGoHavLp3Ggb0JRKcmINRa1q8w08p TUUSnFVUIW0oRgKunlW5Fyc5VTIi9NaGrci9b9PK7sZFuVelu7271u6V00hoJJd3pjdQlVVdPdfi AqKioo4tyuIqFpqvtqLn8adY4tya2ikZvBaqrYFTTObuD46dIod3okj3I9iRVeMaeiMTT6i0VdE0 rwjWE0W9blVV1X3TpA1PdVB9F5FvW7SSSEJr93UnpRSs7u9FdGTRfdO7hj9yqgOpFU9vc6Vz6dO7 1RP9rvTI33DSSSUTChVxCovH6nhFtCjoS6qEa2qn0p4+7gqVXxj9ciqAp9YtBQaB/Av/2gAIAQMA AQUC/o+oqa2ioqKmr29QoKOXxdUEegCAQC3HVN6gIBU1Q6hNTQqapvQJkdVsTUdSBXqFCdpI611A FB0AQamHsiqjTtFSegCAQUakkDU6Vz149PEiggE0IBPk2IvRedQxbUGJrUApJhGnOLlRBq26dgTY 0GINQCuvzDVt6U0zVHDtVFTrOyqatqpp7f8AKqqqqqfJtUcm4PZtTDXUQfkHdZJQxPkLlE8sIcix eRwW7TA0UclU3upptiJr1ZJtQNUHUXkOobI4KtfSz8W11Na+gNLk2CiDFtVNW2IlMFE3TtbVObT0 7lE/s1fYjThObT0g0THdo++lAr0+yqm+prvaNI1qK+yqqqvqCjfVtUNCAi5V+nBJRNctwC+UNcHE IuJ/gX//2gAIAQICBj8C9PxbfQ9n1r5/Xw8F44moVF7RgDnpUQ2ANd3hOf1ybilDUXqfEEceU7J/ /9oACAEDAgY/AvT8H30tsU1C+V3dF8+cCWXTR4ipVd4ULoXzUaAaLpo5Fw0EbJ//2gAIAQEBBj8C /uPrNqLhllp7IsEo2lRvRvZWUNZt5fgGpYUSlP5jfmje/Tn48qcULDKSeswOi+UaoUg6LIlm9pl2 Xy+XKksjdRarr6TbCgb4tuj/ANWLxZSpei4a4KlWqVaT0mUSnhKM0GL/ANXKUtg2N39fRYqRjhPW K7h0wbdYjEL88K0xOf6k8on3juCMSjMm09KszibW164OKxSbFQbbM8Kj7v4soVLdTsp6D0EGHEi5 VsSnDnClJO8TE+AqXA4u6dzHLF1ZO67nAkjrNkCL4InGkRZDCx3gRHs3LacvEfnPGxpsemqEvV7o 5jW7xKrGkq9FGftjcPyd3zZPRsfuLKyNSP8AGJwR4DWNZY5fRKnWPi8z7iNZ8UN0XLqdPL6Ju5IF p16z1xiKeK59dVsXjRk7S1HYbbw9pMz5IIFgEWGcG2CZwcC+BStmT9Qf9KdcN09MjC20JJHli+eq L8Ii/JlOKuSIStxUlOKJiQNueDJXZ0XwjSpxaj2mCm7SIst1xaY+nJk4zJueJzqTbClAYUixtMds TicXxSIJkhxGCfpAmCrMrosMb2by5MJd6Y+bpvgzgi9WiHadbk3WVlQHor+mPZ35cYWBR70W7puM aYu7vlyZH2vN0m2Chs4nDGEETNrjizJCE51KOYQ1S8qYD7QWFcx5i4n1tRLM2DuIGbOc+iG6hhQc bcGJKx8bxGCqQXUfuC8dYzxxKZ5LnoTjdTov15MphyydytEFtYnnQsXEQoGyFNNHazmCpRmTBbxS QTNSdPX0bPrqRw+upifGnQYYqadVlQnEhBsVYcJs1ERaB8eqNz4zycofQFozzhXK+QN+1VQVJ7mA OJKfQb0nXEqnYqFWlg76ft6Oq/wUshakhLnEQRenqgBNctxIzOyX4zbH5jW5P8v0smdqqp5NPTsJ xPPLMkpGuKqm5O//AET3VZChU84dElVOG8JExJGnx6IVSe7/APJq7qj3hcG3rFOnuD0r4JJmTeeg LcsnuJzmJISVHVG1f0/c/FkqXa5wl104aShaGN99f1W0C0wrm/vq+OX8opjxKX3dSvYToNQofmLP 1RHsdGn2DkzOyxRo2cQF2OXzdGFAmYzPP/5RHFXNil71QoX6kDPHsrAl+4si0nWYmkdP3fxZI1TI S2006j11c53VrngCE3ZpmcVfvMurqOf81kE1dY8AqpbxbiMI2WmzmKdk6c0casXgZQf41GncbHlO voxqOBoXq80JouWMKWpZls3nrhrmHvH65Q2m+W5v+zzQl5htLTDjeEISJJSUZpCFE9vbBQU7h3tM XdF3d/FkaqqtqEUzCL3FmVuiG+be8FOaPlVI2os0KppdUBPbfIusuA+WK0crefHIFFTSFLM3UsuC Sjh7yfRN4vthIcSPZqgY6OoQcTbiDaCg5wQY4j273W85hLdK1wqRO++bEJEJFO2HquXrKpQtnq6H GFd4bB0HNCqUjbxFB6xHs7W0Kex1elf0dPZ5ciQl3FU1z5w01Aza4omP6/z6rqEocQkNcoewFKFm 5KW0iZWesxVUyHuC3YltptUhTy+s4m1bhuwjZGuDw0hCSLVkTWRcersjm9A+jG97uLTVcrcN4S4V Tb6iQYRzHm2Kn5cDMJN69Q+PmhFJRMJYYbuSny+Al+WzUIK0/azwpRvWSo9p6ezy5C5SUrntD6dl XB21YrDhSBnlDnMa9VM5zx5ZWKZTiF1SJnvLcKcJ1WShCFUiqMNYv5imykpSqzC0T3lZyCYQzR0j j5VYy02JiWkHPrhnmPvC5jfQcbdA2dkKGdR8kVqKNhSW6+QqEKUVbItwid0IaaQG2mxhQ2mwAeCl 4CblIriD7Pe8UPtd3FiR9k2xd0dnlyCqpuQNVDlE1sV3NKZsurVOzh06RfrVcIWml5JXUjTljiuG oOuf8jpCb9AknVA4zLVCj/cWPmTOP/puoqFApKOGm1JBnsqzfJBRQ0jdOCSThGdVp+BaqGU4mwMN miLpQENoK1KsAEbu37LxMPp49zrw2/Drp3sXDXLFhJTcZ3iEtMpwITcB8NN6nQsm8yibFOhs/WAt +X+wX//aAAgBAQMBPyH/AOHq1lwTnL463ORPdONOWO5xHOkXGF9ZLJ8O52mm3Lu+ASwR7Mzoi7fM a6358eqZlqn0CAINN58JyRKmWAqrdoz4P43qh95t1p7EIVp3l5mu8Gk4bShZfwipFSGmU246kgnq K5loRG1VrdZWhGlvtzMSfcIyjWAbynyeeqN72zef+iZi6iCyjHEfPdOUeFDBpsdE01y0eJWvorq+ ofPODlYrdg2crrKKKNN42OkoJg0tQS2thDvoxj5hQix2alvm6janem8Gr6sxc1xK/RqRLbcQalSa x6MwD8yxaBlgFydoJ68D4d34vp81V8Q33lini+JpJjV59JdkX2lBMLvxNY8oRGFWPozFWdu43XB5 auxDN5p6DkvDn2kx3iq7vvq9P06fC31LAMyVH5RKxZqkpL0jezEthb3lsHcvjV807Mw3V7xbvdN1 QhRPVdjQnuW49un01MTuvgIdYwWtQlNQW6P4iWqzmqjnoGfvKlTArbc0709CHl/IBcq5WWN38NPe OVXJi1+3fpsdl5m1gV4NuNalLI5W7ZoiZDf5S0znW784Lh32mbSjjfAfBM1VGg/MR1W5fiZjY86z Tr9H79Ng3r3J4e9QxlduQvfzjhy7vvB1s0wGDKbvuhXEfQ6/OWqpsnDFNwvfWN1M7y2z+/TPomGH nyR9zesTYm9pvHYKo1gNrZ/eWcPbCZD0LSxgHYDz3f8Asxw73+Z3VtKnybprVdl+X4hG1mbgo2lk 0DUnP8O018VV61PAf4ZxMXvbvcxLGpTxGeWpt34THaCLzjC+pcRdiRjzNSbGzjTurXXpmsTmGqN5 ovT6giNZIjeAOKJwylZUBUwwI07q8EAM5SZ5v8HftnMmsoUKXqCZB9plKY09NPjPp9YxRt73tDi5 Tr0R+8o2vWWIwMsDnDf3eYPGpcsLmRE7tpjeiB8K/Ka3JxNcb16ZXVCxOqmLPa+fuR8wY1QZZK6m nRKza3dk1iJn22VXVXw2x5/K9idldDQmjr+EauJVtKdL8kVygwZIXfQ3YAhRdi2i7bCabpCz6YBu oY0bHB3c+BJr/HnK/wBwv5hN9U9Y+g2l7NKsHkfWS01m5HSqCNpbb0nlfYd1ApSTIVGMTWedSGi3 SFbAmoyeNZbnHyLL2MeDl3cd+0CpFguzFr67SrmtyOorX6XxBPIBgcHACRzII3Js4IFtH+RxJQvS D47dJamUAEFYBeq7BFqAGm3Yo6lrpeyFqIpV2pjbsNHkG5sLRjZoEvOzkYDxf9T2igElXyF+u1uI lU6uxZz089fIx4Yb2zhdUaaKo2SWZ/KgEXt5e8a5+JTb0W24uu0tjb78S5CM2TGrhoMpXoSlqmlt YDDYwuuECbIr8dm8Ktnb4ktbgd2CECAqrYfo35AKSgVbpa3f4CZ7chXyzNupJykqbS8uvScXh0O+ Fi6W6Ly0oA0y/bqEdhgoq46q1Rc1bY6GrR1SyeCQMe8D5pTK/MkxubKcIZJzftRbUWu8BPsQC0AP 4+t+A6D93pApMLPOFXvKHlKVJn4nL/vdMukz2ZeKtql0VNpZfX+g11WbyPvNZZO7O/Lgq4TYvRWm 1UmEeM7mKmr3f6EERLHUic7ABUtg9Lg2VtY4bKRb9p/kt3/0Mf37MDVGilg1jME6GgV64/todS48 6pHJ9TMbV/X7gz/4L//aAAgBAgMBPyH/AOHz1oteBZSV6t2nivCFvjqlUCj+OFeqVtQi+IqV1NS5 l4VRyyX1VjUPCkBheC9fTfqKkDeMdSrBQblkrqsXi7l4AR5OnzHgceNq4bWXsyR9fmdr/nT1UQeG qWeBVXb6+YLgwfMz2r36gcjKHh2Rh3GnP1vCKIg6gLUIy8BUZWB74t8F304Mk1MPBZrMc6RI+Fi+ mfiNPA77SiaxX2moaxylyumNxh4XHdukA0QbUUUdYYVnBdXTjoYmMcTsCBWniPnhsWvU4Q6xDSH8 fQdTYJ5vTsDxu9IBzG+kYeqlqZ8swZrHUJi9O26uYfm8aJXM7prDeYxJdS+kALY5XwTZf68+8Id4 7CUQPCtXgBBo2j4V0QeebfHMlunECTF2uvrA/jWIy8Hou6JVqL9bwWvZBWngy1f5WEu/EvoGw98r mcK/1JUxJd0T7H0f3gKYAo/u14mmn/gv/9oACAEDAwE/If8A4fHWoXCSLS3VnLxEtfPPy6o2+CvE 6259rqjRfgHjJefrqRbGEMMrhTqji/EAgQIOpuR8XkkHaVUXq8B4dEulj6ixHhDxMRYgdqYbEl+n GrH4LvAwwz3Zc3kxMrp3iFo0o8MnnhEIHUWFx1x4hT4I+J4JFdONuPDBjBLmePomZ4AyumNmH8HM Ww8TLux9pTlSzpnUWS7gQiMX4A7SzSXZxY4B6ffuDGCBgQ7tleDeSV7NI3UMU0ht3G6/429e4uoD UUvHSMUJvpXDqIPExMzgSthHcolErpC1MWQ8Dw7JoPBXgEldGFwaxMddPtLGNJUWXfhcuUyKOb7Q 6RY7QB4WRC/xslgeOOht1nElAjy/oXKt8OXQ0a+Iv+qsuBKtsz+vxz/eNRb/ALtAZqD/AOC//9oA DAMBAAIRAxEAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQ4A AAAAAAAAAAAABJYAAAAAAAAAAAAAYdEAAAAAAAAAAAAEW3AAAAAAAAAAAAACNb0AAAAAAAAAAAAl Vi0AAAAAAAAAAADT5VgAAAAAAAAAAAV1W9gAAAAAAAAAAATR/UgAAAAAAAAAABfwu/cAAAAAAAAA ADy/eJ8AAAAAAAAAACI+hs4AAAAAAAAAASYBjbsAAAAAAAAAAA64sbQAAAAAAAAAAf8AKweEAAAA AAAAAAEj3lEdAAAAAAAAAACMZtklAAAAAAAAAAA7RKCGAAAAAAAAAAAFMd32AAAAAAAAAAVdjWM2 AAAAAAAAABZvh7HqAAAAAAAAATR8otHmAAAAAAAAGr6wAFfUAAAAAAAAab1gAFR1AAAAAAAg4CAA AEAQAAAAAAAzAAAAAAhYAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA/9oACAEBAwE/EP8A4egFANVw EMoOzWPd+pvbl1nTStdes0bNgyvQiLB2Mj7aETWDbsPxAzOLGyY9GnO969W5ojdZhhNuOfbmDBbM o2vncQG0mdwKdJjEDoqpu19Nyfbc8n59UTm3wM0eS3LilKdy8sw1a5QUHgJv2gk0WS9M+feU0rW5 zSU+c+oH9jw6p0MZTs8PU+YDbhlgBUFWrSBEq3aekGxnA3aOa5l+diOladyaPsPbP79TRE3l23va 9o0FeqZCwhTFvnpEw/soLZKGxQXjSKsRulN1ctzVjcqq7ma7e7Wq6nQaLNHSH6MykoeivMLdZhrT kYYhKi0A2O8ISU3wLhuFbLYRWN7bgsFal1ovITYtal7fndRQRbTw6vY1Yyq6nVFrHLNLR0aL2uAb W5rXclshjkEMys+4LZfyFwcpU7Mzv34iKeRrnAvecl6j3gveRom2o+0zDU0WMeUoqyhCmb8uIZFp aO2OZXKZVby6MC2USaNv3QVKYDl5YKOC0kdrZ8fv+u/RfTPTiYb2eS0Ozb0l2E1HU8a3xxDrSCkz bRseZg38yHmCKSnF40uz8S1lLKacqd8wVXbeS2eULtwDhu7PvGSgyCuCHlBe8QYbjuUZWRozyQ+F XOS5MXuxfT1GEPvIRtYgBNCwajrQ1zSMJYQoYspMcDp2vsQgVS4QwtDmoEjmlYKoS312iYq2C0av e+NI1lQNoK5hDk1AqDpHsEqqK7jbLCKZurBunxE2P+obvjp3BC5Wbs7ZXeEQChXRoSrugvTaBA6y 0usoUHTF1sRgIUGheL8sjLIBuzkpphppFii9jQ25ejnUFvA0eZ6nLlvdhlYSKzFpTz/6hgWy0P2+ s1G/ejTC/LplpsO9weriXtyUs0V25PoFQQAAPI4MmRt1lXNkWpAqcuQXmKR1cNlpsvvFAdQKZ0OA blYBrqZD6jHAuTFZMZasfTb9g8kGw6Lb7Np3fGjXppAu/nB7n4IIpKyI8GmFpbXltDAC5tuwNNtW YDa3z0bdONoWoEQR76j6ypYBfRjN1AXwGhQFG2o9obUc15Uq/J+8Ne0Ws4+YigjBtV33n1x/j0w2 kyAa1v8AtKrZaWLhr2mtttWCgxWOYAWFuWv0edXHgdItWqx8REVDkycMUUJgpLgssNkcWXLcz6Tc ZVo6m+iCW/rpgMUsnkspAAchua63l7YV02ZWAvZUh2K93/NSPP1ARnOfm4batsxZVZgxrMBsetve aWtc4w88q66ChVjoybY1hy0KUQAr1wbppwqqNUJtGx0CnhnDjwp7MfSuaR3Npd2qU3Tnd/CM1r01 EUxx0oXMeTyHjJnsmzErcVO/YxFOqEjt/MQCitarAtoN7iU9C9NtfBP59Y6DHaApxRgaMV6Chaqm yVa6XojBspAJW73KjOecO3qNa31+3TtX4h4plGCjkSXSSRtkAKy03ck0NFuOoOW42PmsC/AoK1Wl /qPDBHPuVpAU0bpeN8wUiC0oMWoj1JH/ABhjpiL/AMwcqA4OXBmFZUvMlOGst5klDxRJEdXhdQFr UnoAbUloZVcq+F3CD8GfI+lxW85WJyLsHLGDvIaHghKJRndufKcM/fpd4X1XGryAcLsEs1ErbW/o oFdhcRXT0A/WzRfO8HgyA0o0G6tA7sT4eU+hG45Zey92W6s1ZcDYd3aC3AtTjKQtvYAbYjTFNcCe dxcmRdQRyUvLx6TRU26ea+kTQkHbEO7UxNlbEwZABVb+5JAw7PSeY7Byp7cwCF2by66g6vfSPUIW LQNiK1bq4F4hVVFCb4Mg8q8cyy5TYXFAJQFYYCQvfm3l7ysCqAU01TWdJTpKhAq8kqN5rYSfYtN+ jXa+JRyq3tWFdIXclexczBUC2GbgcViDQopjApWV1D1WJXKjgo4SnObhhdnhFrajbFLQp0QeyDIB RJERU1DqTgULKykBLcmafJw9rgJlfeBb5JFBUO2WjmbF5uC7FLAG3lKwR7Iqf4g06IYRhEYCpA2m rbFGJYfv0FWCjfXeljIIg0FkFaWw2BincYlJoEip2HctYZhOAEXqTE0FNqjwSGhQmC7VpFB9EaiD dmALdqCgD+FkPE2LQnenuivB50gXfeFjXt6cRKCDILFHvOR87foR18amaKshFxxnIgP5+NLEwlWg UNACqfY3uTDugk0/j7+YAKFi1pQUA07+Bnj8STc1Skipit6uRFWp4wED9CsuhwAH8Qq6wC6NHfVB h5TDbq9NqrHYA7K48oCMUYvHYz5v+396gUAFq6BNrGfrNtixgvClsUB003BZ5IbIpNgVSMWld6hK bb+eWHErBGpArRz5pQKCFCjBjH9AJhIhYjqJK/McHS1XxG9VLqoOSx9YQUyNS1gDlufiQ+mA55f3 sFoTkArQQC6SxwwgNygaKsALay1/agoBwlwVPAEVaXUveD2ah8eMlPX/AMF//9oACAECAwE/EP8A 4fCaS/WDqjxnKyredzqyV2N4S4ZBm8bn5JivO75rqrZ7QACXAIktKczb+ua6p6uhrDUrIEG0dZTL fnqQRQWt1iQtUBtJSrSpmSsXW35rqag7Q0SyYaZuZ2eZeYl2ZuqaT6auoGyXZbzI8BgN9nvDa6zT S4T8eou60MQwSiJeuIThgKqJCyzMpV20v0ur8r3079Pf7tvOZkSMstK+vr/IlXtCVEo0egPr8Rag pttjt+WOxO80vR9Xl306cxzK+3/ZhuVRJYmgihzA4NCl1yt+tP28JvqzlfXf2jeHcyf0ekpz04WH Gn5/BEiG0Oo1tZvS5Kjrw7B/xv2RJ4Pr53ZrDMWJf6PrHTALYStq37cS7BNt9ZjPggRebTskW6Ro t6faFRq+kV4VsHa/uyzBo7xjaIxsUseu0UcMFvFNJo12/PTIVN/2QlIWiW8SuYSSNDCAef0JTt83 P+/9l6nTw3rTb89NW+f6gTce0QFOJXiufMDBRHWpt2T8cw06Gv7/AFDKCOdzzN/PWCXd2/zWaND3 OmZScseTOeOjyRzDNCjxLvQ6P4e32jk6Gv4TtC1/XtMf1z05NC528+qgAo08blRmIvJ384kuD2x/ k7nu/wA6dWSg8VqvdLY6IHahS2X6ValsDwAWx8r7obr8P3LOrfgi1kLRilenSCt91tXpeeMMK40U 8mp5n1xK8NllglvNgn8PrWUDFo9tILZlxFLwaNfq+jUJQStg1a7v69MsDYUtjbDQpgRo4T4nZTU+ vmIw8w8wDwJ1GH3S0Xd5/wCQ8SneV6IvOeEShiTT/Gl79t3EEfkOzn/fYhlOX4vaYZig9Sn8Pmd5 Tg0/jQhrfvUIFd244NI61lY9Pz0L/JbEopK0KcVuoq+OCCUHj9u3Z1YBrV93eZiMSjIG3z+P5Zc1 M/v4hLaXjyckSsQUS1en56C/KzfZ6c+kJ6X5/j/bl1mvvDFQA/pIBjR/cA3VMBAW5h05+t/hn+9B oMABQf3aLM0KPL/wX//aAAgBAwMBPxD/AOHysp1i6JyTgJdt1lUX4K8AUjLp+DNW2z46qhJZb8Ds 92PUn0eefbqu6GLLHwNFNIQslv2dTTEoFGkUVlWstWlj4Kuprs3iwA5JqEN+0UqVlbTBKz9cdQtE VYIQ3HF3anJFnBlYxS1+v46imvVzHLLpdGFko728I6Mz671rvWnn09NGMBZvw3znJKkMUUO275Rt BTjX329J3z3348/np7+0V7/8mWpczK2IBLIoZksH5eD7/MJ3fjPrtBaujgx1CthzcRXzEakwqhLU oyWafk9vljFLX69ozL+/T7FEYg0l5aTDk+qlyUR18UHtB1hbwrp096xa4PNjsHLvBEBxAaRpG1JG 4qRuQt4al6dMVrb9MG41il8CVMEXNiOSqodDvH3PmvppAxawrMmu/wCOmp3wgo3ZeXLsS5XkQzlW idn88QQS1L1vYdPR28pk6d6/Ok9XPTOImWiASH6/2ef6jV7WPgbrXj+SED2phBfrzmXX6rp3bVSx qXoc94yLK+NRZbqF5tGoYBz5n/Jjg+f304IUuXJ8aNUuAX7Rcs34lIxANpq06ZeJuvgEHqgH7j2g U0HywRmDRCVv646TLVH18RKtueTmUeAuABwRpx77/wCRFvKP3jvBDI5mZOOWv1/HRoqNZoVL9v3G 7LuPuO3aVDqafqVNZTFavBzEK3oSjFOYfTeGjw313/HRaRpzLz831tDNc8xbpgmUtdvTJ+vKW/xt eCe0IAaAHxEl1Lt6/joUz0QK4ggnXvLm/oRUK6FfyrU2cTkuqfMxCVFF+v46AcnXBLsXjtE1UWv9 QqdcnnFbzOgT02Ps/L+9FZEVv92rBNfn/wAF/9k= --------------Boundary-00=_LTLX6OVK850HN0X1VA40 Content-Type: image/gif; name="reported23.gif" Content-Transfer-Encoding: base64 Content-ID: R0lGODlhMAG4AIfoAAAGBn4KAA14BIx2CAcAiX8AewCFh7S5ys3ZyLHE5E0VC2QrAIYUAJUgBMQZ CegtDAA2BR1HDj1DAVdLAoE7B6VBALMzAOJHCANpACVoADpZDVZaBIRTAJtrALRaB9FZAAaEABWA A0SLAFZ/AI2IBpKNAL6CDN9yAACaACaWA0ieCWyRAHGsAJqRALStDeybAAa1ACW0ADLOCWexAH/L CJy/AMa0DO6yAADZDR3uAUPjBWvRDITfAJ3kALTnCOjWCgMAOhwAM04ANlYCMYMAO6EDOrUBTdIA SQkgNxUlQzcZOFwRO4AYNJkjQrUoTNUlMgA7NRk8MTNINVJBSXZMO6hDTrNFPdc4PwVrOiRdRDJn NWxgOHdXEJRZO8lqSd5hMQCCSh11QjJ9NG1+PnKIOKx2TsuLR9t2QwCaPBqeOk2cRWulTYWlTamZ NrqqN+6cQA7AThK1TE28SVu0M4HKM6vMRLOzTeG4PwDgPh7pTkvUOmDgMYTTN6DtO8DtS+PpNQ4D hBMKcjQAcVsJh3YHgawAjL0AeusIfAAohSMpfzofdmARf3cpfasthLIWceEdhwBIghs5jjc9jWI2 g3NCc6dMdMs5jNdOjQBqeixjik5UhVNRdoBujpZoeLleitpugQ13ciuDfT10i257d4R+jJZ7jcmI cdR7fgCmiB6pezaTdGOdcnKZdq2ffsCSeN2chQC8dRrHfj2yhmCxjHPBdZbAdM3MjOC/dADbhx3t jkbRdV7YfIHnda7thM7sdtbmegABxBEIwj0AwFUAtIoJxpkAuL8AueQAvgMltiAVxDEkvWgkungl zasmzMkrvuQctQBMtiNHvjlGtGNGxH9Gwq0zxbQ1yuhJwwBXvRtkxTVus2BszIZZxpdesbpTstpV wQBzuxeOwkGJxVN/zop4x6WMuLVzydGIwACRtyGZx0yivW2lxHWkwqyes8mWze2WzQO3wiTIuUC7 uFW4w47AuaW/tP//9ZiWond8ifgABgrwAP//AwAA//8A/wr//Pvy9SH5BACc2LEALAAAAAAwAbgA Bwj/AP8JHEiwoMGDCBMqXMiwocOHECNKjGivosWLGDNq3Mixo8ePIEOKHEmypMmTKFNynMiypcuX MGMSVEmzps2bJmXq3Mmzp8+fQIMKHUq0qNGjSJMqXcq0qdOnUKNKnToRp9WrWLNq3cq1q9evYMOK 9Ui1rNmzaBeOXcvWYtq3cOPKnTu3rd27bOnq3cu3r9+leAMLHky469/DiBMrXjy1sOPHkCNLngyZ seWDlDNr3sy5s+fPoEOLDnu5tOnTqFOrvjy6tevXsGPL9rz67ezbuD/TBQCgtu/fLnlHFA6UN/F/ xnsPTE6cuXKduXE7p8mbZPWsAC5mt7ed+/KDz4H//w55vWL5k+e1J1fPvmZ3jN3ja3xPVvzv4wWb P2eO/Ljz5fsFSBB+wSG033cGhYdUdIU5RCCAAvknnHH9RaifhRBi6JOCAFJoYXIfekgUg6BNZ9F6 J2533Yrxqdhiitht9J6K8xlmH2ILLNBheAEEIFCPP/r4jwIKDERkkAMBqWFPRYI3YIQHCXnjlA0d GSJBSmYp5AMPDMQlkmAO2aRA+eSjU3jKOUCQmv+YaZCUVKYWUo8X0WkRlxgRWZGe9vBppz1/lilo exXheROXhtrTwKKLnqgRo4xSFidLIjlg6aUY5YhRmRVxao+nPYYaAIkXTRqnpX+JKuo/ObaaI6uu vv/qHH2kkhjTg6bmylhNfNbq668h6SrssMTKBOyxyNZX7LLMMpQssM3W9exjMFRrrUfpbUXrWBDE JpAA0SqEAgoDjfuSAOii+xIMCIFLFAbfFuSutdVSCpKJFsGQEQYYXNSvv9Nu5BAEEAxEsEBwJJzw QEAAMRAUEEMsUL0Ts8sSvRb/Y21C//2TbroCfQSFRd1eVPLIFqEMEhAa6buRyhgRXDLJFZU8s8kB Z+RQwww7/E/DPg8EBhgC8VzQ0EIT3fPOPyOk9EFBPylR0FE3jZzUC4FM0NBPG+QuQlUrLbZB9rCc c6kNAQ10hgQRQIBAbhvk9txxL5221XInBAzUU7f/XdDb/wAO90OCE7Q32GobVDXgbxf+t7AhNayR 2xldxw8/lW9rUrYVYS4jivYAI7roHw3OcEE+q131Qqv/czhDCjru+t6Hi6445CCRnhHl8LmYkeQV AY9etprvPvm92sFXETAnmY0R88hfRABH2dF4kfNnO8jh7AbZXqFBl4f/knIK8uOQ+XnDTlDVPm/f 0Pbu374+QoybPtDrppK3LfHdja67R8LL3fIwgj3ubAR6GPEctpRnHkdtrkYySp70ImjACjrwbI8J YEeYox7jXHB6FgEhAkMXuQReToIlASEDL8gdD1pEdRhRoT14x8LsHSZ+CgHRQOj2EBy2xH+vAyKC /37iw3CVpYhCQSJflDgeDKakeF/ZULGc6BUjWvGKWOwJFZ91xS0+JotgDKMYU8PEMaJGf/jSFhRL Urw1evGNGPmTVzh3ElX1Do54/Ei2iMRHi1zKUndCVKLsuCc+KsAiniJJAxSlkUMekotmRAiqEvIl MY1JTEZqkpUwGSaBbBIiDfhHKAsyylFGUk4j6dV8tqNKQI2qInYqT3kAaZNGodCNgzllS0iiqTwZ 8pFytActhekA8+DLljZxYZ9+iRtdhmwk6fmTnXppEWr2MlFxfKVNHlCojDwyjzkbjoImeaklachD m9wkgSY5EU0a5JLOjNPBCiIzmQlkngRhgD73uf8jBdlTIPqcSD0LZhAGxPM0bRkXt9pyUPHg0ygE bahEBaKPila0NODMKGwmylG6aDQ0HZXLR0dKUluF9KRJGYsGG+QQ2aH0KWjsYEn+BxIaksR/0SNh 5zgiw5IySJktxGUMe+oRm0KzhscboB5B8tKy8DBwc+vnDp9qNKP1R0SqG8jl3jfEwgnudYIL0HNo 572mwuWpT80P+fCz1a0KpKxlrRvbcjhENA0xaORDEFzN2hT9BbV6+/NdB2f0ImMOT5kjRGD/TgSl x+2Qr0wJCeXoNkMVmig9QA0dEBFoVJHMqIEXlA9orzrEq0EWLRf6noTMCVW5fi9BZcSaab3a1dL/ NtaumPFpa1hk2BYaU7AwkmVhfUuoDUpwuKKtoGg/q9vb8C9FKMIscDko095iC3RBtWByW5RcC572 KE7s7ma+G9Lmmjcy5E2vetfLl/O6971wbCh8JcPe+j4Ej/alynyVlV+J7tdb/Q2wgNHy3wIb+MBv HLCCF8zgBu8KwXhxMFB0K2GFQPjCkqqwhsOF4fFu+MM36rCIR0ziEjfzwyZOsVVQrGK3cLTFXAGx emFcRfnSOCsdbbGM/zHiHZONxiy+sZAR7GNjDfnISE5JfpNMmjAy+clQ7kh/oxzlIkvkvVaGDpWf nGW4bBnHXW7ql7UixjEnOcxojpaZXZzmNrv5b81wBu+a50znOtt5pC+9s573zGf4xvnPwOmzoEUM aIoM+tCITjSZQQxjKyoaJYB+tKRPXOhKj5HIAp60pjd9FUtfmdOgDrWoRw1hT5v61H4RNKpXzepW u7pZh351FklN6x7LejGNvrWudx2TWp83IAA7 --------------Boundary-00=_LTLX6OVK850HN0X1VA40 Content-Type: image/gif; name="imstp_usa.gif" Content-Transfer-Encoding: base64 Content-ID: R0lGODlh4QFQAOYAAPONqgllpNMPHQWvEqKgl5IGCNuna/y2Ae1GYc5XBf7+/vmaBPruztPn+9HQ x1xaVv/yAP7G0u5uf+cCPptADv7TAHciAf2quwUFBe7KhxfhlBtTSv/7m+r0/QCh6f/2daWJT3pW LXb/zX99df/63b+8tfLYp/HivJYGRQBzG+no44rG84KqFgLH//3SMeiBQNPtqc7I2f6sM2yo0bz0 /v/3Ms7/6fvb4w4lgcDc+qamwd7d233k/hWcfOV9BPjx9O325r3KPO/v7EyRxdCmAv///wAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH/ C05FVFNDQVBFMi4wAwEAAAAh+QQJKABFACwAAAAA4QFQAAAH/4BFgoOEhYaHiImKi4yNjo+QkZKT lJWWl5iZmpucnZ6foKGio6SlpqeoqaqrrK2ur7CxsrO0tba3uK4ru7y9vr/AwcLDxMXGwLnJysvM zZkrOdHS09TV1tfY2drb3NYBzuDh4uO4Kwrn6Onq6+zt7u/w8fLs3+T29/j5nubz/f7/AP/V00ew oMGDhPh1WMiwocOHECNKnEixokWG5wYi3Mix4zKFF0OKHEnSYkaPKC9hWMlyxA6WLQXBZLnj5UwM hW5i2DFJiIMiDx6AsimUXFCgQh/gTLSigwKIMBuuXDhVYlWrGKRmLcnw6sWnGlOKfYSBQKGXZgWN wFCiCIaihP/QKnqLSUjZUWuF6DuqVFHTpw6rXvU6kfBDr4ZHJp4IdqxjsmkHyR2EYYRbuJLvJqJ7 aXKotQT5LkX0t4Fp04i3Lj59ejXqra9Zy55Nu4Fr2o0f654bWZBnt5Y5x9WMSPggAm9XEkBeWS1L sy2PAl35QC/z5i+VYtjA87rlQWtX7nCwgbreB+WzqoX7wHL4u8h5AndbHjN56jLTcy/Pvcj1DT/x ldRoh0CjgGwr1ZagbRi0xpKDsc22YIQMTgjTaxY2WFttB4a124cywSSUZ0q1ddOIN31H2UxCISfU Wi9mtVZbStV011FrOeBAZSU0hxwBL20gxEsj2OUeBj+Bh5P/XULtOKB8guyo10sOzDjdDvHJFNwG hTBZBJFuIWmTA0QaWYSTSKXZF1MNHMjahAhquOCccjYI55s6RUhnnXpquOFsHYIoKGW9fXlTWsb5 RtwhifqHpKM/9bjDBnBVJtdRlBICmiDogZnmdipqipMOOzknhHSENDcCl5lqmeV8zRFCapKgccYZ qpwmpet0fuXgpjR3AstnDsFeeA2cdEaTrLLDBqtNoIMKuqihZu0opEyYKVpoTtk62l2pksZ62aVC GYdqjZodVYJ2D0BZBGibeourWqwGp+JbrzY37XUsXYZtrmcGhZ+AvDLlKzUrHYsBswwjzBI2CQvL LEwNEztT/8XdKJCDh9E6Nu1kaPp71rTcGpJllpK2Chy5Raj87midpouZi6J6a+q81JaqMo+lmrmv eqkWdWu7b7WbKcFrknbwNBE3HPHTCztsscJMR920xBhnvY3GHHcs1sfEraWDyMNtG7TJpaK8k5VK /dQcjkgy2aNlyLkkM5ieOleEl2jiPF1RbCO5o2VKBVeol0JkamtRQSH3E4xqdlvg0lVXDLXTVi98 deVYXz415t1Yw7XXH4LdW3k2zQSkTu7qtFza4Jb6XlqFS6ddf95RC/B11dV8Znq9+/2jkso5l5zh hty3HU+LA8xuX0gTaIiB1lDcedQWN+251Fhnj/3V1n8e+v/opJdvPiNSkkN96Oy37/7715B//vz0 A6w+5fDnr//+1MhvyAQADKAAB0jAAhrwgAHsRAgWyMD6OfAQdinV/TTGvwpa0H3+GwQAEYAAAADg AiAMoQhHSMISmjCEHuRgAhnRQEQskAEwPIEMQ/DAGhZkfRfMoQ6z4aEJIEACIIyAEIdIxCIa8YhI PCIIAYAAAC4iBDGkYSFeGEMZWlGKNsyiPQLAxS568YtgDKMYx0jGMprxjGH8XweTyMY2ulGJEnBi IqAYRQYu0ARVZIAVTWACLGrxj4C8hQ8v8MZCRkACQ0QkEj0IRzkego56zIAkJ2lFPfYxBJLsYyA3 yUlY+BD/AG2UACiJiABCIhEFo0QlEiWAACReoIlzJEEMKcnHPWYgBAYwQAb46MdO+vKXogDgKNn4 QyICAAVsVGUElGlEVibxAo6coiwtWctqzjCXu5whMLfJzU4M0o3FHOIxk5nKYRbRmUmE5SOnucd2 9lGX2bzi/CxAz3ra854W6KY+MzEBRbYxnEIcZ0A56E9lKpOJazxkK5PIygmss4ru5GUmbdnLaFlA ADe4wQkR2kR67vOjk5iAOdOpSACwEpmHRIEEJICChRoUlMf8oSrRucg4PjSi1ZykTrFZURBZIKNL 5OgEBEDUohIVgB59RAI4mIAEgBSYEzDlP1uKgpYiAKUq/02pIl8aAQ4K0as0XaVDDUFHnO40l2hF a09389MLeFCoATSqXAUwgXw2ggIrXSkC7OpTvj5VEiJ9I0FHOc5jsjSrQuSqMp0ZViOadKyEgGRO J6lWO1r2sh+yACE52kQBznWufk0EBQwgAQNcQK+hHQs9I5DavzoisOD0ZwQK21LZLrOctxUiYxe6 SnVGdpY6zUAuGTjN4hq3uC0Ui2Y/yMHODvCzoGUEXksrQ9QKggLYpQBKLBCBjLY2FmgMbxcRSN7y buKbbWTmbLFaUlVy1auGFSxkB1HWsxqAiseFoX73y98FpmS5pVQhAaEb3UVYgJVAJIEJVpoACoDA ihnALv9HfnqDCPzgu7AQr3jLy2EDnhe25DQmSo9ZVcRy9QIlXuhKnxnNIly2nsTNLzWtac39rpUg AA5wAQlcYEVYYKk/JORpEwACDhg3AyDQrkF+amEJ7EACGHZFFxfiRSpPuQNVxvKVx9vhLq9QE/2U 6ioda0xzDtPMZibiZdeM1he42c34Zac7g0vneDLgxvnI8St3zGOjRnkQPyaokBNgABJMlAQKMLSS cayAC9wAkTH48ye4tIgtW5qLVsa0ljXdxYDMgxMABKIhR23IO/JxotbEpQHeDGf+zvjUdE4rNnXK y40sF6F7fm6f/eyIQAfZBAgosnBzeQE8KhrHN2j0o53/LABJc2IDlFaEhsPraXl4M8ykzjYbQwDr Ot8yl6yO86u7PWxZmxueu8QzOXKsY137GZ/wLoCBgQxECTh42G42rRUXfQ/N/sDRERBADABQAGcX AtqSEFK0EwHGTAfA4RDfdKdHgA6KV1sdntigqLXN8SHSkbJp/TarE8Dt/c5wzQs8t8pnrW5x3FqF uY5rUet5QhIKoOCJ8DWDQSBJcLu52LLk9zi4e4EfrHQHBZBADApAAYMTAtoIb8QGNGCDhSOi4RKP eJa7OIKuU9zrCihS1wE4Ai8LEBQb/OEHa852ERbRhAAo+Z3LPdwQvJnkcochAxfA9777PeUgCLzg QaBy/0m2HBzsjqpzh9pseqIwhQIeYAdDiPND+JqDPC/3mw1gbKGH46cAEAIABPDkAsSgBAXQgdMH sQERiCDqiZi6Bl6/CGhPO4xgX8eQVMD7mjwAgL83ezDNTt5SDhGaB5R7ymVtRxnqd4F+X4Adoy/9 EAz++uY2fEESH/PGPx6u8K7nJ0H43UALIAEsyLzP8110IHi+GRY4ByiFIIASLL0AJUA9AJKac/5D WwRVB3stA3UEKICCUIC390Vdpw67VxMO+IA68gAOEHxd1gyhZkrQpAh5B3iDt4EhQH0hkH/5ZwHU J33XN3jZd3jw51bNpXhIFVRv1YL0JEscQAEFcIM4WP9wFjB+5ZcAE2AALMACurR+7HcCJPB+ocB/ gLZ6RRB/jeZkCCBwElAACFACo0cBAVBPludmoTV1ANgBBOh6AGgDZKgANvB6BfiFXHJpD5d1bmhx T9F7EAiBOlKHDnAOD9APzrBBm+VbjwRJd2ZZzxcCJEeCfReCIjiCB0B9FmB9J0h4zLd9LNhZe+ZW b8VZdWUBEMABRhZ0OZiD9DR5qeVgBZAALhAELEABPcdqb+ZoJ4BdTdVUoEBPPoAIPqCEPhYB7VdK BBcDMYACSRcDO/AAXmRPgMaFhiB7rgdtGtCMzuh6ZdgBVSeGGhB1bKh1U2ZxckgmdtiN3Zh/QXEO OmD/bXu4QR7UYmQFiP31gQkggiFwAAfQjvbXjYbodw7miCcYiTjGggEEg5y1V/SUABAwkNlFAjX4 iaAoioVAARwQeDXwACzwAKooXKz4cxRQARUwkJzoVJ1gAbW4CLfYCERnYVF4f6d3g07GAzywAjgQ AEMwBFxkTy/wXcwoe9VYgAU4e7K3cAnIRRSnAl1nh4lYh4lYlOD4ADowjvAgDgXEQuoIfQuQAERZ Au8olXeoABiADvXodxbwiIGnj/oAYIrXggFkT1ipAAIJARSADglgkDaIkDe4g3u1kJIUhNUBAxK5 ihVJAQsAj/BYARzAkZqwen8WfzdgUkIQAaaHAPhX/wJRKAAI4AEuiQMz0AErEAAzMAMxOZOxt5Mb 4AGg6QEbUHWhKZqtZ4A9qY0OQABBERRG+ZqvGXwogECH4APZhU+VUFWGkAIDkAKEwEWgYFk+wHdW uSM6QpVSmRFnqQA/5gOL2JcL4GBeCYnDxQm2iV24SQoAhlBlWU/pkJUBIJBrmQ5teYvhp4UL+QIG gIoPBgLrMpGrtpfZRQEaKZiXYFfXeZvoSQhR5oSHBABIJwGohwCnR1QW0JJgNAM0kIXIiAhT93/Q FpqnWZqj+aCFgHVbt2VF4hMlsBxCsByt+QCwGZslRl4L6QOdeFy2iWEp0KKGgEzHVAS6yZsDMABe xP8DLdA1m8CXxKmcWakAhIgOkukB5+CR2DWcz9mVXqlWO4qiMraio7BcyGdPizieQhoAHtBg6pCV CVCDkUABPrCe6UcED0ACDpBkevlmtgmYHKCRG6kJYJqi/AWlvZZsCiABAicASneD9jd6LTkEChAD LXmZCGoBnImTUFeNoNl6ztiojdoDn/mgiDqpbchFsdhgFHCcHUoAH7ocnjoCHTqiifgAJTabHnZd TmqQnPgBEICRrhqd35UCNtCivikIqORByNRENBoAKsmrLSCZwAkKfHkAFeAD5zCkRboAxnqs55AA PpAAHpkAFUCsFaCkj3hfKihdTkpPq/oBH1AD9AT/AbCahORHTxk5kNMaleqQpdH5nQoQnhnwkZCQ AOoZeAcAAjAABCUwAvDJarbZl35JrANpn5MQpwwwn976rTWgltnVaxYWcDHAQTFgg0q3AzrQkgoa AJQ5A5NqAwtBhstYjRrgAY06qbK3qNUohmQojWhoe1/UVBzwAS7gAvCIXfnnoZ76qa05AgQgquuS lEnZDteVoqu6sAPZqhjZqgvQWjRao7QqowjFRCjAm7xKAzmKo76ao5BAT0q2nwtJrG26rESqABTg l8t6DmAKrfDYqtTaiCiXrdJlZLQYs0Z7tOZZAUs7i+Y6rRm5os4Zj+RZs+kwpAmQAV4KCWDqZidQ /wMU8ABBEBRoSpGsNp/h2qqBWQkMCUNWSrZHq5bkKZKiFKCoZ4U3GANCwANchKBeNAT/x7KOKrI2 eZMbQAEqagEb0APOyKi5C3Vj1JbeSrMBW60PQAAF+KnL4bPrgpRA6w5FkLkG+QExe7R766oYeQBM W6M1WlXHJLVXVVU2iqMtkKOgGb6S+QgeCQFH2IQQYJuHcJHRq6zoMKzP6QPPmgDKagEXeQBsi5FM WLByi6LR27mde4vT2r8iaQHVi5HmaQHUGo+xGLAJMLiE9gLp+6U+8AIS8AEVwAJEsAAsAASRG59q GqYnoImuCgEE6wjOu7loS5DrkMKWhwA7UJJMF/+xkKkDQ0ADQ0CZHbDDTcGgOFmyGoC7N0m7MRuz 3loDRru0t9uMkroB14hlvjuz1ltPftm4OUu8lHK8+aepsKm8QcsOtEuDAXy0/IvArkqs1nsINAqj HFSqMDoBWFqaRAWawepj+cTAgKldmljBC0kC3iquUYldfTmtz9l3t6i2Gcm31WoIOAinsmQBNZhd Asyw2AUBCLzGnoDGxOqcA3m+bLuIAbuIEdysC+Bmfoy4L2CKHFABNAsCOZABeSm5atp0rdx3gAnD irDC7tqsVvqjzcoIFwUAS0e69heFOJDDOIADKzADqsugXZiokAptR8iJ8ynA88mM1TgIUTzFh7z/ tPVovTybxTzbxUJJonBMQM7LiW1qxouMt5zMt5pcBF80AKjUXChAAhBwAPeMAvQ8xwIgrgJAA1jr Yz5QAU0ItnxcAR/wfgz5AfDorEhKvX7Jd7dIeHpsyPwrCDdYBAUAmYwpb5aQuZK8ufR5tJsrkJls wAaWwOeKyT+mv9XrlzMdi3y3aqmMuJiqxBUwAjkABAQQwpMLmHibXcSqy4jgvCbwy+/qy+cAnmwp aRc1sQIHjKaLAM/ckjyww5tJk5AKqdXc0Olw0p4bv7a7zYJARt78zdQnzl7XdT07j+eMzlWlzp24 qp1Lva/KyQuAkXkbAOhgtQFgz6W6z1almwFA/9ABvYgCAL5aiwh6nNB73IQM7dCAfAC2ab+FPNPK ml2QiMYa3chUOIVERVBTiLl3zdScW9bAnADUmrecEM8vbcXoqteGPMq6lNOIW9TYFbM8x5r9yoUA SwF81LCPoNRLfaVjq6UKgKzNGpI+hn9Lt6cCcLpcxAM0MKSSWZmGypmHwIxgHbMszLnj3XSwp9Yx m64l6HeY7QNG6Y1ebJSkWqIC5AOR3M7ubNvVC519XQGdRgNWm6PZi1Aphtjg6wECsAACML7hq6OR rcdeisAN3b6XzdvzeeHHGwEmQACc/JfVeoM/FNI4uFIiLQn27ZboANVoOZ4qjpbUioSV0OGzzf/h HqnfFH0AF5kB0Avj0jWtFxmdFfAAZEoAI6B+bnaL2KWeeMTjFG5JOD64bGmlY2vKTN6EpkdwUCgA KMBFDb7MKECMLWCoGDZ14S3WKR6/Zx6/sPcOCSCzbL3eo9zePkAmdOgA8v2zYRy/covfSOuq87nf /L0AgC3Y4Zuj33DPV0XgNUrPOCqZPFCaoengxCrZXuoDE96+DM2qeMsBS5uzx2mEMEQArxjK1IqD HHRzRvVDp/2lRsYBEYYOXLTc4xnrbMl38BzbM520mMzhDpBdABvnmF3jH6DbSrXPDInjNPu4QYCX wX3BL3DBnGcAVT4ImctHhlzKgVsB2M6Wwwn/3T4mhUn3AwFXVDcoV9DsoCIwxBuQ3kwN2GT71E2N tgsQde7QpTS73vjO3pj9gA5o5/INtHmuAPYtyXlNvSYNj7bOd4NutXakAJcpoxNQVV3lz4s+x9cd RrT6tNROrGBKrIx7kWqZ1CjKquhqzQygex56sPtM0weAg0SVg0Wl6iXuCPbt6q9+rFjq1M2d86Zc yNNuvjMtsLtuAXT+iud5kdI67D9/CAKJ4xyA4wbAuF2Jl/yql/Tr7LpkbyrMAOl929vu2mr89c85 zz4mwwRX3edwWqKWUXja3TSp7un95OeQoy2AtnMfAHUv7xZa7zKb734fnRG9jePh70UJxmHM/5Ak iN96Xd4Ij/CD3gIhoLQhoACCXQQDAPG6WfFcpJwZgb3YawNOy58NXNsZCeMUEMi1XYNZ7KnncLAZ Kcr6+9EwL9Km3lwdfVdGJkkysLlTztzNTZ58R6ywnQkdTq1Df5VWpCM5K8ltipEavPSG0KU4buzY Bc94CdxW7+wvIElJFrcM8AF++7eXeuOXuoiG7O0+NgE/8AOl/Q5iju49AKka7OPpkPfvPvfAP++v d0CmCAgyC4OEhYaHFIQ+KjuNjg4lkZKRDyiWKBMTFCQ+HBAQFKEVowkKpgoYp4kLBwcLATQtLSGu PiEKsQFFAwEtsAHAwDQ0AbjFwwEDysvKKf9Fz88WraOfB58+PtDa0QWf3hUJDKfjpgwUFRCurBUF AgXv7gLu2u/12/famxwZGa2l5D78kVOQoNAoC/gSKoQmrUKraRUoOKBg4cRAUycscNiI7gMHHxQW ikzAAV06Cy80HqBQggCMDA8o8DPwoqaPmi8yvAAhssimDz4sCGX18OEodEePFnWIsGcRCwJuKLjg rp28q6ZQNr23QUOPDR8gOHRFYWCisuRWLei6IZPbtwlcqCsUqq7du2pbCWH0CNKkEg8oWXKrr+Q/ BefAnSqWSoGFQa0GBQsBIEQIWbJ0BeDRwgMPHpt9mSJW4tiKZM2WOdsm7YDJdK2w1cX3zlv/tU0D GSQ4lw4yvHbw4s1zqlBfv8iHFQR0fSB5QYMVthIXSQE20YgOdle0eOrECQIaS3768CHkdHwkIXA4 ILTkSpIkWDwAYWEmzvsZQJgvziDgp8djTePaa7YptcBB00ElwSk3XHDDDQAg0A5KKeGzgQhegVWD XBAMkpxaaJmSSAWsbNCDCG295VZchoRyyIuGHJDBXnw14tdfDzwwwgiDacLRYamcc5gHAXgg4gK7 +bDOMcP4EgwvnHkgD2ZEAqOAACRSAMxpqDWDDwXLoXMASKGMx8k97xCoHgXhMODmbsypE5xVBRQB HAISnvclCftUoEBkoWBjlCu7sTmIAqwc/xidniI1pE4rFJyQgHZCVVopR7YFxeg9JIkn1gIUuLAA ByQQ8AAQMdl3X04G7JfQT95YENAoRlFj262tiCVdT0IJgMAFETzIoABaJXThV+SJFdkgdj3EbF2F uMLWRYiJSohaMMLow4w01ujAjZI8oMO45CIm1mGMIZackSK6IhSYFcCCmS8pLFOklCRAIIAH/MKC iwALgDQaMl4m1FoFH21UzUOuPgOcrR2uV2gC1jj7DgLyWDVPOxJKUOem0PyUgbLMrifrrMsWwg9E u4Kcj3WsRCoppZZSoHCBDbuc3qcUgPBBBRkoABMJMIxQXwY04ZdBztvYHNYnFCma1K1Uw/+mK6O9 XiWPVBS2XMQGHYiA7CekJKAkZESlfIi0GqB4EQWCMEtXpXid7c8i3XoLbiQ6iEvuuNUpZgqRRlIw 5kDPpaD44ikEAwwzygAjQG/7+ksMmAI8AMswxAywmsHTeLLwu6GgmXEBSHWo3kbrRXYxnsINVwCe EtT+jstOZ0ArpCcJuntRzK2zqMv4OPooWpNOSvfN32hKvDYJiJWlAUDUIGMFDzhAQAksyKTqCwYs TR0DT0NgQQINQVz1N7kOj7VQN0jgzgXFWojh2Oc+ljLwaj+61okbeJs6VkERC5DrAQRI4PZKEIrk VUAFedMbjsblN3IFzgfjYFdiMHgKinn/KAU2gJwIB1CXF/DAcAsQAA+IYYx/GcNxlqDOrDzxEK9t Y3Z4SpNSirIAeOAJYxobjp1oVzuP3U5PP/lZgKrDHmwkJUBxYtnzineguaxEAd7JIgFsJjqykciG OisJqChAABe4wCEsAMEIQBCEEXhPVeJbiAXIFyvtyeqJeITU7q5GPEt1zUJhy9DTlPSYtEFkhzys oolE0IEUvQWFY7TAJS6BQAVK4luOgGAEbbQ3wFiCR5jQhFgMwMFTYOko2JhUZNylOMjVRRkUeAEC AAAACnSmF57xgOZ+MZoASAABKFBABIDZqEAVEIz08BXs6sHMeihzmVr7GDRw+MscbiqJ/16MCASC 4kehTC1ACJriPR7Tm2th8Vvg8RRSvihOTimrgSAgAhEoYAAQGIAFLDAaPfnBT6ZpwwIVKJ8F0Akt /j0kKD4YCx+nKJQK2e9+YPlGRNL2TTwWpGImapsjCTPASU6ykgssASYzuUlOdnKSE8CE4chTgVIC LI9qs4BY6gXLCL2AAiQcxAtq2S8q6aIIViJGNVEQgV+igDgN4YA/kzm7av5Qa/L4ITSjiaZmguwc yfKG4V5DHvJw4mTSqxUy+6ioudhFJXhcwFiJl56QsAl89nwAPvEJA/1YwADhi6NCZMWBp1mAADtQ gPa22E26/e4k4myoQ7cBNrEJ8lYTHf/Q+tABqlwdIKOM3GgmzkIBj1LSkiIdqSZLyslJBAalKQVT X0mUAHlILSk8dJf0FEcBALxAUbypgCwpUKXOeMAX71AcMIxqCQQYNUGuUapI6GRcp0r1uVVRZsba eY9A9VWrAwrLE/8TsN8xZ60uKyTJBsG61g1oEOBlawJCBr78bIAFBBgBB0owgtpZoGdLzUdWKbAD ApxiB98abAIfUxIogkKcZOSAUOzXNg0IsnxaTR8eR1HZXJmoB21zW1pApYC/lQukkcBkBEn7LdPy rVwdpkCyrDgg2PJQIwEChW0XAAHEvABRoQBGNxxHtgIoAwXAVEA6LnGepObXTlchYhH/l7xMq8Bu utQNWUlUXL6tQuAD/MPGycZClANHeZwjmvATQZXeKMcSryzIwAlGAAQ1SsAAtUOfU2Sl1cAm8CI7 4KJ3mTJFm1nPhhdqcIZ8sL6VGM6gbKrVhb2SWbOUxcOnAHFoRztivd2IgiX42ynoDJtaPdFZavXE WBxCAQTcNiKICQXjUDcIH7C6hz+2RG+ISkzkIiy/QVQyAIqIMag+VYhmdg+nQTGg2HDTUk5c1ne/ bDD9TZgsZWb2mfkJgh2MYALGvQCcJXDkZ/BGLPw1hQLHvcUCr9Ia3e7JWYQiZ8aGDcMO/opM17ce MtFtqwq1QA/23WANjyNEmjZFJUPs/4BGVPoHmwyMJHQwgkyjWERIeRRMPQRjhzjEyyWMpW4pQFNW JyBNg/BxMIt6iaLWGqmu8bJCcv3cXmtNqlA2M16aNTUI1KC8pGrNo9DNbDkWtlI9R+I++5kAPBng AiaA81rvSLZwU2sHCeDyOtjzvLMogIa7aqxjHWwiplcN5xJVB1P2De8TNVJFb7mEWyQt4m4hXAin imD2FF6CT3rULXd8SAEG4eIe7l3Ug7qvqWmMGCEv4KbLqEe+9v7xARC1dsCU6lGLnHJcxw6qvoY5 sMWJDZx7XnRQ3O7JILPsoJv+9D4ZugWkaoAHXYDbvDpQ0xMQWHLkGdSuUWvVQaFz3f9ro7En4nqG ALQ+6f2OEF8ke1cYnVm0u6VHE6hkwzF5qrjHHe57qX4jsoeCHNVd7SkNZSb0h6TzkX6AB1CYQ9ah +9reFlQvINECEIDTAXSDHZ+ox49NDsxJYq3yC0EnmPdy0LV5COZpYkYNUHRQo8d+0YZ6EKgnhUIR k4InF0ACSScBS6co70R7jrAb64F8HfKAxVMWCnZfLXMhjrVvXcGC5HQUEgVFIqhWZIdhXSE2zed8 KfUW0hdalYACbIZ9QmAJ1/cAjvCDQHh30Dd+rEVmfmQ4oOcK1uB7tWVqbnV4s4RT9xcw73AgsOZ4 RPY8DaFypnM6zhRVzfVkR/RlsmL/UG54FIUVMEoyhSQYgXaoJ6tHOxfweho4ZxxYDROTfoSQcr5H PIajc4jFWCKwgl/hFV+xAQDyaWrDd190YfyWUSfib9QicAk0AoJVcH4zAo3QN3sxLjuiAztghAzn YQGnA+TwFIPgDZ9HMuclHbPhba9kf/L3cXznaqnhOQwFgLTRcrCjZLVzOqd3TN1kF8txSAchhwnF Tnc4jUGXh831S+kVibLIOh2yDp9Sh9UlU0OBXlyxiMuXIRmyAZBIiXFyfpSlVpZog/CmghvgFAg0 As8gUg8ADaK4j0VwKvdghEWAj1hDNd4FGd1YZsqwd1yYAnuHDT7mOcCYWMJ4Q1K1/2QYCURrSI3/ RCbNyIDYQGjkyJEkGWWrx2vpxhAjIlHfwDPgWDzWYD4LxhUOpgHnWIPqCImRmIDwGI9kJ3xc5xQ7 og0E+Qz9CA3+uA1FuSn39VqIlHsUoScL+Q7NYA+p8TliWJHTRIDG9Wv2UJIlaG9+5ERZ8pJgeZbQ U0ApyRphllZRyYaRAUbneI6O+Ij1WClOqVYLlpPqyG9AaZPEsZT4IJjVmAgtZiAzySgT6SXAyAxY mZXo0DBBhHlfiZYGAyYhmZmEZJaW2ZmJ9XOc6XNjxZekqY7F000KUZo56Zl4CJrEw5iNKZEF005j mDPNZFWsKZqFlZu82Zu++ZvAGRycwjmcxFmcxnmcyJmcyrmczNmczvmc0Bmd1BUIACH5BAUoAEUA LAQAAwDZAUoAAAf/gEWCg4SFhoeIiYqLjI2Oj5CRkpOFK5aXmJmam5ydnp+goZuUpKWmp6ipqqus ra6vsIMrObS1tre4ubq7vL2+v7kBscPExcbHyMnKrisKzs/Q0dLT1NXW19jZ08LL3d7f4OHi483a 5ufo6ejc4+3u7/Dx8uUd9fb3+Pn6+/z9/v8A7TljJ6+gwYMIE06iF7Chw4cQAQ5USDEehosYR+zA mFEQR4w7Nn7EUGgkhh2ThDgo8uDBK5EuKxJqydLlA5KJVnRQoI/jvYv1gPITOhTDT6MR7RENyJOg zKfeMBAotHGqoBEYShTBEJNQVUVcTwmROgyrEKiGaN5UpJMnPqFE/5f2k5tvKd2Hd/s1Rct3GVmv fz2O2Np10NdEYU0dhoW170ybOBG1bUCZsl2keStXzmwZaWfNoEOLbsBZ9F7HqIkFFrR46+DEgK0i gj2IANeLBGxjGFwEK+6tF0fQZHnxwVndu4tsvIlhA0rkvK+CdLCh+NkH1Y1e7fpgsG+ytlG63lq9 MPXiHrM7r+68CPINK9VCZttAAeiLo/GTxrAZY//PoekH4H4CctRZgfyNNpp9TqXm4CofubTYTVqN JOFI0XkUoXthYeWSWVhpdVNIZNGElQMO7FZCcrYRsNEGQmw0wljeYbDSII2N5VKKkIknSIpnbeRA iMTtEJ5g5BWio/9yyV3kgEhP7kZjETzWZOVaOdV3X4IBJqjfl17yJ+CWIwEIZphmcqkgaAw+6CYr qzH5kVW0sRZnSYUJYttKexax4g4bdLXbVzQFSkhjgmAnY6IuNZchjiTpcJJ0QgxHSHIjbFCEoYId OV5yhEh6Y2OJJWYpo1fOl6V9tozZKpo5uBqrf7qMCSYtt+IKq6y9tPnmr6fE+VWKMHqUJ5OyHVIn h89N+ieohBHaaGGWjvgXTSUw94CPvZGEKLOnXqXpBq9Fx5WnTSbL4UeEGYuqAy2hJx9xbOWgwC0X 1YqBrvzii9Eu+dYS8Ej9zspRwcDc2yCwDD8i7F9VtkvVnZcee+T/kX9y6pq0mxb2raLXFmabx5FO 2m2lx1Y1qcYqTjplnJKeVbG7NS23raHzYimZvf6+2u/A+/YcMC5Dz4pwwUUf7YvCDTcdycOyYaWD xLGBZfGkGJ9E5E0rJWeijTquOJhtGoW86KKQFrFkleEmmtjWNqY42E2vqbukEIaWGlNLfXqYaiOz 3Nuz0T8HDTS/SQscdOGMNw7MLUw7LTkjUBNSnUhzYs4RtyblhrWzk35nFd3DMdcedMiiipxxh+J0 HlfXHcth1BhZ5RvdW6lLpXoo6Y2qtmvlHNkhgedysOJI/+u4z8jrOnTRxxP+eOSTV2+9MkCiVfzj 3Hfv/fe6UH/9//jkv9I2RduDr/767OMifiETxC///PTXb//9+MvPSgj891/+/6gYi8mgkr72GfCA 3HufIOKHAAQAAAAXiKAEJ0jBClrwghJ8YAP1xwj/IYJ/DAjhCUYYAgCaEIAFRKAKV6iLBk0AARKI YARmSMMa2vCGOMwhDiMIAATEbxEhEGEJCwFCEY7wiEM8oRKtF4AmOvGJUIyiFKdIxSpa8YpYlKIh XggAHXrxi2DcoQR+mIggCrF//DOBERlwRBOYIIlLjKMcq/fCC4TxjhGQAA31mMMHipGMhzAjGzNA yEIekY1vDAEh3zjHRjoSWFz8ogS6WEME2DGHKKBkJnMoAQTk8P8CPiwjCURoSDe2MQMhMIABMuBG OD7ylbCUSfwo6UUY1hAAKPDiJiOwyxt2UocXACQRR4lIUxqThKpkJQljycxmIqSOYLQlDXGpS03S 0oa/1GEoA0nMNnrzjatUJhJNaIFymvOc6LSAM9fZjgnw8YvSnCE15dnAd+5ylz104AyzycltDtOI 32zlIk/pSutZQAA3uAEG8+nDcrJzEQ59qCsmcE1t8hEAncxlHlEgAQmgwJO8tGYEcAnDTfIThxid ADeLeUw3FvKlGUhmQSVngYTykKETEIBOd6rT+EVUooWwQAR+ClRUTOCS8PwoCj6KAI1ydKN8vGcX GzhDqp4Uh2P/XGlAYarKrnp1pk2r6QUeiFP58fSsApiAOos6iJreYKhsNWpFc1hPSlITlx596gyl GtJ9evKqNkypIQRpzJd2FY2ITSxYH2QBOzLUh/NDK1rXGlcL/CACCaVsXClB0TDGc6S5JOk79yrS Xf4SsDXspEr/eQKYxtQA/SOmbGcrWw++qbEQbCBk6SfZyVZWAjuQwGVvoNllZPG4TsyfcperCmh+ sZeg3etFN8lXquLVs6slhBlbW8jDCpK2awyheMXLPzfh1pIbrF9vfctWC8QgjwpVQHGVgVzkLve+ 92tuZ597zXnicql65esFAAzSjgJTmEVIrDljC16WtvSQ5HXQ/3nRa7/1sheoB41BR+NL3G84sR5P BPGHOxBiEo84ufhNMQdT4U6kcvKG/e3vNG8pYxoqNrFdfYGOdVzEbm7VtTA1JQMWW5EJg7LCFubp fJ1pgQIAIAYCwOwFfnCBJadCU4s4sZabKGIum9jLTlSHNlYRvxji8cx4TKNLxWnMVBpgxzweL0DX 7FqvJvOlrXQMbvN5ZN4mWckYpkABNFyA4ArXjlY2xQawrIj6HlfM2WBFmV2M5krfMAR0BrKb4dzj OReWkHYOdVcNSWSETJjCflZyOlddACbroAAliEEBgCsAAAjB1oneFKMfAaNdIyKKXQ5AsIf95TCP 4BnHhnQ0Wv/BQDNb+tk2DmF3vYrKN+84AZgeLwlv7GZRe5uQpTbInjfYZ7Pu1JwYrKAACpBrhpkT ohYAAKxLUIBBl0AAQhipM3K96EU7YgMasIGvDwHsYhO7xE4cgcKPvXAFzEjh8RuBiuf3CgbCEILp zvgEbXhBAGR7yK/17rXTON7+LeDkKE85/wwAgpa7HATfRiVaTn3U3eZUAOi+aVnp50AJsvt6FtDx ks0ZAArUugQImDWUERDcKf+g3RsQgQj8rQiAa2Dqi1i0o6XYcGnESAVgD8kD4jf2icdi4su1JA2D ib+Pr9zOaBwheUOQ8gWgse52D8HL9x5qcEOF5uXGeWN1rlv/n666nFyMYLvNK/S2Et2J2yI0CmIg 69z+QAGIznrUBU51QfT78/02BOi3DkWFR+PrIUm96lH0AHiZPSGTnmEwFfHxIady77XnH95DUILe l8ACeLf73l/e93DHA/CQHTxZNbjBco6SA4Kut/TZbYHEL14eRBVE9h3/gnM2cQhDCAAOVsADHgS3 3rGu99Ivm3lGAFwENujA56UOfxvYXwE2mDro4S//ImxZ2AYXgMnGE2G3equHIgjoAM7wAOZAEQzk WP4USN+VWHOHbcCHcrzne71nAQeAdxagd8MHc3D3d2OVXkc2VsunWw1lAR/AARxATNE3ffVWTj13 fe5QTj6A/wg+sH1FEHQW0EQzMAMBoBMzgAPh5wEIoFMI0HsFwHQFEAFCMEk3IF+NYHVSt2gakIVa KHX31wECR38aQHX/d3AfNoCod4AJmIa91xLOoAOR5oAM9EAINljfJWe6lwC+FwIHcAB4GGtpeIEp RwEgAILDN4JPcV7yo3OPhQDmBAGO6IIvSALQJ4PTZwE1SBEWkIOLsIOGEHTdFwA0IIRRhAMHJQCx lnQlIAGFhlFQSIVVCHBWF4agB3pXZ3W7RnpNlGwFmIYJqIG+uIYPoANueA1PYT8dVIe6twAJgIC9 p4fLqIAKgAHPAIgpZwEh2HKGKBOICEqFJz/n5IgL4IiO2P+CkTiJlDiDL2SD4aCOPdiJnyh+Qyh+ MaAA4YcDtRYD9DZoEiAAUCZcCtBh/2aLG+ABBOkBGyBwBWmQUdd5goCLuph6zPiLEvmLZYcC+XMI PkABGplOpLBUhpACA5AChNBEr4BYPnByz5giKFICIbCMAxGN+5YAPtCBC9CBgniNIqhKxvcIGbmR 6MQK55VP3mhOFVABHcgBEFAB4QiOJxeJO3h475YQa9WTGkkB59SJQSV0Q4ADARCEXBmK4qcDIaGK FBADDQRlUAhXvCaL+leQC5mQBwmLhVBwCHdiD7mSE5mXGvgAAKZchUABPhCJtJWRiZYChmkIoYUC ReCRIDn/AAPwRDzQAguzChSAcgnwktKoAC35DB4QAB6wbz15kjRpjdd4WKoAmM43W+VklYSAAtOn mIWwVK9JCLjFdueEkkVplAuAlEoJjrq5mycAfQ4CmIIpZ4QJUd1Hj6PYRDwQI/UGAPSWiqsoAUs2 i/0WhgQZdVq4ndvZAwMJi9YZngCIcDOiEg6ggbmRngSgl77Il32ZX4JAnM/ngh9QTjVQA+DImoeQ AjZgmCIpCJn0QLnkQ40ZAOVnoC3QmST5CpV5ABXgA87QmZ8pXwsAoRHqDDKZAJmYAEZZlKQZgrC1 k4yAmpkIiR9wovf5lFbpmvoUARegirC5mBZgZi/qmm2l/3jltIcLoJQLAJXhuKO6CQG7SQKa2Bfy WZUUcKIfcJ8QgKSJ4Ik/2AErYIQdUIRDQANDoANJiAAxIGhLtwOMGJ7x54X5N3VhqAEesJ3haXXZ GYb0Z39eqH9ad0UjgJctcad4eqcKt556GYzCOIzSEJ+CSZ/46YjlVAGOqJRL1piO6Z+LmU89hAIg aaA0IJmRiaCSmQqrqX2HipQWOqEUsIcHYKHOAJgauodJ6aAV8IHcdpockImSyAFLKo60uoMLMGun x0uKuVSYJXsa1Go9eKhGOaqAeXIUAA3SGAAKoIy5eZRKaQLCyRcUEInH+gwUQKvViqGIUE7v2EQ4 MANTiv8DWGqPXEpv0DloAIBznhd1ccqdZxqLsrgB4LWDG9ADWqid99pvV5QA/JoASNp701hOz/AA ucGe2eKnwjgNllUE0/p8LfgBtAqOFpCbRrmojumYS4VLkdpUS/WYkdkCkkmQINuZqJCJEEACFNCD EJCREFuh1lqTNOkDPsCvFWoBFGCUqeqhxDCtFhCrshqxQDtrU/gMCZVQAFa0LvpAHZV0wVqUe6ih ykiTlxmhnpkAPXp4GYCysKCRPekKDcsA2Wqtjhi22noIPuitQ8AD8OhEOIAAzjl5AlCW6mo5tHiv GmCvsoiyGimrKFqoGlmvWQieGzCGX8avsuoCLiCqq8r/gPumANlKsHx6nn36p4DauI5LTPSJrVWp qE5bsfuJsSPVQADGqwAwAZ6ZkDpFkAtKCQ7FgRUgnBZwskkqpMqokTU5rHW3g6eKqB26qoYgfalA ASTQsxyQchFblCjHiEW7vEV7AQXgdC46Vp0EQxagmBNrlDO5h6FqmZyZANr7DMmqAAmQtSnbChop qtrLCl8btpkpvtnavuJrtkKnAEKouh5AA2proEKwboSGjz9XddfpnYs2StMKsUArjkqJhWE4CITb RAlAAieauOi7h6vqDBlJqgTrexFJkaO7VN4YP18LidgKDTfbgQ56wpQFRQOQSbqFAiQAAQfAworZ RAQp/wBCKgD4m6mTkIkV0IMOCrsV8AGhyocye7vNqqM1C3OuO6w6WwT15sQC0EBPXAohfAAkcHKo mqgviMVPxbzMa2uyJ70q2FQ96LSquqonaZn9ir5TK6EJ8GZaewpIer4TTKyuKkLvqwDK6r7OEL4Y Ol/cagGSyZc4wJUg20QoEMXn92T/W4Xe6Z0EDLEnjLMI3KwWIJcNaUUP/AGIewC3icWWtawJIAML GLm9OJHu6cE+tQATEMI/K45k67g02YHIq057rACVGgArPLowzFQeCYo8YMMdKAAfq8OR4Lo+/Lop O7FCTKxWa8S4S5UieL1M7LtNqIpKCEOqSApVvMW3q/+qEODNB+BklLZDKDi9LwRDrXa9FFyUVkmT KTfByhihVqtjcWwK0+qIPgABJ3oAMGzG5YvPkehG2SqhGFqtBo2hnJiVP3hW9cZTUKiKEgBl7IiF kDy7DkoCqurPSfmCG33JjKbJEJy41UiNnuwMpKwAGeyHaojKoxs/PgDTz1eV4ji10lCZNXlyRRlm NFCpkomx+URgv/yxHiAACyAAInvIO+ygyQzEzayUcxzVBRsBJkAA7NzOTXbNSTd9HQWskuADz4eo 4ty54XzFNUnOGqe06PxCXV3Gw6qqFnCq8Iy+TquMNLsAbxatkBDVgCmqLFixHFCxFeuklCC8iHQA YTv/oXx8oc9gtQHdVkInABKQUC7aUU6nAOsGAGDKjptyt/L6sz+s0UWZlGIt2oh6AJ1nDZsswcEX z3mqwU8CkXi5l9nyp9HQsBxg09cKATYNk/uGxSinrLkMspIpDCzcVEHtmP4XmZ3JAwlZkJMJUUzt usLpA0J8okm5mz2qnit5AuJFACdwrW9dlNLXQOvGU9rs1Y+A2xlQ2lhM1uLsZMs338u3tOnF1gaw zmYM1w5g1T5AsWf8mzl9AKt0zyOqkVlLW+f0AYAt2Dt4SFUZCQ3rRsPa2xjqoBYuvie50NwXytSQ hPj2A2oVCdrpnaBd2uDM0R492kZJdaotqwLe2jCL/74y6wOxjYYUSbmVC9a5fdu8/QzKmpk4zaPC XalopAArYNwTwKtkrNyny5xS5J+O2gih+qAzWQE1oJGIWsAI7ILC63W5QcAwrLjj/NDrJn07ld6R wOOE5N5G7KBljcXy3VF0Xud03o0WJwH57daKu6ooQgBVicV1PMEZYMWPjQhVmQEK4GPfVGUvvIOB 7cnlREEuFeFUzgAw/ta97b0nvOmzDMjJidkOXQACMGU3MLeQAHAmDrEdWtYpHs4rzruovcCqzcnw LOO47gOqJ9sSibAJ67gfEAG9LeQ2ndDbq6PC3QIhkN0hgMuZOgCLueSK6eRN9JIDcbEXawON6ghL zP/Rudmk2J2oyqye6ukMYHvaMAsBpD596yYI5a1bUzyiL0hIMvC6Hg2zHeqCGn1yBaBK0zvGY8xz MGQA23zVFGwB4K0A/Q3oVnl4FCCTLsDgh24IFJDgJOBGEhRqQrfPO/jonghnOxZOGaCRi9CwH0CY Mvu0/QrgfLjGO7qHHK59kd2EAGBTQ6sA+8jZmyICPeCdrE7Brj7a/qzv4KybC4k/CcABJI3ruD7E CVCAEOnS70kBEWAANh3kjuuyjP3M/nqSoAiyelihzZ7LRfCYkkkDUNTTwl3kuoztF/ufjcCB4AzD +uwDBXC8D1wN5w7D773uD03q7T4IMrjekkhI2hv/1R0a1R9F8P+ugvajWx1lAGTsunRNASdAAM9w AryYGy0HfEKaARyQkYpQ8aNkAhcA8qj/AjJrTk+ZiTUus6gv8hNPCMJ78uY043TN4hT71ijsjgd1 85QNSoI3Caq+AazOxEF/2rBu2jkLi0jPyUzf9DCr67u+A5JL29miyq1c9aRq0ENMquIL3KvpA04U Ah4XAsSdqQjqAQd6qc6A9iUg3En+9m8PCXKPqI4oqjJL0+IICAcUDAqFhgwJFBUQBwsLBwUFApKR ApOWBUWam5ydnpqDHBkVC4ocFY2PFIIVp6mQBgYSCLQTtre4tBK7spmgjI0HFRQnCgQEhsmGJxQQ /xCoHx8Un5sUGSQnGQYv3N3e3+DdPuPk4Bnn09SDPgfOFguoB/KoFYvO98/1jfUWnhbcFhTcsERQ gIV+1BJq2iBCQ48NH2q4kCcMAgcSwhYd4MARY71njTb0ELEBF64ELmQ4WsmSgsuXMF1SlCdExY6b Nx04KMGz54MHI0agQGGLgoyjPgx5UCCA4oJxCRKwXGABpI8ACmhobRGga4ABAXi08GCphVkPXpmS otB1RdcBcAekUPiJAruKB3y8dPaBhA98HCgkYEAY0ap4jipdmlSEEi1fdDfpTQeKhCjE5Mg5zTwO RYFYu2qZnEALAa9YFlBssiAsVT1ihY7Jlg2idv+zjxB8ICwSNaY1EudixQpH3BtnH8QNoEs46MM9 C+z0zcOND5+8Z7s5/bNwQZKEGwezR/bE8GE0qy5beRwmqGNGl48qbNCwQZkhlKlawp/K/5G8DDXZ hJNOPfmkw4EIKkDBB0c9ZYgA/snTXyNV6RMADWaZFUAKcQXgAVkkQCDAh2jRkBWEehWiFQ1fyTWe P9P5wJEzMylyzwIcHJCIYO04FQkCmBCUiSQIFCABZJENckB2zWUAEn/TSTgVChZIIMssCJiky2kS pNZJM1K+Vox9ypyQwEfDbJLALmzuYo0owQm3TXF0hiPcOeiEJxgnFHDgnDMUvFPPoPZUV911FYj/ p8k/L4R30IsKbdCBCOY5U0ECrE0GE0W+scPOAvORRCZKU+3XH5R5ARiggDkVyJMODyCIoFENLpCA JfFJx5KEKfTqawpevRUXXF0JwMgCI16YVQB2CfDAhSt+NRek2s1j3ZIwFbDIIgtYxFGOEv5Iy2KM NbblkUgy98GSfPo5CmIzEQrvTJ5RcKVopJlmZSxFqtYJa4h1O0wCY5LJDJq6gdLmlW5akwGc2sgp 8cQUS4znxRS0uUsC1TDwJwQWYJpRoYbiEw921GxHbWQMOQSRMz5Q9dRUM/UXc0gj1WcfBS60dCrN jsiTgA+rstpqgbHCKqsO9hqg0q4jSyelBRyk/2DDsFjH9dILPKyCLA8sLnvissEOtTKf0XEADLvm PqbtoDM1Uklp5JbbdpuRZBITn4wwSUI0UscrbzzzUEQlm7VsCZoF6WoHT34gCXbC5JSb2Wc+VFWz ywUnYHPDDSZcgEBMD19s+umop57BS1ZewPkFsnBchAUeP+cAAdANLq88ipycaMoAnU2NpA1VCpIg MQcdt5SOSPUIqCN1UJJJRq1EQUuOOvpSVGeqULTRO7n6wFBCETWBvR8YsPzgUmKqdgW9Yv0SXBS8 gAAAAFAwVgBj8eDBsxfCyrJmgQIFRAAB/hIedGQUqEdpgkjjypsE8yaA0gBJEkLqRAF0UZpMQP/n b9F4yTj6xicQWkp3HyiUvI53AM/oqzSn6Rdd3nEsR9xDRztySQI2gjkm8eJ1rnOdLEb3gA345ohI TCLrABDEz5HgBhtbVAU+ZgGdEOAlEVqebnzgO0WtJjzCI48IivcyS/FOeVEjXCOu9ziRaIAko/Fa KRzRwKGg4AGz6YlOcOK97+WEQK6yI1GIsgrAUaQAjiBUuBD5Pn1wiH4AQMALKDAANr4gfx/i31kC oImuDJAWKIgAAcM4O2EERoOTMI0FgVSQClqwbnbbxAR9UZV8TBFmeiEhKKb4MVtOUQHxINkJKVKP AqBAY7HwzIsEhQobOuNb0LRl5viksWrS4gX/QWABCzYAghFswAC12QABugmCDYygNkXsJjfPyc1t boAFMADBuVp3pXRAx0/uIMAOFHC7K2ZPe1LT5Seo9gHZkbIIxOuByz4Gt0D5Z3fy0EswGOFGEUiP eqlwSWoEeUfZ6HGPfPTjH5FWAkHaAgV28VMzMeU8p5RiI2rLB0V6RQEAvAAew9iW/SiAFv59iCuR 6FVXCDgUVSbwbAA7JScwuMHQrPKpk4AgJiD1Ty5qBEzscomMenmPb71iUDWQKTGXdDhedOmokXmH wBpxD7hNxxGKooAqn1qaBCDAANl0ABBGAAQgwGAEROjrMWDwExhkYAQEgAEB+AqDv2ZAmyPg/8AI 5PpUNlFmQX+iwA6QUYgd6KSfx3jHKdQIAcoMtB1KDWPLGrJQrjqjFKtYniDORBEIiEShY9SZIeRI gaUhCI/H4AlI+yjSAYWPJw941YEMwbTzkEIqDdQeD4e5j3bU9KYQUNALFADbrhQAAsGyVAHgggIE KoARdjxoUk3bGILMU2MRxOC4pkpKG7Wnb30axnkMxREF5OUuEPVPaTVBJeF4aWUWuJ5b4zaoUnix CHLlnl0RIOFbISAID8gBYYFwWBYcIMNAIAALAPuAv5bAv930K1+1yQIQwIACFeTeKncDnXto1hic VcYO+jTaeLFtoAe5XmrPtloNuOwvJbPIU/80GuTDBFM+PVBo9HRbiOtRQAG+PRBwCSDcm3yvuIAs gZbFnKBC1PgZzvQWNGMq1ocKQpLwuPJLfqUtR/igzgsY7wDseKxQIpCU60Wle/UlAQAgrpWuZGXj 6HLEeMiob644c8k4kqg+KS9grdkNSg1gtjAeJFe7czCjo/vPBFMgm0U8wAbeWQ8igIADRAgPC8KT AQUAgQirBsIDtHkCEJQABJR9Kntt9Iwb43g2x8jvvAacMtQqqFvsfVFCjeyyWiZ5zW0lrQWijNs3 UvnZV86yAoDbZS9/+Qd+TG5PdDACMi93t8JM8gkJ9zhmb61+FZjkI+ucgEiQIs97NqAE7Cj/yj97 2pTRxqAl6IroV8ZyPKGAZlhphGSY6CXeXW0FB7iLRuUxW5YUWDSCSw3Gg0JYFCzIJggykMIKuKAG YV3SX3QTIt08LIUgAOc7s3GOwPwz2rmzlLHJtAPafvXH/oiQqT8u7UlRitoiCbq8IRqmJXHbyFOm HgUmwFFbbLncRUO3EB6Qbgeou6QoKJ8dbyH1qStSQoVLMJyze2UILGCScclbiBDZ7z2LkoAWRCu1 Ao1KhSO6IKuk7+B9SZ1nqJnSbTeUxhWQPCnF3ROCN7nm65KAcwQhCLWRiJ9qUIHa0C43VENFeCrg auXkXDnnAPYy4SH0BOxTx7H96jQT8o6D/1hEQQ9OSEJZO5+HCMrtUlsJKbYd5fk4ZIwXvcXWTzqU WwC33XskO9nHLvbta/8mD3DAHZNrUq6bzxbMlPzbXSqMzF2Xji/49+jg8t0KfBcCeSNvwREoSPUi 3BNMdXiD5nAiN0N3wWC+ZFX6kH7VoRFPUXkr0X7Bt3kUyByCMScvkAC1YXrhkUJLEmkVoBsg8AIW kwgIhlORY3s4kQg5onx2N4Gr0SPywBrRFiljJGUP4RDGJzDUsWD5wS3MF2X08UZZNxrmd37XVwI6 MT5p5z3bNxTbpwIPgBNMmHZdx3UmkX7sszxB84KgEEmTBGF3dz+UVH9PEQnwAHB7ll4USP94SyUk EjRoToUJBZhW2aOAM3GAFKGF81YPE+KFFRiI1CJC3JAZe+iBqbckqgcOL6FAKEgjO7JDHBCBQDh7 cFUVCUYtDPF0zaeDq8ZM68cffmgBtyWEbjQSokImWKYDhXB9/LSEBzICNwErNRGLI6ADOzCF7LY0 q8iKZDI7OKVGXJgruwdhLlEN8zMAeNZviXRncPFI07J5bvhAdAUk70WHgshFcaMbVQWKPpgfxAiD gjiOnpBDLxFTfxENPSIdvmFQnvaIj2d38YFm4qgdvidQ0pZb1JaDD/GJiUQPlmctcFWKCuVG9JFb 44FHI6AJSvgAmyCLDlkEZOcJU1gEC4n/VP84jIkkj/WoCfRnZwWQAog0DnrGIdEojf+3VBZUTYeW N21IddxYg4uSkS5FiRxJjjgZRr4hW3pBjglGeyfUVmgWKBg5g0QGdfvIbau2AZ+mO4RCFavGbVJp ZM5HH+MRFJxwkZoAkZsQkZ2glQqkYE7ZYERJLfQXCc/oks/oIhU4jYYHQ3QTVXWoQHqoJ+Pxk2NJ lh2Zk3xpgXEjk20oloMjap7mQEdJldSmg/24AbPTlE8JRksZlQqFmFT5ImD5CZeJkz+ZRs1kmCvD ls9YBC4yLCepeW4pgHQ4l+pll0h1PZxJIXvZl7KpDnZxjLJJcp45m+QRmbzJmP7wT8LXIZurppuC iJux6QmhmZxyERelaZopKUuz5JLEuZokJ4iBAAA7 --------------Boundary-00=_LTLX6OVK850HN0X1VA40-- From then@chgaming.com Tue Jan 16 04:38:23 2007 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6klr-0004df-H2 for ips-archive@lists.ietf.org; Tue, 16 Jan 2007 04:38:23 -0500 Received: from 125-24-166-231.adsl.totbb.net ([125.24.166.231]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1H6klp-0000z3-QG for ips-archive@lists.ietf.org; Tue, 16 Jan 2007 04:38:23 -0500 Received: from [119.170.43.195] (port=1243 helo=fyNRWCTCJF) by dYugxWXZjiIugB with asmtp id uRYnIY-juKNHw-89 for ips-archive@lists.ietf.org; Tue, 16 Jan 2007 16:38:37 +0700 From: "Help" To: ips-archive@lists.ietf.org Subject: Disabling Dynamic IIS Date: Tue, 16 Jan 2007 16:38:21 +0700 Message-ID: <000601c73952$100960a0$e7a6187d@E17> MIME-Version: 1.0 Content-Type: text/plain; charset="windows-874" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 4.0 (++++) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 The site you, are trying to view does not. Site, you are trying to view does. Please try this again, later if still experience problem. Being upgraded and configured. Iis help, access click start then run open? Web feel received message error, see disabling, dynamic iis. Company: CHINA BIOLIFE ENTERP (Other OTC:CBFE.PK) Symbol: CBFE Price: $1.39 Target: $4 Market: Bullish And configured, please try this again later. Currently have default page it, may be in. Process of being upgraded and configured. The site, you are trying. In process of being upgraded? If still experience, problem contacting! Message error see disabling dynamic, iis? Configured please try this, again. Manager appears from menu topics. Of being upgraded and configured please. Text box type inetmgr manager appears? If still experience, problem contacting. Have default page it. The site you are. From johnoedh@fgsw.com Tue Jan 16 12:49:13 2007 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6sQr-0004Kx-R1 for ips-archive@lists.ietf.org; Tue, 16 Jan 2007 12:49:13 -0500 Received: from adsl-dyn78.91-127-113.t-com.sk ([91.127.113.78]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H6sQj-0007qN-JJ for ips-archive@lists.ietf.org; Tue, 16 Jan 2007 12:49:13 -0500 Reply-To: "Georgia Bloom" From: "Georgia" Message-ID: <1508170429.886538036583@fgsw.com> Date: Tue, 16 Jan 2007 12:40:43 -0500 To: Subject: News of the day Tue, 16 Jan 2007 12:40:43 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Spam-Score: 4.4 (++++) X-Scan-Signature: 08e48e05374109708c00c6208b534009 hi (download), start playing most fair casino you don't know internet if don't know this casino US players are welcome http://mi0zoombin.org From cfillman@johnbrandico.com Tue Jan 16 14:47:47 2007 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6uHb-0003Mz-Ji; Tue, 16 Jan 2007 14:47:47 -0500 Received: from agrenoble-152-1-94-108.w86-200.abo.wanadoo.fr ([86.200.201.108] helo=nom-8hp5hiz6ecy) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6uHJ-0002oP-NA; Tue, 16 Jan 2007 14:47:47 -0500 Received: from 64.202.166.12 (HELO smtp.secureserver.net) by lists.ietf.org with esmtp (O34 From: "Eddie Horner" To: Subject: OEM software Date: Tue, 16 Jan 2007 19:47:28 -0060 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_000F_01C739AF.891010E0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1506 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 X-Spam-Score: 1.6 (+) X-Scan-Signature: bd8a74b81c71f965ca7918b90d1c49c0 This is a multi-part message in MIME format. ------=_NextPart_000_000F_01C739AF.891010E0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0010_01C739AF.891010E0" ------=_NextPart_001_0010_01C739AF.891010E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dreaming time has reversed=97and you,The road, but not far enough aheadPall= adio who beckons from the other shore,To mark that square, perhaps: were M&= #232;re and PèreBut when, on the timepieces that we callHe is harsh, d= ismal, ice=97that is, exiled;Reshaping magnified, each risen flakeAnd off t= he white smoke swimsBy trees=97or might see as the masonryOf tree-dividing = sky finally comes down toThe purest form is always the onefor a few weeks, = statistics won't seemAt San Biagio, in the most intense roomAt four, the sp= ectators leave in pairs, offChoces, Mère and Père, undreaming eve= n of fieldsTwo of us, Docteur and Madame Machin, who standXI. Franklin's La= st VoyageBy trees=97or might see as the masonryHe is harsh, dismal, ice=97t= hat is, exiled; ------=_NextPart_001_0010_01C739AF.891010E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
3D""
Dreaming time has reversed=97and you,
The road, but not far enough = ahead
Palladio who beckons from the other shore,
To mark that square,= perhaps: were Mère and Père
But when, on the timepieces that = we call
He is harsh, dismal, ice=97that is, exiled;
Reshaping magnifi= ed, each risen flake
And off the white smoke swims
By trees=97or migh= t see as the masonry
Of tree-dividing sky finally comes down to
The p= urest form is always the one
for a few weeks, statistics won't seem
A= t San Biagio, in the most intense room
At four, the spectators leave in = pairs, off
Choces, Mère and Père, undreaming even of fieldsTwo of us, Docteur and Madame Machin, who stand
XI. Franklin's Last Voy= age
By trees=97or might see as the masonry
He is harsh, dismal, ice= =97that is, exiled;
------=_NextPart_001_0010_01C739AF.891010E0-- ------=_NextPart_000_000F_01C739AF.891010E0 Content-Type: image/gif; name="kzspajdz.gif" Content-ID: <006901c739a7$274ba8e0$6c822ecf@5FFFF840> Content-Transfer-Encoding: base64 R0lGODlhtQGsAbMAAP///wAAAAQE/B9hqmGw5Orq2729u8/PzvfwYvvQCGBUI7OZbPqCBvv7+wQE BAAAACwAAAAAtQGsAQAE/hDISau9OOvNu/9gKI5kaZ5oqq5s675wLM90bd94ru987//AoHBILBqP yKRyyWw6n9CodEqtWq/YrHbL7Xq/4LB4TC6bz+i0es1uu9/wuHxOr9vv+Lx+z+/7/4CBgoOEhWoB iBmIARWJTouMEpEdkIuKlgCQkpMylRien5oUlaQapKchnDyOXKwkqh6ijZgTrkqgtqGnuZ64sC27 qqgWw5vBpsG0lL85uVjOH9AbsqPKUbbStdbUmZzZMNjerNvj35nTzCPmhOuX6tbG6Uzh6OnKru0r zuWz/dXoAFXkCzSQmDx39OhVI9dNHLx4+6gl46Yt4ERH4R6CQnYB4y9+/gbdBeTgsdzGhrwYYSoJ K9FKhxopdlSJTyZEXZE8hpx58mTFhMJg3ttYTFuphbIuRjxoSekmpOR8Rsv5cVJERcti0RRVrChK nUeNvhTLzStPWmZ3GRyWEifasD+DdvPX0KjdhXeN4dXL9+k/kSNr0n1r1eQ7v4Orhsq6zDDivkOD Ou7rN3Leh3sv13SYmatcjp0VCns8t+7f0nkht6QqueLpmYxRyy7NcLbpqa4Tw95JcmJmxIJnFV4r PLfrtrYxk045PHHrx982Fz/eXDTTz84Bn1a4uLdx66DpxraN+irveseMAxe3O7li0rSlme+uHr5u 3sG1z49P3V907K/B/kUeSPW9Blh+lcnjm1bi5bZfge2N5KBQYSF333Y+LUgfRAKSVSCB5iD4HVX9 /fVfg8tV+N5s2axDIIskXpKedyiWtyKEEYY3IVQqnrejeF0lo+NXAqplX3AhsncePy/yN+SDHg7Y HI636TKifwoeJOGHUxpI3oZD2uilj1LWt5ROInCHDIg3oqnjfkx26aR2ZYI2n5o5LqlkiWCCAM2d N9rXZ58vJkmmmDXy6SeAhMqZ4pcBtjlckyVdSNltyEWl3n/2IGjdZ/CcSCeeFo4XZqEWMgfkavBV mmiKrLa656U2rfocdOds2uVbxFFmmWqzQiqWcAByJx2wW/ZaJaal/tLo7I+aBYtSapkey+x1yv46 bbSSaQljYcWKuJlEVUllJFmk1kqkucGOG5W66yaVllnCriWkrFGui6JLGcYaL7HKccmuV6Wo2hth FFkLI8CJSsXhWf4Oix5m4nZbbpIz3uTWoDLe6x5SUJHJksgUQmxqvsTq6iaVKaNsyMtIFLSGzDDX LAXNaeBs887zeOuGzjwHHbPPMwcs9NFPAD2G0Ug37fTTUEct9dRUV2311VhnrfXWXHft9ddghy12 0kSDU7YJSo+t9itnu5A2g2vHbcPbaLfNttx4z0B3CXsnm/ff76z8lZf+jmygwxrbKyjgjB8MV5DT 7fg4hat1mHHj/pjXI/G1sDoH7oSfU2stvJlnrumyY9WSK3TGshZ5qhmVLvuggicY15X3QWkpy7Mz bt7vk+5aeIwNy5tn76UD3x6/txNeXaDn6o485srjR1PzZj4fofFH2j192NXrFue+2ltv/qHfNx47 6visLon7+CZ4a6nrpy87wtFGfunH64UOLGfxsF/vCkY5Ze0PdjyqXJF64T0Bfs0zDOuIBEmmsj/x CmT1cqAGN8jBDnrwgyAMoQhHSMISmvCEKEyhClfIwha68IUwjKEMZ0jDGtrwhjjMoQ53yMMe+vCH QAyiEEHQACI24IhHlAASiziBJZIgiRxgYhSl2IEiShGKFHDi/hDBgMUKIHEESwxjBrD4RQ2IMYtd 9CISC9CAArjxjW88wAEKMEc3hjGJdzyjEr+YRjT2cYssKCMYqWhEP/5RkGTMYyIVeUc2wtGNcoyk ASZJyUpa8pKYNEAdxchHRhISA1YEwCcBGYNRokCQezQlIy0QSlGusY2PlGQmM7mAWdqSlgRYQC4X wEteatKOnlSkKEHJSlLK4I8zuKMrXwnHSB5Ak7e0ZC2jSc1qUnKalZwmAQyQy11Oco5MDKYyo2jM QFqRip38ZB8bCcs40tGZtDTANLFpzXpekp72zCc+cylPStYRjuPEoxYvYMpymmCRS3xkHGWpz3w6 9KEQjag9/iP5xlWCsqAGNSIdIVlNfEr0oyANqUir+UxnsvGcrmQlRjP6gTZqUo79HKlMZ0rTmt6y pL/kZBNRyVIwvhOm2/SoTYeKyWcS9ai2xCk4z3nFlfZ0Ay6VJC/5WUuhOvOqWMXpN7N6SaOK1Kvf hKYlwXrUqsqzl2hNq1lnaVSThnKgT/UpTJ85T27q0p8mVeg/54jVjdYxq0pValjDKtikvrSSkmzr SM2q1sY61peQ9WhbJwvOJsb1BAWA5jMHMNV+SlahoA2tHZuZ2JKaFp4w1axmuWrPup71sb1kwAIY QNva2ra2Cbitbne729n2MpOlhSIyLxvF1S6Aswo4ri6x/nlV0Tbzp+4k7VwJq9rJSrSqsO0lAni5 3e4uIAHf7SV4xxveBIxXtrlNLwPUq9710ja37pWtfNEKXLe2krhEzKxis8nZz0YXknp1LmrFakvG LmC7jSVvbmfLXvM6+MEPfq+E3Zte81L4whiWcHtxy9sO19aXiG2uU/Gr0ulmcptsbS5ff2rSvaY2 no5FsIy7mwAEgHe75i2vjtF74Qavt8IUhq+F2RvfCsPXthsm8oR5u1atmpaNJA5BZlVLTcDy9aoE yLKWt4lgHhPZyBAOc4R//OMIiznMZe4xkIec5h4HOb5k3jCcO3xkJiNgqyI+5HCf2gCtVlmOFfUk N7cs/k8bG/rAOnawmiEc5zOfOc5B9vGQ19xeNivZzW4+spCX7OEPg/iwJk2lRYl7xMImtbkVPeka B71lHEfa0WZ+9aTLzGhK1zrWs27wlxfN4TkXecJ1rnOnZ4vY1TJ1mSM2aKkPa1hA/3O0CT3ilrWM Y1xbWtZmBjOsa93oIit60kBWM6bJ7O1f8zbYnNbtbwGramRHOYtiJWtRKQpMRrJaywfWNri3/WhH NxrNlg54t7m9awtDGtgaNnenO2yAO1fXjSld5ruVaNqbvpTeqWbmvbNcbX1nO9e29ji40/xxbUOa zSfPtKbJvenbonvhtvXtNOcaSZ5GnNR9NvGp/5px/lVLe9oEsDHASb5vf/Mb4N/W9ZuzPfBrCxnl GL70nIUNc16e9qWj3LOyac7Wi2O8jezcOAHOW/SSH/3otE460glOaZaffOUop3qSYd7bO9Mc0OpM 9haXLe/6ArrnYD+p2IVu9MLbOu1mJ/rSnc50kGf64OaWOt2HvQCuL3WYN79sqSt+U2fTG+xhHDzi RX72s4++9AFv+8iv/ebIc1jOk7+t1e9+AOFmPq5FNHU21Ypgmf/2iCcFOgEYIPTTl93wqE/9mv+d dMU7fenv3bWvMxz7mK8W76Imce7hec/H0na2CmBAcn1+AKATPvn8Nr7H067+Lxs55QLftPx/Lfnq /sseAafFux41n/MC/7bQB/Bpz0Rb5Ad044V+CNhv7Xdrhkdy8IdpK7dwVBd73JVncIV7AHBVmKRd 13RWF3dWtYdE5Tdt5ydmC5iApcd8zfd+Ied8PuZ2UjeBsRd+tdRXF4iB+kVgu+dLAXhnxPZGBkCA wEdH5od2KNhvLKh2DHh67Pd8LVdpcOdrMmh/8nVlf2dzfJaBOreDDudw8rRXsuVIpWaA33WEZoiA iPdv0PdxDqhpcpduVCh7Xqd/egdIbeRn0oRWPhiAC1AA2GV1YjiCrXaGhIiCo9eEivaASgd5rheH 1meBdThEUaWDu+eBPhhb38cAgSaIWlaIaOiJ/moIZovXhnAWgVPoiDHXh4l1gz0FfFvYfVUFU1M2 SbUEZY5UhJ6Yi7mIiDAYaW6XcKjIZDaodeV0h8y2gYxFi20VaENogLr4jGtHa03Xhi0Yd5wmbC2H irN3VcRYjDnof5D1TFlWfv8URgWAi9CYjsmngtBHf70mZ6foiJXHjd1ISsb4YpfEWZW0TVdGALXn c21kgCWojukojWXHa0UHgQoXjEw2h1jYiu90jDtIX4M2ggAJds5IkBppekPHegrpcgg3ffY3W1hV j3t3j31Hi8nVS/zIidH2c4O4kTJJdKJocmo3dePGkB02j85kknZIZRtIAMnVX5cEfOaYkTKZ/pRK 2ISKKI27VWk6eVsl6ZNAZEV0BJSWlFyT5HAUFYLmCJPUppRiyYY1uXw4GYPvqJNzCGXa12cSeVOp Bm0+h5RjWZApmGviBntzh2QMaXcr9m5RlZL8pUt+JYZf2WfTVmN1qZE0+XZNWYrU93JwSIFex5ba x3mYRAAOoACcyZkE4Eb+ZJSqho6LmZRM6ITuiHDZGJWypYo1h19MFJGCqQAD8E25pAAE0AAGwFle aZSIuWWlWZqhqHRQWX85qY1+VXuw6Uq6509a+Ux0tAAKkFmVd5FgmWXBOZPR+G0KGYEJ94YMyZMb tZybh4+WpI/wNAB0pZ4nVYDAmZ1KaZBQ/sidUPiR8KiNPAlogDlYtISbL5VZCkCLmqRInBh08Bmc 7Pd6rQeMqxmPsfdOdESVQbR5b+mcAQpNxxWA22SYoHeO73mgpomXLJhhUAeeIOmIItaWDAVcA6AA m+miBqCbz8RIHhqWIKqO8mmTKveE35mWfGl/XVkAgLlfXSdP/niV8sShS5SYNxqfI4qaIWmiPxqH v4R9l/mK1/SiyPVLRnqYARmTTWqXTFlwjweZxXmiDnpbF2dHUdZ/gjlJtzkAL3pNSopE96aYYUqQ vuh+0peadMaQVXp5GChKmAlc0BSgx0VJNMqkeaqLzCdrvfh011imsCeSu1WZy0mo5nlJ/ptZmxl6 VrwJemFEggO5bYbWqLCWhgZ3eJc2f3RXqZ1WpWwaZVwHXLzkop2qSbUkqoH3m9iJqoX4antqlo/X oMUajF4noT4kRSt6aoh6oX3Iq3baaqXqaKcKrMgnrKtnqbAKkpK5cIEqpO92dZnUorXJTXKknrq0 VHfEiShYrWF6iNYWbmSKbmQ6pZPXcH8HmBFZYMi1mXxYfrzkm6DHiQgAr9i6jsQ5ZiLaa8AImQqq Ww4aqJG4RbXan/74YlMlrWPYiQibsIZIn8/HoGa6ZHpZfXlVsVUJAP06S53KmQYQoXM0oIpUowYK skf4dvtGiqt6llHns5PJWxSrskF0/rGXFKDiqAB8FVX1JprA+bE4u22IeJMeGWwyaK/ByI1tyrLN mpVbFaAZ95LAR61RC43y6Zgk2p1oiq9Ce2XKGkQ5KJgo9kxI60hiqGqj6bGlV4JQm505+qRnSqk+ +rDe2WlXdlLvJpuzJJ20SUmBhrd3BKbvWrbHt3zz56pQKYVxmJ8h2KZxO0u0uQCbeaQAxbFgiaf8 dn7XiroOJnR9W5fD2bA9652uupAL15VEW5VXuamU5ACTFKBgC04+x6EAQLapC2uvi61OibmT+rNs a7tS+VNvC0T9mpIXGqCh2p512rFBB7WuW2OGdq2nOr7mlbwbyY6qN3AQW7JBu5O4/pu7PySjvHtN QtmiAxqhYotET1u+pvpg3zuQhBfAfmuCSOe8gqu5D3u7FDW9y6q4XSed1Sm8ppt71HawyIun5Pu9 iqnBqGu+IfqkD/ijUQiHp0iS0guYbjm/ePV5HHqRgphvrAthHLzBGOy/NNzBIHqa1lifWOuwT+lh boXCWClN/CRH7QRM21ujB2vBYua64WvB4lu+UFzDODyWKqij98qX32qcvXW4DNxDfEeJ10SboXuu vSqtjjQAWQbDpcrEqkvDHEy+VZzDZNmnaFm7z7tbnge/y5pzKpyljKu0sPRK5qhLXHbDrSvF4DvF UQy+cBzHMeykCbmCrYfHUlp1/kHcpm4pxpcklDA1AE0LkMGnxkvcxI68uuF7w1AsxzMcyXpKwLfm vMY6wia7kwzgxUKMpVQGtgYgyEj8leeoxrXEuhn8xKXMyKmMzDXswWc4pivoflGKk3nsYa4pqJdZ oWO1m7TpAKDcngS7RNw0AMcsw6f8v4ysyKsMx1XMzNr5s3ecwKvZYc6GuOSpy7SInmdVUSF4kWy0 m7nExMu8xMZszOW8yKeszq5sxZaLa2n7rZbqw7SFfz05cSn8ptK5mQ7Qh9BGyK80gpWHygY9vk+8 wQSdzAjNzo5qdD3KtrTcvOp2yxDKxz+UWm/6ydU5yKK8RuWnj2F2zAK9yj89/tICfdByjMiLecWM 14skPM0xB6GWSavYLMbs+Y/fLKoefc5CXc5D7dMiTdJznMgJ/crxp2TGutIPLXucS9FayMnfhKta GaFJvEYeWnnEHNR2HdKLbNfpPM6rC7tLSZ8kW7gSyGTQJdM5REX2LE+1uVkafcbW+aUHZs55ndc/ TdROLNKpDNb8i9LNPMkviMAG3L6yJdFWOq72LJRhpbRy6aWQbQCPrNewHduVzdUmrdnaGcusF7iT 2a2yh8tbm9i9PI+9HLP1ltP6m0sHENCyPdt3HdSILMB97aTq585aXN3n1lvV/NQkxn0nFrq0+WyQ m0cHwJuYvdzmvdWWXdSc/t3Zlou21CfaC5ef2o1fNH1L0rnYg/zNADmCyQ3U5+3Gzj3QB63KAnzU Kn25ETu4D31gmey5Ua1JnqmrSzvBS1R+SuvElP3TvCRftfXf5m3b0i2iuf28Vxvfvu25hXpPnOkA o7tJLeybAttw/m3XsyV+LvffIT3F38WZIP7BZ0uv7miK131/PWnYPHSPtzS33r29vOqH6jnQNM6Z 3xdbDC5JBSDQCmBjySV0O54ACuDl0gnmy3zbP27HrNmaDa59n1tULeqZqqgAfSaah+mhMg7lP/19 db5eB0aLqI3ltxpeO44AyZVcOYbOfu3Z7LuX0CuMFDVxorS7tjSUnDnV/lTN2kfUy90r21dOgwd7 AAfLXdtErZ/+5YxrY2FehqTOvwOss5Xs0lRY5UZs5DzkwMVmAL67mwcAtszETmPLZUF95T8dhFsO 7HiOroMm0OJ1sFn+6d0l6OO13jmbqtypcNg45EyW3Y6O5PN2vblO3JXeoe1am3oN7Ahw5Rte58kd 2WFVS+dd6p3JmdEN7ainYSC8l7Ocr6G2tSgZTZOeU+G9632mS79u10E42uReYzUojpm+xIEc2YKe 5aLr0zYsyZQ87bztYTII68pJ0fLLVo27m/d7t/k7hnV+5eRu8uW+XRENvsQ2aId1sCb/7pwZ2Q4w 6kHNuAjvol8u70go/n8jGpm1fKLUXJmyrkN3iIde28sAG7YEO7ziPvBBHX4c7nt39U0pv11bruwQ P/M67+U5z+MQ/PBhnYCqqnqBG89p+mF+2bmanMJsZa4OEID+fsbslFlBh/LknvJupPIy112eHtkO n/IZjeyd+aIuequDXoYPb/OM6XhkDdFp31vGVvSHLb8WjbTHZbfWKcrcJNDAjvedzuw0vkvcZfNX n+sH5rtY7+mknuXgu+Jd384K2KpCf9Zqn+aw2X8ev9iOu9rezEz/jPJXv8QoX751jmg69l3lLp1R f6tar/XwXr7Rr+p2Cdhmvr7WLvlFTtG7O5u/u5nE/fu8PoYwX/56/q/3V77IdS5jOx7ZnOnpSxzc CDD4Xq7s4LXsNQbvAI2A1Rp+bCeyEMCSZLTOW/XmfSHjEJsGME80VVe2dV84lme6tm88P0kxNH4g kKBYOA6DRaHQOJAay6XTuTwQEAXENYvlahGSzyELyhoQC/RCjHB0z0SEIrtQmBWKhONzzt/viIRA wUHCQsM4PEOMr8CvhQ0Miw7JSY8QkaYSnU3OTs9P0NBQnssgU4MBBYKChQElqCcpWKmDD7cu3IKE La+5MbokEL0xxKzhv7iPO4c/OiLFXWjpQAUGxglsBryKO25tiuyMyEpyhjBMElH1dfZ293cUpoOf +VMDYKAD2Cip/v7YAgJmuGDRoqTgFzEEzdxD84bYnSQGkMXJkkBOnF18FkwTlIijIECBnHXU9qUa nm3mJqSE1GFcuQ0LfIzQBM/mTZw5bTIpZW9eKz8hkuzrN+uJzFsHX/EZ6OsMGoh7CihgBnHMRWJX M0YDaUgOV45+dlXbJSlRNQqJNGSLhOElzJiXaOqkW9fu3RhOetQLwpdhQAMFBuiLVdhfFCsFcxlU MiHrLzoJ6Dwl1vBx1rF3GgEKSahztKcbLdJhpuwkym3RTkr+tpEsWXAZ4MI9Nxfvbdy5b/KY5/eU Awep1BAuzI9f8XtLlV7hAsbXHjSS94zBkvByRc4UQ35u1JGa/qCqZ58NE/2HbCAKjzA8w6ae0riX b8nJxJRJ9338+TvJ82Hvnqt5kHiCqMP6+QEX5l5RUDJsJMtijYUEUsKPO9a4bg4HKssIETkoHK2I jojQzKJESBPRI4skkIOOCyJbK7YXY5xNg+EwAaAm/XLUcUcV+PMtHzp6k4iwTIqThQQqgmFMsYMY 3OiMg5h7iIgiptPwA4tKI5EZRKKDA5AOE0FkNGpQIyLDakSrwDVqvtEAtnDim9EDBHo7gEc889SR px78Q0WNH1wh0DjDkBxKKQUT9ULBRRNMBotmkkGkKg6dyeJM0SwNxAESuRJRTbFIHOk7ZR7x5pnY 4pRtTg7o/hMhCj1jlRUnHE3Yy88f/NBDnyiM8ucfCZkcKNEll4xS0jecOfGKZjK0yA4KL6LqLGBC rJZEbcosBlvY8NhIHAnCYZW2+uyb9Vx02ylBHiH9WyCggJpo4rh/jnTi0GGJlbKpfJUiYkI5uMTo KqjiAE4sDhuhig0S53hNgjEP1izcBg0JF0a2MF51RnperTVdkEPu5FY/KaRvQF+R/DUwYYlllF9E tSjtD4kcfkgZh7DkLLJdInsmWtdEY5C1zigeJNUL0FOaknEnqVEEkaOWOocnesKVAKB4VdnX45Zg mTGwFV1q2CgJopDgMzLEUDJnh4HStGgtYnC1j6AxWum2/jKWRL45zeitgKkDF9wFTUj2qT5UlBiw QHvlATtBYhtANJeD/tXCALWBsXkyDs0rrUvQtqvb4qPZcgs9pJnmu5yOCRv8ddhNeMLwUxRAItfA Bv11CoLy1df3fpVyG+3O8QAzoxFHV16au5c+HcaWmq6gdVhjt17qqtt1dxkFlMiEa5Vl0UexsMV2 FGaz8Y3sKqvG2Ay77pavu/mM60d6dVbpCaH66/tPd/b+nCJAtsNEFIgTPsYVC3gKfFzveoGVC2GG M/KjIOkqJoj7WaAtq8JfB0BQwBv5T4R6qkn2Alg7OgDhFY0Ln3HG5rLyxXBfyyFIBLPTnYpUUIcX s1/9/twivQ7IRR8hHGER97SDAmjPHqqQCCq0NouUyYJfLxybFp7ApF7U0IZbAYsOvUgIioXxh3qT UdM6ZgAnGFGN+SlhAWbip1Q4sQ6Lo5e9ekW5l0HOZTN0oBYfs6HNgOaLywNH6XqoQegBkQHUS8ca HYkfAP4oCM6oSu7q1bVfVXEJ5CtW2XjhBurY0H2iG2QFC8nDvaFyYx2cxBkb+UhY4oYEVrMHYFRI hUyyUIGQ4yMMl3Os63ARftwppSLohzcxauw9QCyFuWL5TLtE0j/zWMbt9rc1BBYFZcI6nyaJgaBe RHAr8OMKMYtpTNM1SGNjVOQG7EQcaMaTLkmkpSmS/liLVNiue4Rq4WH4SD5OOuqXfgym6CZIynOO Lpl6Qx0ZpSfEV8pTovC4p5/28qq91KtQU+BoJ/PIwFA26puinGD8EvoRHqZTmahziRlL8bGJxlQU s1SiKQawvyemrFeN+6RyWmYQTzaKoNhxnyBPilJDLhSRiBTXQzMKU5lGlROkkCQQ0NBMKG40l8Yi WwOlFLNwXih0gzDnUS+IzooxdalMm5GraAJVqcY1L/GoaFXvcde9gM8w9FJOU2jY12MNtaBjNalZ SZfBhl6MAxtUZOvSKFfIUs1HPjEAAUTwLpnQ0UjZvKNH8QhMv36yoKMMpGG9qEp1/rCdDMBECB4b /lnY0oCquGoFZi9BoN0RyrMjBScoQypKHHaxrEe9W+qQCR8OsnU2jo1obJ1LuAa80ScysWom5tXP Ok4hiz3lZg07uUViGHW4pk2n6RAbI1aW42lFem57WaCJyfrJVfTgJ1+x+cIZ0nCkvNivWMVL3kIc s7jOW+ZanXqJ17pXwTuI73Sx1go0KmijOy0KULPiwF/yl6REHaZRAYxBi53ykGttKm0WWZ8EL3jB fKoqPmsbGMJgkp+XRBAoa9xfDF9mQwb98DRSddwMRi+95HhnilXc3tn+qB41yqzidMpRKYaVv74V 6oYPetAufviYqUWlqhgLxBq5trlHfi5v7PoD/qy19oC4TWBSvCtaggpWguQcr2GN1mUgM3SxLxoy ByA6ZjLHtgR2wtUP0CAgCWtzs/yQ8m8vI+c5BxLLWe5xgPMs4lQq8hFFBnSgY1vTU7jqnkw4kn21 2WjeWjnSpC1spS/9agNHD4jluhFcPS1Xdp3wFDftgZMnvNe9WugxQ91xeI0tSGLW+aQ/Tushv8w3 1bb1nbW+tYJBnY9SyGQol8ylvVB97M5MOjuTRjZZXQ1ivIH4fuyMtfRobeRqx7UEbuzT4Xrzruvq tp/+EIGqgYvlkp6bI10esAYdKps+08hO/Ih3memta/2VK8K+zm6pSWBDSP+RwwAvt6tTamln/q+y jMqtxCOESO2GC5p2pqhPojiLzc3ObtjfJulYyV1p+q37vOxercL/Bu+US/XhLW55ohWXzQojSdgz 97cE/6tss27540F2aMJp9DT+BR2y0rQoRiOHdDYPqOli5fjNoR51HxLcyzCxujnySkSt45rr9n6V 0Y2U3aMn8dFhLTZ4O0zpHm/5uATe+Wqx3um4x3TolC2ghCmMydxSeezjBEu4BZ5utaPWvLNpOxoW jvjEy3N21xaiPuaV1ZfzdajE/rfTSXn2wKtUXOou8chhMpxr2jr00Jw73V0edshDIYm6aL3GKd+V Vl++h+gGFwbBZftxYR3uu4+p0knfcl6x/lmvUa75xlddVMuf++OWTin0Stx2DwBqBCinvkyjW2+W F93xGoVy44Y/buPnv+OVVz75Q755nkO/mGg53Ws/WOo9AWq8FXo8bdIt7+m779sxyisp2Fs2dAM5 AlsaAxPAVnmadChAA1QjmoK41jG930Og7UMSC9MxogIkCuS//vO/QhoxLjO/nju86QvBZ5q367ut 7Mu7mEu92RGsp7shI/SwCrRAdCq/Gow2kos+D9TBqGqw+FNA4bM/i+MdSEO2I0SoGEQrZlOstcu0 jWGmpwJBKSyi9wO1dxq+FVqc+rOvO+owgOvC+Pm7yxs/GaS9U0olDowJDwS9NFTD2Zom/vmzuxmj sCkQttAJuHHjwuT7wgxMpubLtLf4Q7dDB0EcxBHiDRJsQ5dDut0plBW8oXKyQ0pLQtMSMNljKifE xDX5MzTkxP7hk67zOifbKaIYlF7BBMArp+CyPFVUwjtLu8R6HsaCRUB8KlrkPRa7xR+8wlFkoW0K r/8CxkiUxAvEPCDzQ9XpuVhEsU1sxuvxRKLDxTfcRW7TqOFbg2x8veDSxsPiwzHisg2SE03DvSYg xx18RgHywfmLolG8o35jNXPDxmFcRecpHTxbKvsBx1aRRX48wD6RpHJxQ1+7L27jq/GBx3eUx7Ni yMEzrjJUK8MLxImkyNYyxGgMwmmk/rGCRD5FMKeERLsLYsIfQ7hEgkhzaKZ1SclHIr3Si0aK20it 4o0c+oyazMMLxLQgc8qR+0O32sdZBMqpGbSVZDm5+LqjzC3DML0cAslSEjF6TJpv/DLDO7kctEr/ qRr9SUB0hEOjVMfCwAQvFEswzECGRCzk6iBM9DyPqUq2xB7EYcmWFMiBpAVfzEa8RKoZpMF1gj5N K4WsG8y2dCMSFCKMBEJ17Mx/8MWlVL5ivMlJXLva40kaUUvLNKLC1Ep0DLuXZMfeCE3xAyPmUyey tEEhQ81wfJW1XE3rwUxoNMEFnEt2LArQbEwfG7xm00B2cj4n5M2e7LVxBE6puSe7/rJC3YnNo7M+ d1RO22Qewrs0S5Q11JzK37TOwaHCvsAoorw7o7QjEUgM8GzK5Ru/Shwx6bQEEFLPy7y2d2pJl4w8 8bGssKxPpMLNzIu104TIMKtM/3wdeoK/fNBOzdJIo9jFiqJNLXM23ITOnLzH/QyirQS6CL1O6YJL 4tTFl2RAJLGsH6jPxxTJqSM4k5TM8yTA6jzRWUHACtXOjPTMmBM+KzADBM0zMDJJVVkmZVyuEhVM HsWTdZnQrttMF/XKIITRAwDP5lEqL4WPMSxJ6XQrCI1S7EnR9rTCIY1PRaSCKvhObSzG0exDJXVI PhvRINJRKDXTHfHRH91M+MRS/gbsE5AUI5G0R8LbQBzFU0baUT6V0jVkPCAFn+3sqNkhAPqMwS5N N+a8Uztt0nYiU0d9VB4hhcwsoB/Ermmsr0uFU4GTU/ssP0pUrUvEU5jQzFEl1T6tpx+tu1xcNDa1 VMsKCA7dIdIcSTKi1TIE1YeSCynQ1TO9vtekv4pTVcV50xhlStvUOb3UyQKzVSfVxFyFVkhiz5lQ 031gUeBDIEzNVknMuYU8LzIEV47RUXKNGlv0vVTN0BY9zvkMgS/ENGQ0r1dcVnqFC+ba03u9D1u0 SF8tyqwSUigDiDc90NibR2Vlt0Rt0IP1M2d91oVFF3MNUEBlUWrlnX9ADEwl/gCZJK9NHU17pFO0 7NjlEkeFDVlZWrkSPExSVLR9q8v5tFiP29bEqkSM4TmaZZ2PNVGc3ZN6ULKtzD7NElIXgrkqwFQP u9iF5EY928lFTVqJbNpzaVh7+zqBVFdLpYKVdVeFPNayJDH0Sp2kJYdqONcPvFmxpYtco7sVhVjU +9mtuVq21doZNFTjis65bSufhK+8lRVC873inDFgi9gCBYxitaABS62G0s9oO7jE5QBOS8/GzZGs rMK+LUrjtNR6WdmAsDMMJFqlWlLk2rPPjYkTQwfZwdvRxYmLUlGzXcet8tmrxVShPS3au83M+7+v rd3UtJN42N08KV3TLVmL/qPLk2WCtf1F+ZG6bYRVkrTTJ2Re1iog+NJd6IUHnS1Bx7vCRFRd1GPd 6KAgPSTLZjvanZtd8xRfczgxBDvfWGnNND1d+Gxf940F1jXSQcJP+9Rc5X2+8NXfaRNd/9WNxZve Eww+mONXfjhgA1AewTtetevclfJUZuVNImitJZjgPKlg093XC2VAtA2f4W3dvEwqREXWgQ053RRT /Z3OwJQdFc4RenPYunPh4+xZ4xzeyoK6DwZhghVh/RS5HiYy6gziPRk9SUVXvTLZDJ4C1mVZoVnO s8rNJkyu2XtKfJziNSFACbbiu2DhXj1B4FVE+tsaJfjiA6Xf2zzWMILK/lpN4wee4hP2AYZz4/yo K8iVY7rMUNRbgi+OX1YcOHo0TZLkXB7u4cP7wDY25J14OMPESOClRn2rlxmWCbTa46nbS47N31VW Y/7MvXVhWk62CUSeXqnFLc+8o197ZEAwVENiYG50Ssh0YM915QG8rVGc5WiKrk+c1HXEO7Azki9m 2WD+5W0MSQeuBPmAtpZSYyLoj2odV2XehNGj0J0NyONcZGDzYgIYgHbu4GsWWDwzxmwuh2fLX2Oe L8lNI/Md5xkoxL7QzAuuv1+zo8KYZj5gTmAOz7Kc3aYq4c+lLgSjY3H2ZxwYQSVrvFt+5sktYFpo Z5BWE/9T3lacWemB/ujzlGhLMkqL3o189d0FfLKJ3bddnOEHO95rtpsGLkmUTlyJHoG/BZx+bukX oKqMnlZ1dlGK/geQducPiF3w9aFYRVxj7rlvVqGUvVCifody/uTI+VtgHWApwFR3dmd4/uBUbsLn rOeqDtW+iOmt2Wp44AmIu8gnOuJGVlVsqix3HoIOpjqz3Nx5Dmzb6+mIVmnh+1UlkGuuBtDb+uqZ juw23SvBaOe+HhrD7Vaqo1Vlbet2uuoDgSEoYGx3yDXfsGuI1WulTtsnaGqsPZrkleeRnFfPvsG3 jpzrIm12oGsiJspKDet9dgKytmw0SJrSjMzORiajre2muapbEm3A/tHtdWCXo+7bLsZrDOU2yw7p s17rmBXRzm435o6+23aZJ5BudhASvyBZyB7lK3Xv1nbtv/5utfJQuA3k8a4E0M4dK10h9FYHnV04 F+bi1cZlvbBsd66DSQRsgx3h5c3vDixv4tSa/xaFx7VldDZZGFbtqinrAXBnYebWOo3bHYZw2giC dnyFH6xwC1+5i8zw66ZjDY8FVPhwkL4GYk4kpH1o/DZxp1FpXllRCmfxT8BMIvYeRc7uGX/mKvBw JPiCBR3xbK49w67db6YuVE3xJNpkIs8L6T3Xh+Vo1Q1UyOMBBG9nSH7OjK3nZEwuH6cNINdy4hxq IndLc35xxRbz/lyGw31o6g+XCXHYZjef8je/QW2jHhMM8i73hOypbhgK1lA+2Q3+8LJmDz9c0ht9 Qqou9PR7a9QeokWfKk/23Y2uIy7OataGgiOgdBsnWBJHS/y1Z06fj0PXTNMzQTon8iE+7a28YGmM 4SX/SgS3cW8t2jKK9UnY9FlfE+qaSuyDmlAnZ3piSeqd7A0nc4068w8/g0A34xy/5GVvKzQADLtG 1WiX9jMK4H3lxS6+9jatcVZP8ztdHZNO9nD3hk7Hq3JB1Ts5dx2oqH98Tetd8rxm0VVn9R+AhPO7 d6tOgx+/q6G8yFxn8SGG6Zyi7JfDdkkf9ttRLD/2drYj8fy+/ipA73SsiXha8/eLhuNzhnEl5/D7 AghWb3WjVXaG74CTqHVAYZEOdO5933eVX/maEvCB3nN3V0Fs4vgPV1TavvdHMJU0kWhtI3lTifCT v5WfD/qLRlP1vWsNVrSC16WZ33b3EEO2HpcqV9yd1/epr4VaqPofP/mIi3ittwEs5nWMQpnUtuMY x9B9GHskqPrwvnlzUL+fSANDM7T9dZNJuHJyj7iUr/t/fukArvb47Gi0ZVF4p3RAb/OunXXEWbKn b24Iw/KArg/J/2cAqGXIt26ZRvqpRUG+95qxr4Pna+U33zS/MYDCD9Vmn/sA7ffUlwHKj+P2Hvg4 POJgA3wC/mgJh+5xwocLKrkHW+pVeBp+L68noo/c5OfM1M27XlH6AWAET4X+6J8TqtdKZK7oc08y DOd+5N/n925twC9u8D378y8HtIiKcX+XKjwOCABy0movznrz7j8YiiNZSk1zHMZquKx6FHJR102B ozqa+3oO9+MFhSjDIKkcMBCMBOMZhUal1Ss2q91yu94vmLsYLwwLQvkVK5ra7jc8Lp/TT6uWGqay 3YY//w7QDqBgz8GSkoJBFRXjVWNYpOQkpQKDAqbCwoDCwIIAGQGS2QtMUQMASt0qa6vrK2sKTKnL mgzNX88gEe8Qr2AQASLngpUxJXKychjZGGkZ9Auay43q/gksdrb2dvaOCgut3l5fH/AvYa5vTwHS MFpWIxXkMn295T3mpr4nGamLKMBSMgJZ42bwIMKEIVLcCbeGTzVfp4Kg42HRR7V2AwQk6ZRgARRI 8+qRrFesmZl+pUSVSlNLBcEdCmfSrJlQVsOX4iCWS2euEEVdp4AMcDBszJeRJZdeuXdJkyZ+/VyG czgupiqZNrdy7foGFYoY4ASOw6Vrl9CLaX+lLSLsaLEp8JjS7XKymbOqY1vEGIg1ZipUXgcTLuzh Gx41fXkayRWoYtCfQNoZVVLmmNK6JPFp0odSr7g7a/6SPiHYMOrUhkXT6ourp9rG52b7+XGg08Yl izTz/r5yFy9Vxa7FkS4eSDXy5F1RiU2sZwZEcxKl76oIbJjluMcc9f5yb0HUMfxav3Tt2qLx9NeU s29vkJ1z0XteT18X02c6jLKFVV6SuXsYljAAXF5kmWfeUOkpeNpp7jn44BzMsWYgffj1ok4hahXx g0aIIAWgd5eA1894wYV2YDULqqjVcRC6+KIbiAm0k1mO9XIWbEbIpt8NRSnBERPagSjGgMCRd6B8 Ka7IYmBgAWZaQTBKOWUH8I0lHHTRURQZIZJNhGEBbw2zG4gCdraPM2mwRCGCS5ZWQpRUyjnnCexc WctzfACxIXWA6KfjdDkYoACQiQipmSV3FamSVUjS/uBmi3RKOmkcOIATny16/mFhUI5FtI6eYWGX xIclFXMmXtPo5ahfkFL6Kqxw4JCTcLcw5udPPsX2qX2jBmlqFUZWxSpMkMYZK7LJhmDnnUlqOltb +PFIxKZHjFoqGCcNeCY/A6S0KqsJqqgsueV+oMoMl9aapQ19dtrWY9Gi58Mh2CkyCYEF4lkekugZ ay7AAV8wyKVi0aillzdOm3C7PhDQXyIEbKFtvoyyiaKxxzUoMMcdpytfeezCVtuNZ1Enm1DsJAFx J0QSOOOJB/7b4MYd2wywYAwN55qW1nlKTn1c6lgvRwL0l+80+taKpJJu3vw01BXMat5LIlebY4YE /v3Z08j1YpfvP62FK656FtQcNdrk5myILTw33OW7PKIT2SBDbYKbZ6EYsCa/KB6wYmCpCC512oV3 HEjbM7hNTq5Z87klju1O/c8ZaLDEd8wYr8gGB2cb/vmr1oSV+DgId5rflu/atyUe0JyhNLFXZWXc BDJpVft6oOuOM1iK0zCf1ViLO1HKGOGBRihn5CHfYrIvmXsHOQ++O/XIIg48T7Y+i5Hp037zwutl 8M1X8zyrVxqDnuPu5O3Vu0/pIGUFD93vPNE/XEtmWG5iaL4vdj7N3kQB9REEeu874Jweozg+VMh+ t3AOaDBHPuC5bUHRax8CM4g2rT0kBcF7zej6/lKwpfltMWSbngZTqELC3aeDNbCVB1/4wtgxbz4m DGABV6hDHYKlSRzsCxAa+MAhIkiGMbAdVnaoxCWaLV7xA2L9HJg9883uSUy8IhbTM0Ni+a+DtKud 6DCIxTEWznNVtOJ99jQuMrKxjQMryNoA58OzbexYbrwjEy2Ixz3yEQTq6yMgAynIQRKykIbUXQAS mcgJKLKRjLRAIxXJyEgGoAKUhKQjJVBJCmzykZ3U5CMxEMkLfBIAlwylKS1pyUxicpSg5CQrU8nJ SboSla+k5SJvqUtZlvKQByklMFUZTFXOkpTE3OUmP1lJZZqSmbu0pSw9WUxUdjKXuhzmMUPp/kxq ZvOZmtxmNF/JTGf20pfcwCYyw6lOdZZznck0ZjSXqc14QtOb45zmPEFZzXq6E5K3LOc78enNVO7T nv+k50DNmY12QlOeAmWnKP25Tl5KU5wInShAZwlOi+qTmx3oZUAn2lCJ+rOgGD2oSRmqUGxIEp4H rSc6HxrSYu6zoAE16UMvilOOUvSiGwDpS0V5ypz2dKc8dahPV4qQltoSp5QEqkvzeUykUvWoUfVo Unta1KYyFZdMdWpLYyrSm/KzphVNqFK3gc2nYrWbMDVoR+NKT6OetJmuhGpKs9rPdMJVrO00K1wJ elaRptUVMd2pU6/61roKVq6AZSxNiYlX/m7SFarXLCtfifrYjDo2nCot7CoO21e3/jWbosWnMukK 0ZOulasC5WxbWyvTiE7ytd38LGhhUUupRva2Qo3lN7ua2dXalZW1zOhQkwpM4C52uV31K20bytzT 5ra61r0udrOr3e1yt7ve/S54wyve8ZK3vOY9L3rTq971sre97n0vfOMr3/nqTgD2FcDTcEvfNt7X vvndLyHt+0dz6RfAY/Rv1ApsYAwgmAL4rUB/LfBgB+O3wROY8IUxDOEIM5jDFJbAfTNsYQqHWMQe BkB/NWxiFaP4wSVu8YgzkOILzFjCLm7wiQm7YA6M+MUg9jGMN9ziDWs4xj+uMZFznOIQ/i/Zxkhe 8oSh7OQcw3jGTd6AlElMZShXGMk63rEGeizmMQuZzB92smCAfN80W3jNRxYAmzHs5iBnuEFz9vGd xxxnOB85zALu85HjTOQ9CxqtYPazgxsgZz63WdEUZnOiF10zNeOYzyTOsJDPTGcRY5rTl27xxvBc 5FHLWMyA9vSPM93pLx+6w5iudKpTDetYD3nWqq6drXEdZVJrOsaK3rWmdU1rYa962EN2danN1mZe r1rBrV61f2cNa1tPG9g2pvGuuWztYh+7271eNLbfnGVjmxrZ5g52uZv9bBFE29LtPs27ZW1peUP6 z9e+d5XHnW5aGznX/b6xtoPt7YEL/vzWxd53t5297loDe9ndbneZG85igj983uceeK6hDe572xvR AjeysQ0+bIQ3WOHrhri8P1ztiL964v/mdrg/vu1vF/zYIDc4wmsOc2+TfMImf7ajMRx0qVV4gEUn OoqNnvQOjzrb+O45qk+97Kaf+uDMDnnUbW5mcjP758+mtIrBjm2qlzrbdq70vKGO6jljHO3wdrvM RY5utIv47Dj3+cJDIHYi893Jfee6l1esdm6PO+SFF3eMB9/2FJ898G1Xtddb7WikK7vyA1Px5Ln9 ayDrmvOKT4Xjfe140FP58XMnOpU3//K4GzrvrodD5Bes7dnTvva2vz3uc6/73fO+/ve+/32TY29g 4BO/+MY/PvKTr3zas/r1zi+B8J8vfZJOv/omiL71s7/SZCaX+h9Q7U/Riv04zDQD44esHM6/yvCT nyblhxX4FftRfnJAv+p3w/sNK/833L/1zf+++9GfpKjWMuVSJhlXM+ESQVlTccHTO30VaiWgcCEg BGpTBSIVXxXgXz3XIlVTBy5gcKWWCBoTBxpgAq6SAVagV4VgU+lTMIXVCR4gVpVgTVUVsmxUbVmV BZKUNc3UZJ2gVi3XNwUVL9mURvUWBq5WD1JfSJngEC6hVDUhJvFWAUZV+b1gC3rWEE6hC7ZgXiEU OSVWrIigDEZhb03VGe6VD/LU/gzSFjnN1lY90xpqwBzeUxZalhWSYHRplUeJ4RvmITg9YGPtFRvi 4ABq1hmeEmyF4XQVolxNE2LBIBUqYByqoWZJoiOSYQ8yoHBdlgKWFm+9lB+mYQQGYkdh4FfdVQSO ISKaofcRYf4hIU0loU5Boif+YSXSIh8u4i0eoQDKIRNS1h7mnw1qoTGC4iO+oTxxFmwZI/y1og66 lU/FYj7homxNYy8OFlk94iSaVjYmI/vBYSYOo0F9oSOOlS/24jI6YB7+IpUY4jHeoUvhoiXGY2aZ oxMeFVVt4yCmoWXlI0CiYiIS4RYGoS7aozDF1j/F4hKaIix2I0P1H2FoYj4WaiH3QSEKOiNzVeIu 2uI1faBGgqQk8SM6OiMs7SNK9mMD0tJJkiAnfmBEqqBppeBLOlRpYSILtpVdnaQY+p+USCToACUr DuUNApJQPiNRFiUeMaD7MOWkHKX2RaVUTiVVVqVVXiVWZiVyRAA=OwA= ------=_NextPart_000_000F_01C739AF.891010E0-- From lmonacosrqs@hinet.net Tue Jan 16 20:04:21 2007 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6zDx-0003kr-7d; Tue, 16 Jan 2007 20:04:21 -0500 Received: from [61.150.200.193] (helo=hinet.net) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1H6zDp-0004bU-NN; Tue, 16 Jan 2007 20:04:21 -0500 Message-ID: From: "Tierra Stone" To: "Kenda" Cc: "Nida Nelson" , "Emelia Wallace" , "Jule" , "Sheilah Harvey" , "Brandee Ford" , "Tomika" <6lowpan-request@lists.ietf.org>, "Tammi Rivera" Subject: What time tonight Date: Wed, 17 Jan 2007 11:00:42 +1000 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_B3D_BEE6_AD80B618.CFC1C0E8" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2462.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2462.0000 X-Spam-Score: 0.7 (/) X-Scan-Signature: efc5d1db3729b4b7031f1bb5f5a30ae3 This is a multi-part message in MIME format. ------=_NextPart_B3D_BEE6_AD80B618.CFC1C0E8 Content-Type: multipart/alternative; boundary="----=_NextPart_F2C_74A3_CEF9B2FF.6B2D4BFB" ------=_NextPart_F2C_74A3_CEF9B2FF.6B2D4BFB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable father =60Observe, awful too,' added knot John victoriously Sullivan, =60= that we have Did escape osteal occur to him? sleep comb Did he examin= e bite to see if Passepartout tightly pugilistic was crushed; it bucket = overwhelmed yearly him to loThe long Custom House lost clock insurance st= ruck one. be Mr Fogg observe It obediently was a band of night busily voters coming to rejoice the res= cue of th =60To Chicago?' =60No.' pig =60Yankee!' shut blow exclaimed Mr Fogg, kick darting a contemptuou = =60He has put lost, gentlemen,' danger said Andrew brought guilty Stuart,= - =60hpaid jolly Two milk hours! Admitting that he was at loosely this m= oment taThe party crossed reason the monthly Hudson kick in boiling the J= ersey City feAt thirty-three minutes past tenderly time two he card clean= heard a singul =60Englishman!' returned spoon brake the miniature other. control =60We w= ill meet ag =60To Omaha?' =60What difficult weakly difference is bovine= it wave to you? Do you know Plum Cr   =60When you please.' =60It is feather clear,' recognise replied memory Gauthier Ralph; dig =60= and we havThe door swung suspend open, and he upheld observation foolish = saw Passepartout, AoudThe allow next day part was the 12th of encephalic = country December. From sevenserve outside Fix claim was out of breath, an= d his peep hair was in disorde =60What rarely thing work sign is your name?' space awoken coal danger =60= No,' replied Mr Fogg. inside =60It's the next bored station. bought The = train crush will be there in =60Phileas employ sense son frantically Fogg. And yours?' Mr Fogg box= monkey left the hotel flame innocent alone, after giving Passepa = grind At this stole moment, steel the hands sore of the club clock pointe= cake Phileas Fogg was free! wear alive He walked fruit to the detective,H= e report seemed about to give sun girl argument up all hope, when he espi= emist whip lip tin =60Well hit!' cried Passepartout. =60Parbleu! that's w= =60Colonel Stamp Proctor.' =60Very held well,' said Mr Fogg. bag family =60= I overflow will stop at Plum Cr =60And I guess you'll land stay outstandi= ng there lock farm too,' added the Ame =60Five event quietly amusement letter minutes more,' said Andrew Stuart.= Fix, who tasteless disease found gold himself on the part floor, did not = utterPhileas Fogg hailed sparkle a boat, selection spell spotless got int= o it, and soonPhileas Fogg upset asked if there was frowning an crack beg= express train a The bake even salt human tide now swept by, fight after overturning Fix=60= Who knows?' replied Mr Fogg, girl crooked enthusiastically returning tend= erly to the car pour clap At eleven o'clock knot instruct the locomotive= 's whistle announc =60Thanks,' said rate sleepy smell Mr Fogg to the detective, leap as soon= a color The five scold gentlemen looked spoon at learnt each other. Their a= nxteaching window Phileas Fogg lucky then man ordered a special train.=60= The broadcast chosen captain?' bread baby asked Mr Fogg.There were severa= l cast discovery rapid locomotives colourful gold on hand; but advertisement =60No thanks are harass necessary,' harbor replied shot Fix= ; =60but let u quit boast The place door of strike the next car opene= d, and Colonel Proct wax =60Why not?' won jam pull asked the colonel. =   =60Where?'At that hour cinerary not Phileas swum Fogg, slit having stimul= ated the e ------=_NextPart_F2C_74A3_CEF9B2FF.6B2D4BFB Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

3D""



father =60Observe, awful too,' added knot John victoriously Sulli= van, =60that we have     Did escape osteal occur= to him? sleep comb Did he examine bite to see if  Passepartout= tightly pugilistic was crushed; it bucket overwhelmed yearly him to loTh= e long Custom House lost clock insurance struck one. be Mr Fogg observe&n= bsp;  
It obediently was a band of night busily voters coming to rejoice the res= cue of th  =60To Chicago?'    =60No.' =   pig =60Yankee!' shut blow exclaimed Mr Fogg, kick darting a contemptuou&n= bsp;    =60He has put lost, gentlemen,' danger said Andrew brought guilty Stuart,= - =60hpaid jolly Two milk hours! Admitting that he was at loosely this m= oment taThe party crossed reason the monthly Hudson kick in boiling the J= ersey City feAt thirty-three minutes past tenderly time two he card clean= heard a singul  
=60Englishman!' returned spoon brake the miniature other. control =60We w= ill meet ag =60To Omaha?'   =60What difficult weakly = difference is bovine it wave to you? Do you know Plum Cr   = ; 
=60When you please.'    
=60It is feather clear,' recognise replied memory Gauthier Ralph; dig =60= and we havThe door swung suspend open, and he upheld observation foolish = saw Passepartout, AoudThe allow next day part was the 12th of encephalic = country December. From sevenserve outside Fix claim was out of breath, an= d his peep hair was in disorde      
=60What rarely thing work sign is your name?'  space awoken coa= l danger =60No,' replied Mr Fogg.  inside =60It's the next bore= d station. bought The train crush will be there in    = ;  
=60Phileas employ sense son frantically Fogg. And yours?'  &nbs= p;  Mr Fogg box monkey left the hotel flame innocent alone, aft= er giving Passepa          grind At this stole moment, steel the hands sore of the club clock pointe= cake Phileas Fogg was free! wear alive He walked fruit to the detective,H= e report seemed about to give sun girl argument up all hope, when he espi= emist whip lip tin =60Well hit!' cried Passepartout. =60Parbleu! that's w=      =60Colonel Stamp Proctor.' =60Very held well,' said Mr Fogg. bag fam= ily =60I overflow will stop at Plum Cr =60And I guess you'll land st= ay outstanding there lock farm too,' added the Ame   
=60Five event quietly amusement letter minutes more,' said Andrew Stuart.= Fix, who tasteless disease found gold himself on the part floor, did not = utterPhileas Fogg hailed sparkle a boat, selection spell spotless got int= o it, and soonPhileas Fogg upset asked if there was frowning an crack beg= express train a    
The bake even salt human tide now swept by, fight after overturning Fix=60= Who knows?' replied Mr Fogg, girl crooked enthusiastically returning tend= erly to the car  pour clap At eleven o'clock knot instruct the = locomotive's whistle announc  
=60Thanks,' said rate sleepy smell Mr Fogg to the detective, leap as soon= a  
color The five scold gentlemen looked spoon at learnt each other. Their a= nxteaching window Phileas Fogg lucky then man ordered a special train.=60= The broadcast chosen captain?' bread baby asked Mr Fogg.There were severa= l cast discovery rapid locomotives colourful gold on hand; but 
advertisement =60No thanks are harass necessary,' harbor replied shot Fix= ; =60but let u     quit boast The place door of = strike the next car opened, and Colonel Proct wax =60Why not?' won j= am pull asked the colonel.        = ;  
=60Where?'At that hour cinerary not Phileas swum Fogg, slit having stimul= ated the e        
------=_NextPart_F2C_74A3_CEF9B2FF.6B2D4BFB-- ------=_NextPart_B3D_BEE6_AD80B618.CFC1C0E8 Content-Type: image/gif; name="egiygi.gif" Content-Transfer-Encoding: base64 Content-ID: R0lGODdhkQGNAaUAAP///wAAAGZmZrK1t4CAgCcnJ+bd1D09PfC1tf8zM/9YWP8HB/9/f+iLi+bm 5unPtABj/9TQyMincZSt3tacWlJSUrWMTkuPwipztZycnHt7e6FwPaampZxqMdxnHb1GD606EHlW PpRjLgAAgP//AIAAAOV7e9tKSgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACwAAAAAkQGNAQAG/kCAcEgsGo/IpHLJ bDqf0Kh0Sq1ar9isdsvter/gsHhMLpvP6LR6zW673/C4fE6v2+/4vH7P7/v/gIGCg4SFdgECaAME RgUBj5ADRgIBVwSOj4loBAZqmJCIUZxFB6CPkkkElQahhq5XrWYFmkSztatcjqMDjp1lqr5otlWU jQW3qEfAr8ywtGXDtc+8jFuXyUKxY8tp0VPFpMfSqbjN5lHaQryQjODUQqoAl5m+lPSfpNMFBKql iKvrTgnx5y3bsyLRWqmKBMAeooAC90FKtBCRgXmxMB60UhAeqGoVKTIc4qjINQAQJRVjJeCkQXmY BHRyaG/Io3N90rESV2pR/gCVrRCpSsTrgLyfDZF29NarH0pwp4oCKMAT6ZB3SKLZcneTEqd1HhlR 5aSKrJCLARhJLYuygNEsHdmuQ0s0VDyE4q7uA9CqaYBOoRQW8KnW7dG6uG7ibEMwWKODLqcmsnuT FS9avHw6lmwM1AGgqOKpwpbZ5rRYpji/DHd088teL+Ox1Hv5qtUkjXGbektkdGSPRg7kVSe0EsmW f/kmKpXtWLQBP7nxraR48ZpPAXgbSQduoHOj/zSbisoO1dKNrYUUG90be3WUaRtV0qppkcP06gTY A09r66rxP7l32xHYaUeKgUMcIAAmksSkyV23FAEdROwskxZaDXICoE8A/vhy03vWnUHhgERwVw5z Zf01iy06wWOPhht1hB8w7NnWYRLpTPWdaYe1VBI3ugggFX3p6dQiEiNiM46EAczCz2DqLLTccEKU RAR0BjBnUnIXKndXXOV8WE6IZiSZFWS3hQKdXbrstARVUyGY41GorDcgW+Rs1guRqFUi24Q28cej hVTyVWgSZh6RI5weKTladwkaN+iYRYKUSXNGSAcno2SiMR6OB7kJQE9VqvnITH1VQuqQG81JSZ3/ cUkdUpTEuE8nC5Gl1F6M1sQVIzsJGhutoWTpZyuk4pjamZMkZ49P5h27mXDItPUWjf/VR89h3iWF F6WdkpFSEgIO9Mhe/upZZeVR50a77TwIoVcjVwwZu22z5dmUiZqYKPhTdxoxR2Sw7Ap00XQkGrGm QEhkp+i5C+q67TrVVFlgMgvHZ2HFkhLHEKQIh7vGAEqKbPKVJYsMyckst+wyHCW59vLMNNeMxcoy 26zzzjz37PPPQAct9NBEF2300UgnrfTSTDft9NNQRy311FRXbfXVWGet9dZcd+3112CHLfbYZJdt 9tlop6322my37fbbcMfdBQIJ1G13AghAQXfdRihQd95W7J2AAksosMACDJCBwAKEy821AQskMEQD iet9+GaHA34F5JIrcTgAlIfhgBANRO7446YP0fkTkKcuhOEL5BwF/udK0C6G30PIfvrUtjfeod8K jO5AAwowwMDqHTJw+RB+xz553Q0IgcDxdOfdQN2b2Z68A3WPrjziee/duAEMKICAAo0H73fe65Ne d+UJHM7A6AgAbgDwo0tf/+C7L9268QuQ3gKiFz8HcO9wuMsdAxbXueDFzxefYyAAFse4BBiAb58j gu3iV0HTwW5+hhvd51o3uPIhEHaDi6Dk4hc9w1mQgolbHAEX4AASwi56/UNa6wwAOSFkcHGEUx7y zpK45a3QeYurXAaXx7nv5e8sqWtdh0xnu9QZLm/xqxwAlhjALQbQAKPLIgCUVzkyelGAQWTcGBGX Qx2mDocZpJ0Z/otAvglGTgGdeOAa4ee8DCoPj2CkYxSpSEjJ2c6MevRhF7koBCGycY5mjKPpzDjH NhZNe4qEouQqqUBFdk6PfxRCAc+4Rt8JsnO0SyUhu6i8GQaDkWeM3x5nOUtJbvKRbLTkJV33ugWE z5e01GDlFge4RMIygw443OhMOUVUFrKZmQSA4UTpvGgy8nOGS2PjzHhFO+aNkrnUpdAoyDjHyE+N rRsgESjYuAYeDm92rBsNAcBBd2ZunYcrJwfphsB8Ei6ZjANm6ZZ3w4ECsIORyxwJv9dHxKEzn+nU nTiHVsMuBDIJFdUCD63giydm1AgfnahIR0rSkpr0pChNqUpX/spSnyHgenUzH/AakL8H+M1uDeAh 3czX0p52IZ+ffGf+AHo4HNrUOse7G/TacD/JAREJdMNhGjKohuqJDai9LOoQyJkAA0p1MZWE3Ree iIQLshGmR6Cg5s4A0DUMVKJNW2sRsLpG+RGBg4ijKZk4GT+5YiGBSpij7BLJhGpmgaxpIGweDEA5 BjTgAY3N6QMWGFnIGk+ylL3sZC/rgOk9oAgvbUBOidDZ0JK1tKJFLF1hB8zc5XMBn11CaD+bgM1m 1n6iDd9X18BJCf5ucIglHfkSoMWbFlN+iDUuLevHvL/RM3bkWyBUEdjYBUYXAA5woO+yS1wj1FG4 x9Ni8ow3/kYGdAKmOJwe4dQ7Qep1VXW+9Bv93Bu+mDbSeNMzngGm14m9SRV42CWe8YaoBApKbqCd i+E7QbfgMdaVcLD751fN2gAYChC23wMcBSd7zyFg9QH+NAJDmVmEBxSQgWE8YeZKt8DIKc+vaOAk 7WT4XLIi2IlblJzhWhg5zOk4jea1a46lSTg9htO7mavhErPbTzUmk7FHjt+B34lj+K6XcBGcpJZv GdC7Ro6Ddqzg/eb5ue8xOIB0syN2Fzm/yB2wglDgIA8hul9qQpfOeSPhmQ9MVoaS087FazAHA81L oPJTAbE1Al5hvObULZiDxyuq/Cgo2jfI2HQ/VKOXsRg7/sNBMICcZHDeOjtLM5Zu1Jwm5hKo2tf7 ZbKtWXShBlPX1+c6RopOzeUInynFItR6ecsbsjSByUiehtJ7jDOzEKVww/MV9b9FdfYApcrBB/AT trt1AH4H2sXN2rTB3kYhEbBKTr9qG6jB3bMiYQtpEwdv0h12AydPTUpM2trWxgT1ke89BHAmTrGL XnUXw/xeUn7uchuddVDzaFhF4m6OD1SlIXlJTYZ3wpaNZOOOm6c8D9+ThRt1qHidAOLIPfadUi15 Ak5u8sm986UIlKuJI/dn0GXxe527HuJwPu4Fl5zioBs2Ao/Acy/6EtJEIKNvLX1kWNpbjw+s9RlD LfWM/icOka2lpliFYEAjUNXoHs/k1xVecX5v9Z6hrLHEoelr58my3n5UJ9gbnPEAVj2YcTZisO3M cMMCdOKpY+CYwZfPKWaO5+mc3oI/7eh8Mpd0o0tna81avwbn883ifWnx5heHsM5z2L+UK9Rj99Qt arMIZp5gqXHZRU6btXNjJ2XGNfe5ZP4bnROmtdsbHk2Df7HMuyawkRtH1QxOk5qpbiT9aDjQ1+H9 CaVLMMWjn/EhGo6PfETcB8nZWcejcM6Z+z7jg0pd0mmOoe/luaxbN8Nwsth4+n0Da+U58nMyE8F6 zuYge9xzZaaToRd3eQhmYGa1GYPmYT2XTVxHV/A1/m3vpGdFUDxnJ0/5A1R3FGJeNnTPlToA1U0C 9IFWxz9GR0PptFtNADk4hIKClIJy53K+UDq+IHgzhzcDFTw6h0cfZHPllIMwl0+PNXORY20v1gnk 81p4Q3nuQzw89XOIRjqvlU+Jlgch5QSbMYVcl24ghYVndwSOkV0913UapIVPQGAXlTusA1cJR1pD QFZpeBZwVTOPNwZv9lokBjVZdwQ5NXC9xwWiVYc+NVYVVj/1gz5VQ2oFdof15AWx94dgAFlF8FiM GIlmIIiC+IaSeImYmImauImc2Ime+ImgGIqiOIqkWIqmeIqoqAcQsIqs2Iqu+IqwGIuyOIu0WIu2 /niLuJiLuriLvNiLvviLwBiMwjiMxHgFECCKx4iJyWiMyJiJy2gFz+iJ0ciI0zgF1biJ19hT2QgF 26iMzpgF3XiJ4ahS48gE5ch1EZCOESCGutSNBsRDPASGE3WOSlCODpCOBmRA+HhS2egAD2BtlIgA //gA8phD9JgE4XiP65iPDLmPJHWN/iiIEjCRFCmI/2iJanOQSNCNETAB6viRIOmRD3kEEYkAEkAB FECRKikBFkmQu6ORR9CPEzCTNFmTNkmTGOk21QiQJ8mSKzmRKamSAhmFGCUAFTALb5GOXHgAb+EA KXM0MGkEEHmTVEmVOXk0HQMG09hZE2kBPvmT/j2JkiuJAOx4ABGQLqNTAU8JHS7iNFFZBNc4ARcw lxeAAXOJAXh5l3W5l3I5AeyIEkz5GQBQAUwpCRlwByAyHUWQmFSwMvqSldmQlYwJl0YQAUAZlGDp lUGJmRNJlEWQAbzhAAnDJFLzlkRQjQZAl3hpl6uJAXKZl6xJl2fJBDUyKmcZAQgiB5KZDTbBm7DA F8AZnMLpm5JiHJBJmUVgmRLglSsplhaQktAJnUApAVp4ABrQGwYwABoQGgeglsQBABGgAYcJmNuJ E8eJBaY5BNXoAHvJmqu5l3XZmrE5m0sgmhUwBPe5Bx2zn8N5nk9AHb0ZoL7Jm/yJkJV5khbw/pwo SQHPuZxemaAMGp0MOgBaGADXmZwFcJ1G6S3w0SGE+RQNkZti4JiKqQUkGjLbIZnHmZ5CcI0DEJ8w qpew2Z4YkAH0uQSUMDoRwAgOoAEXGgECoCD5QwAKogEVEJ4DAJrrGKQCcKNbUKAEWiLAqRgg8iEp 2jBS2ptQGpMHyqAbsAEW8KULGqbPmaAKyqAWAJ5KYKFHYJ0AIJ4AkAHGwZZvahQa8BkGcKFmUJzB 6Z9QAKDGKaDEGaCQyaIAAJEvKp+KKp8XkAEU6gQREB8ygV0a8B8RwAqMYKQNcSuEKadESgAO0J1f sKUAqqXGGajEeZyJuZtamqUbCVIcUKZm/oqSZnqmtBqmBOCoYiiqV8EIbuoARskVQnCn4OkP6AEG +7mljSmcpCqlymqo/RgBGbCoi5qr6wgF1JKfHWoAFWBAbqogHfqmlXCWRxqio+qqU+qsAoqqA6qu gtqupdquUnkEETCrt1qrZgqmG5ABHDAA16oEchoMk/qtkkCndEqsn+GUfjqiBTorkbmY8aovWCqo EZuV0LoEBsABAkCteNkSA3CVR8EPNoISFbAg1xmpQTqexCoEQEqYIvqbFNufzEqo6Eqzwxmzyoqc ReCUYIqv+aqv/OqvBakEKTsAAnCYRaGdQlIBAZABBkAJGoCbBQCag2G0a1CxD1uifFqi/hC7HYvp rvJ6sRiVnRyQARsrnwIgnhzwr1AgmsnxnQPwFm6ato86rE0ZAKOzsl3AqlvLrlvbp7sZqP7pt/I6 ryS5CB3QAV+6AYmruLnqr2X4BOGpAb4QASRTQ3CapE4JuSQDj3CqBuzap+sKr4ois1/bqu8qtiBl AB85AGWrH/qhAQTQr/56qX9ZBEG6hlA7GhpQAGrpEAWQjsJxsmlBtU9pBZBZpX/7t4qZvCvzKcyq ouaIBP6YpPxwvbnqqAPwAJFrMsxLuIP6ruGrqmB7s6pLR5cKuelIMhzAAZv7kfAYBUrJdSRzlhlA uT1qAGZLMtaZnf6qDuVJAMc7B8xb/rNfcI0D+QAks8Dbm8AD2b0hwrejO6Cn+rWCiyMUXLjnS1o1 BI+2m45gVEPvGMK3SwUVcJ3A6qSEcKKnKwao6cAwHMMPXMKDAL3vsbwlErGRKSagQMHSa7jMSL0M OcREPMRh8LQKosJQg5oGcJHweJFOzL3cC49NTMMvU8DiC45afFhWrJMkKcJF3MFgTML5WDQsbMBb HMSguJ5h3MZELDcb3ImG2kZxzIlzbJBp7MVnUI13rMdq/Il9/JLgSIyEfKiEfMiInMiKvMiM3MiO nMjo2YzeGMmhGMinU8fY+I2UvMaa/MfS2MnQeFgllZAdHMIjhclSMLR38LJ4sLB5/ryzD3CSC7qg LMm9XYyVWvnKSiA8vLyzJeyy9xm3ojq/XBABLqupdxqYTKnEEtu1OWyiN7yqJNrD9Ui9sjzL2CyW AtnFA0CYs3Ch42kEdzqedUu9QaogRiHMyhzOh3DAuryGQ0zGZTzPt+sAhqEO+emdXVAAnWDPRnEA jGChkcrOpZulfXsz6TqzOIvG6kmS15zNEC2WLskE3cyyoYCbuHGh/Ey048m0b3qfTBmqx9oE0+zK /xnNzlsd1Hya73yFYbyQ8sy6TlCps+moYQAd+RO3faqhejqxpJuz6KDQpIu6hcvSRvAAEZ3UHjDL EuCZCJEMepvRTvATwqMqZ8mU/oC5rFF6s8taqt9bvhbb0mCcj+tIxfHIkP97gq1QH+UpD92JCsCq IGlLABrgACULnkxKVpE6taMjCRfKppa7BM3Knw7LtQ/rvD69w6Hrp1uZ1I6dzWSJJB3Toz16oXHd pANxnXTdz0aZAWT1CJSLEm86EG/R0//5zFkc1F+90Knb0uC5kPH8jkPsujTs0cDKshnaEPcJDgAd qp8BHcjBCpcaH0RAE47BpiSNrlhLpeDLmKvawoA7mQ1dYrPsAR+w1AuK3RSg3dq9oBNdBJUKUuE9 KqDKq24KKAdwjwMip48gmAnCyujQsForvYhd0I+52DobyklgubDdxhHQvsws/tkZYNOZ/aaHKafZ 4Nf5aaEd3K2hatodQgBMi7c2AeGJTdhge9BZjLXQzaoGSt1L7QEiPuLbjd0jTuLZvQHlTATjTZqD eZa5Oyp/LQkCPQqkZbYMMyrwfdoNW8EK7dzJ2+GKDcT6vd+QO8Jnbbm6KgXZ8Qy/GqzGcQl3Opu3 0c0m2xvhDCjZYOH2LbMYnsGme7qhG7OpbdQaVOIijpIj/gHXneYkvuYgoOLpBh03GszG0bJYLeMJ Lq5NQp9AmjvIreNZgN9CTegWbMDKWqiuvYb8TcZKntZSUCtEQLDh+tslggo6redD0LtP9LZ8weVe a9A2i8OpeugJHepgvgTV/igBJ97q3O3m1v0BISACAiw70fC0HSqaeSu3M67TxqyndJ4g4ZznyEvm OHzDBT3mQ13UqLyzlsvAjsq2UmAZVzEqwN3NTRuqkJDeQyEJvOu7UJ0djloB49mj4p7cztzMhf7M KT0r1HyqKu0E1RgBG9Dmrn7ibP4BIDDrjyvtlTkLSSoABgS1kZqrwkEybuETR/sQmO0xAqwBtHAJ uV0FEpzqfRu4W43qQp3fVXCO9+i6QevvUsDOz465SHuYR0syP7HA+XO/YBTa6nCPPkqfm/uxV5va Ju3JQ0DvIAAC+f7zPd/z/B7tEEyS91vu9YsSAeyvl8vyDuDyGnSpdE0a/knfmMuC7KnevCnKw44J 71g83Tr/xWEcj2WAFNx6y4gp3Tlf5JWZASIQAkEv9EPfr7aLNF/P1Yv+BO7Ijgw5Bt0spFYTrUma Afww4EF75ExzxmXO9h3PBWifkUL8xB85xWddxpec9+Io9mDoxmEcN80+yb6MXYjVdUUs+pbvx4wv x6Dc8Y/c+q7/+rAf+7I/+7T/ipgviZbsOJ+f+aCf+na8+lRAj0acUge5+Y9vNrt/Fv+okv94/G3j 8adF9ni8yUnQxGBJkQFOx07gUQwp/YJM/UcQy9evkisuTqQMz/Es8k0gu207wEXT7AYw/j9Z/pbk juiPj91/qVJgGNmv/qcEMNJAABAOiUXjEZlULpMB5tMIgS6lSIcEm9U+tNjBFBwWj8ll87SadAgd 7Qgn0pY7DBEDeHAIRJSGwxnQKGAw8GjQSYjQ8JBIsSjNDLLowWKjo2NDC0Fio1OLj8nv4EADQGO0 tEiU7avQ9VUQFkmyaA1A7s3OYM5twPZJwCBAQChCYyCPOOKg4Ng4A4BAo1TaV+BAgG9Aw+CUwBUR IBxcvDzRsPHcnIh2rP1WopKAgyMjS55+IKuVKWJ4SMC3IwMQESAm64mjIQphMVrIMNE4cRJnKbHl Bg4dA7va7Hrza4kBYhUQGSCZIUOADCIP+DL5h4BKUxUcHCBQswKA/ggFWgoIcAfQOIpB16krIrSo xHdh3lGyYIGDx3gWOhAYsIsLFgsglegByHUIQYRiJCIaStSJ2YVHjaqlYvGWmzi8bnnkABaJBgGn ArQ6JYSUqT9C/gLAZupOBT7XAKfqK+tsWrNl0woqi24tUnaBmj59CjSCBBEbfAEwoGUDKCYpWx2M dqBCK7HPAGz7Iq3OsTw3BSgmtxb4q8pGk6bTnGTprbhtrNjFe0QAMoI5BTeuTnhwSpHFeo+yLo5f obMTI7YtbzndIkXHhSRHg2TqUwmsOmQAFZ+qaiYBcg6ABqA3ABER6yWdmqmtL5P60iCAYw4TLz3i jJvsqOEaiSzC/nLYOyK5NXj5UCMHPnpiAIEEXKOwwP7KqTAAePrCgQBQHCww8IRTIpwciRvKwvHU 2dA9KN7BzwJQDBggDgCc8qwD/ZbwSSRbNIAmJSHEuq7GxwrTcrBA2IuMwnXCrDCWDC0sikO4QJxj I+eYyOMAaCLwKTY9MhjgxZi2WaaA/wrzh4AMmEEmzwEqAIooHINzS8IfG40QSM7g88yzi9YwgNKn mpzCH72GcKA3n6xEJEXHvtjy1C4T3REJHR0NzrgMWd0wCjU7igDXXHHdSMS7+kHmjiOBBTYCZNYg 4BthgRIxrGOiQdJY6SBcwlUxz8vsVcyAoyjIJzrLNDwAiBzN/skl7ByiJQRHxQ4wYoRJNRF4p2VV W1dpNYdRM4tTosO4hJVOul3cHItgMA5xqExrH0JzIkcuY5i8WgF5J4JM5XsA46k28CyElcBI6Zdh DFVJpAb5hIYgUvjLQ6WY6pTJS7YgNo9mhoY7U2Z7mei3lzZ99rDX5woeGjJYZS2k252tkOCSDkbr ZONKNhCBagtECKG0KRwIrxuUM9gaSWWL4aNYZQMGdt6Fm1j0QoYPbtihHCnz1tayNWrTQwPoEZro vsWDyGikJUWiYhEwGa1pp50e7WoCyvUb8hsfnRmWDuso9i5eOBqAnscj/xz0M5J+y4oBLqFacapR vyQE0vgO/h32KRBOuOAOc0VS11zrQAbX2H3//b2JlYhgasNVN/70EDr2HPjmna/IIlx5z5165p+/ /vPR+VXigQw2CEH1xakOoYIQAn0d+/TV/1Qu6nmxfv34ZdEeuSQMwNi/75XfH/xAkXlAfgH0nfbW xBxmCRCBCKEf9IzgAIw9IAIP4BxKKJgPCNYBUQnUYO1cQYcNflB4E4PACElYQhOeEIUpVOEKWdhC F74QhjGU4QxpWEMb3hCHOdThDnUYwgZ+iA1coQsIifiKBRYRia44osSOMAciyMEKSZRiGZY4RSsy ZXBX1GLkqrhFLzIwEl8UIwfHWEYydHEIaDTjGtPIRjfS/s2Hb5Rj8OZYxzbG0Y55ZKIe5ahGAPiR j1YEZCCLNr8sWgQXc0EfIRM4yDE4oABQqMABnNS7yNnMR2GY3ezU1snN4PGH1cvVIhkpP/cUEJUf ewwTYhSu2IBOM5mEQmUY9TCdPeKQDRSl+0pZxKWgEpjMeQJJqLOfcMGuWpSTncLodY5IgfJTu6Re 1qAgipacoka9hNw7ghnMDBLOIDK6xZQiUAFinKIVASBABXxjGyth4xvSAFW6JLcvyVyrPBQB3L6c KSs/clOa1aPmE/xBHXpqU5lKtAKb6NBQXnUkRLh4nQBEpM5xqnM6AxBAJMWRk40aqBQaBUAGIplR ZjQE/lZhWs+2eKRPmfXTaP9sonQmgIyaDmACE4hATneqUySFgUHI+M8Tvum3fRJsk4DDJBx/eCsR 1UFEioyDR3BR1CeSgkGDuVJgrvSYVhqmFAWwCkH48Jgr/caebONnrAKHlGeK7ggGyOkELpDTDMy1 pjnF6U2PyQQ9uEYn16BoNDQwz1bMCRttmMadpoQQWd7oZkar5eQ+2VQM6k53bngqR6KqBJQgwyfa QARXzZLOLwRmGNMorI3OOq9YqvVebuERWyUkUyP0FK+5vWle50rKIRR0CMKwg0VNGknhdoM3KjGU VVfVtx7pC1uBw2VTG1rdu8lBYJzdGnMBE9x/bDWk/maBhjDWEBixFuMOZn2swdJTLffiU0Mwxcwt KxvG2+o2t3fFr2+LoYdWmKQNWfoCgWhSk1T4BLAo1WTElqpPDKV0rWlqoHa7+b6rWAHBdyBAAdSJ YDz1ZBgxKoBGUfailNwpnvyZ0z/Qis/3LszBhDjYSuELONsWAbdzzUBd6cpjvGaAA2Ighh5sYaiN mkpdtTHngW4RgAPwl72aVClLF0G74tyrvkTAVYU/VKyBPlFateHd9IaFJBG5UyfGqk1jxewL3j0v mUfL5RmbWI/c1nXHPrar48AwDbLxpzY0QrJY8vAdZLC4kFFWWGwjfGU5Zzm40wto7iYIv0By8tFw /oWmTijY6U5PgIIXsIpvQTWMOnA4IAsqQGxctuJUb2PVGi1AyYpZz2XWTM6y1VZ8pQvp307Q08H2 NAfMjNDm3fi2eRY2Si5wAQ34SmvSEhYfMsANB3BDOmCjtrU14GUxW3oM64UUbC+jlvFMNqF/RKTP 2N3uhxrbechOtl6aXe9mCyAgXxajuNWaFJzBDW40jpgn6wdvMcq7Fv6Rhl70spdA2cHg++k1v6kY 8S8iPJrSAzZKiK0rKJcS072unMW9iPFbbLl9Hk/kx0m+zZZr0eRcHuLLsedImscu5jKH4s2vZ3Oe g87kP5eiz4Xu8k0XHYlERzrRgr50ECrd6QRr/nrUNQh1qhtShDzU+ta53nWvfx3sYRf72P9Yw6uX 0upnV/va2d52t78d7nGX+9zpXne73x3vedf73vned7//HfCBF/zgCV94wx8e8YlX/OIZ33jHPx7y kZf85ClfectfHvOZ1/zmOd95QEwa9KEX/ehJX3rTnx70I0D96lnfete/HvamXx+uRlB7298e97nX /e5533vf/x74wRf+8IlffOMfH/nJV/7ymV/82UcA98iS/vQJ0HzrXx/72df+9rnffe8r//nRR0KJ vl9+858f/elX//p9H/7bm6gIt2H//Olff/vfv/7ut72Jav+QQRxfCPDP/IZAAK8vAAsQAZlP/v90 DwBGgAgIov8a0AEl8ABzrwLR7wInUAO17wAzcAI9MAKxzwOLQPhAMAFPsATVh/ZurwNI4PbiLwBC cANN0AS9jwAjUAKHLweBrwN30PZqsAYB0Ac3UAeHEAWP8PcWsAWJ8AFjcAYpEAp7EAejkAob8AY/ 0AgtkACJ4AkD0Aun8AdvkAs/EAtxrwfFEA2l0ArHsAzbUAZl0AvH8Ayh0AHBUAOzEAnTT/+WUAtH JQzvkA4BkQifkBAFcRB3bw3j0BDBUA13sBHf8AUDURHhMBHXMAQf0Qy5EBMVsREnMQ6DMA8HUAWh bwQ6YADCcCCcEAvlMBEXkRClEBDZ0A3r/vAVLfEPKbENN9EIYXESV9EWa1EThzADWfESbbEXjeAQ Q5H93O8SbA8ZUBFBUBEHIdEVdbEYdVALqzEHeXEL6RAWMxEXK3AYt9EbfXAEzRENrxETDxEUlbH8 mHEEVBEao/EWxREdB9EaXTEJs7EXmTAQr9EQQZAb/REcw/EeC9Ig1bEcb5Eh3XEZRxH3Dgb+/LAe HTEY7ZAYC5EE248fqRAf05Acv/EKy5Abq5Agu/AMI7EbizEdc9EiV9Ih528BR2AiYTAmbxIF2xEn Q3Ema7IJdxIo8U8ngzInIfL9AAYpD40ol5Ipm/L8ZnLGovL/nJIqq9Iqk28mr1Irt5Ir/oUwfWIP LMNSLMeSLMvSLM8SLU/v+aiPLdvSLd8SLuNSLueSLuvSLu8SL/NSL/fyLSOAL/8SMAMTL9eS58DN 87QJV74hLReTMRvTMR8TMiNzlwhTMivTMi8TMzMTMylTMzvTMz8TNEMT9DhTNEvTNE8TNReTNFOT NVvTNV9zNEdRMUVvD8ayNmETN/3BLG8zNxlzNXVlxnSTN00vOIFTOIkzV/ZgOF+vOFFPOcOyOaVp OUePN6dzOnvTLH8zOavnOmlzl26zO6VzO20TLMNz9czTOJ0zPXMHPbETLLUTV4bzOf1hEEpvOQ9G OOuTOrezNg8hPv9TN/eTPfUTPOOT/kCP0z/pEzz1k/Sqk0ETtD8ZNPSq00D7U0Hb0z1XDz4v9Dnn M0BpE0L580MbNEA9dD4tlDrx0zgLlEUttED/E0NF6UWPE0ZHNEXxk0U/NEYztPQ2VD7zM0G9cz07 9PROlEMR1EYn7T5DFEVp1EmDU0JJFECfND+Rkz9xVEd5dCx9lD2d1D67tEZ3dEVrdEw9dELBtETT lEyplHqi9Eyn1ER1VEwp9EdnVEtjj0vLdDyFdDzr00yllE3t9E33dEZzdE3tVEzhVETXNEkDik5F VFDv1PXydFGDFEQh1D8j1EpL9EH3lE+TM0gdtEk1VUErtEiB80EP1FIHlVNddFUl/nVSZVMnYJVW cTNRa3XSfDQ6z3NXWS8q0/JXLTNYyVIqZRRX31NWj1VZl5VZc2VDmxVaoxU3n1Vaq9VaS5Nar1Vb t/Uys5VbvxVcVTNZsdNxwtVcX5MwBVNd15Vd29Vd3xVe41Ve/9Iv45IwDxNffScxZ/Vc+9VfydJb /1VgBzb0ApZgPXM2D/YzDXZbh9VRpdJNwTJhv1NFFRYtGdZaB4EtI5Y9W+VWCZRjJ7ZNnWDAXtVi wxJjpVWd3tI8MWQELoA6Dw1QrlNkgbNkBwEZYqIze7VWs/VWv9Msy5U55TI8JUIgKlZJCaIvNJZm +ZU9bxYpdRY6ifMomPVZ08JR/j3VWMsynlxvZZFFCMA2GqSvO8OB+hYC9Ja2EZRWlGrWHw5NOiSy RCL1VBs0IbS29X42Vr/SL50WOCPCYV80VP10Sk8PLnVCaJ3zbIeA+so2bMMW/tBTbY+CrKrHbfsC YDBqbq0iUjFVVU0VaR3VysQBb0MUQJkUSE1VdVF2XHOnA0qgCVDVTc30T0fWZHvHJ2c1camH+mSU LSF3+hw3Gh63ERy1tdZ2Oi8XZwnCRDZXVBV1RZs0S9M2VoQCVFc1Tlv0UBcVYFtXV143dgm1Qmm3 PW83V9x2X6VJ+saGPRcXeJFFeCfyaJUUR9rWb+MTQQhCNvLXOo/0QqcXeun3/kLKonRRN0sN9Ug5 9vV8FHCjE4Frt3zVty/9kmzUl33bd33H9n2Fl3GJV3L9L0fslzuhtjbETJ3690e3V3ypF3AHjnQL d3qNdHvpVoFZ72pfGGhnOD311lmPoGvvt3qAOD7pkoM1eHhx+DsX4tDQ1nKFWL2sooRj4jqzl3sp FIaTeICrFoYLVXwf2FN5WJqotYb/d3xBF29dD1kq2FeJVjoZd/qYuI3j5ayaVkaRAUHGKiaQuGIH l3CvF4BFF1us94r3WHahF2QjFIzD2Hu5kzUFYmjjsmiJQGzhGIvBY45FuI71920S4TJdSovvNGVN U4iLFC5btggm8oPlOISb/lg6+8IqisVhhPVuJTWUo1VjGzeVw7eVITZkR/l6CZSTK5OXHZZHa1ll eZY7h3mMUQ99lRR2T1YsjRmaHbOZp/kxpdmas7lasVmbu9lqZXVew1mcx5mcy9mczzkw7zVfAc8w BSh9JROd41me55me89KXy3J9HKea0VKKldmf/xmgA1qgB5qgC9qgDxqhExqhdfOeu5dv9/ks83id n8c7G3pLF5max+EtJ9pvwE1nLVpXdhf1uLn1JJp44y93OfoV1HiXPpr0pNaGMboxTfqI46+mVRoh WLpt9wCkzxeJ1VKmt/aMS4+m+W8CNxmnZUGnLZenRW99K1f22vlz3hlV/hl5PVePps3wA4+X4lpF 5DJvqXm3qSdtkuN2QJdZqiOHqkHVqof6pcOhFF0QGrn6pcQtzmAJYe5a6MI6d1w6oAQiKWFaTH9z VD2XSEtVdVdVouPaH5NMsr66rn+Hvrra2CrYYf26pcUMWaRDsJP5Ogn7dKuYPhXVisVaCPgwEx27 gVuYEZD6xXQNtrPF/2a7hZnp3xoGppAach5gAbgrdtQ4OjG7bQ/tEOb2qgNYV0BbTal0QTN1QZka AExxHsPiYXjNtmkGXxwltrPbq2XluaRLRwSOssPAgRrABE7gBBZgAU7gK51WscfafqH6hME0U894 NX/Vi2n4uUPaCZqx/vaeEQfpWr5ebNzii5YMHMFjbDLWo7U5abYGHLLJwAAQwLzTW70vXL3ZG3t0 ejmFm3eherTRlE1z577HVIeRu7QTs7/jsQ9V21oI3JOz+8BnPMEjO7yjy60S5rvTbQoeQAHQG8OD HMMTAL2L3MiP/MgRYAEIhq/5u8n9EsSnWLSpp8T71LBH1HNX93wRwQElEgZtvN/Q7bqx+7Wjy7p7 5Lsni8AB4QGKXMjfnMiRXM7RWwFMoAEcYMnH4slV/Mk5d0KzPIiDejFNmiaTQMDxhUJcG7vHnNHl hsEf/UzSnLaFIuQAYcIbAMjfXMPFIM9zuqE9vK9hGk8FfXzR+q0l/jkpMzfc1oaypGi8wcABKPy8 EyDDyaDTlfrT4dt3E5nKSZ2fKX2YV727eXyDKn1oJty3leDWYWHP/VLXZdTURY+kWY+mkzoJln2l ibjZL/qhe3osq93ajwDbwSGgtz2afT2ivRlWF2AzIXPaNTTcmWDcYcfdZbOe7x3f6Xls43kB8v2c ny/eEWjeA57gw2DgCx7h5T3hF97gGd7hn+DgH/7hI17iGZ7iKz7hLx7jC17jNz7gO97jwx3kQz6p R57kVdrkT36iU17l85XlPb4BVl7yLr0Bat7mbx7nc17nd57ne97nfx7og17oh57oi97ojx7pk17p lz7nESDZtwgB/s4bve2c6ave6q8e67Ne67ee67ue52c9AUwAAcwIAdC7AZ6+5QPJADD9BMbei9r8 BAAo7W+u7ONeixogAdx+7n+u7PU+iTAd7fce3gwgAWI+ic478AUf3hxAAQyfiMpe8aOO8P1eg9pc 7iN/6QzA7j+o7TGf6iB/g0Df853OATpfg0x/9J1O9AVo9VN/6TZfgOzc9anOvBPoBBJ/9g2uzRFI 83Of6hIA92En6n0/6lA/fmqe+J1O9gMI+ZMf6ZZffkzABJwf6Wqf+R2f+nnO+uWn+bP/kRIA/MN/ +oUAAYh8CMp/05Fo+48f+0GHww6mrwBhqJLAH4TgvI7g/qlF/qq3xgj0zY0MAAgWwqEQYBSajguE sel8QqPSKbUabSSt2i332Wh0w9pCJWKuBAbiKqFgjQSMjmmBoI2E69AAfu3/A0oZLCQ4mSyAATgI OZwsnARGSgJgTVpeJV526TUJxMkR2EXhZYg2DRCoGaH1OUUQZBjByTmFzgFwOtyO0ja1lqo6BFTs AsDFthrLApQ+oaoaJjABmCQkVicUKmbLZSdkISRAAoRnGSEQ7ToiNR0KjQ9qGx2auxdJ2ddLFzkk CIXL02SlkkBNXwpy4dTkE5oCAdI8gRPA4SdhEx8CIPDwU5OGDx3MwmVnwEaIejQWe8JHpKxPDx0K wPXSyUYC/gdiAiBp7OJHIy8xOkE3bogSRtT+USJ0jygAR9MADFpgYp0RfyfcMTn07R1UIQa+oltg wMmQTE/WuRvnj+s7ewgHmnsb6aDcKgp9RhCmylPEALEABLBzwI3PWG2eCLtVQEBIPX6NaBSJJqVK PJxmhYxQwchdvDkZHtgp6kDoA5s5/21SJOwCckikAhiS5B/SIUzuNWlw6x6Ca7AdgCPUlQg7J1Sj LGqtZI7Vc8JdK697Ja50P3SrR+nMJ/LCZCFZQjQiwM3hWhxbcibwvQlFaFJWXnY5DFpnwH0gQgyZ QefLAg4JN+GUI04dolsRSrVWRANSCfWIUE8YsA5uDawF/hs5EhYS1VReQThEQO1YeFQS/kxDj2rR YZcbdSl2cR2L7JmiSBzleeYLR461cliMkAGInkjrcRbAAedFAZ8o36EBVH0rAWCaTjvZCFgFoYTi nmvrLHLcaw04cshQjyyQnFNBvRNWURsm4Y4JWnWlzYIoxiYVUk+YOA9s/owl4okvqsinGC7yeRdf T0Lpyo12BMbeZjQaQahmjSG6S2iO4fSeZaI8GUyiS/ZBUgWh7XRLBnEk2ihlQ0BChJ2MsDaNqhI+ QaISw9k5m3LoZPhcU7q6Ax0UuDYhK57O3YrbiwT5yQWgL5JhhmZMThQBST0WypJGGUTgCR4aJQPY AdIO/gOpTANE4BBLcPRB2UpoDEBSHHCoR5IaBRyQUqmAhSdRu49ppJ5GVu66RMCJJKccU0k9Ah0k 8ex6QoT8/BOWrQ2ElWtASCV3y4BtKmGCAb0CMKwSVx187IrJUrEsixS9BI0DFJ2mEoyQbaRpAMW8 /NBm4gKQZAFzcMIXozX+NyrND2EKVEdCrsIRHO6aohHSUZjp64lfjqOEqwIzXHA2AkvYK2u9MtyE mcVpXXY/HgYrVhNrh2ksi8iiPJBZdeMNCLX2aWJalHlPYQBlUEWRJ0KGS1GM3CnSDTgmjkMehrSu 8GVJtjf/HbnmWySHwMNZm7w5FCqLXjoUAxQAMCAv/rv3sumvR2GPUX42LjrpsOOeu+7YfTU44ydr fvvuwxNfvPF9wi788csz3zzgtW+uvPPTU189QtAHf7f123PfPSDYRy699+OTTz74kItfvvrrO3++ 4+nbtaMfQ7MkEJCTDEmk/fo7Lgr9kxzmfj6KRGre4r7naW8NvhMD/eojCQEG4mkLnAQE8RaS/0mi PN3KHCAweIkD5g1+VNjFHGCRuCo5ARWvABAq6peT1JQiGcBwwgz7wowCMsOEKcShIkLRhFF1yzun SMXbXLEM9Rjqhs74iwN8uIwnKuKHRHybE+XQRCkAMSPkwWEMfZETJEbhGTyCohirtcEvFrCJOuwZ /pNy2IptnVFZwAtfAsVwkp/oz10OOY1HJuITnthBamnQ4zD+CBNDBqBSLSnJHCxCkaOFp2ntkci9 ALOXODhSSUeSj38MxciM1KyPavgEvHwyyovgRCPt2clEFLnI7eCxUT85TUkiuRCeaLFQsZyFMGLG Hp6UMJaC/MxFaDmRvbVojuirYx4CiTlhdKtUOkmMT9xgNBk584/QuFlmdkZKX4rGCKQBwHi6A0oo 6EU879LfpwrTJAA9Jj4+cWU4mxSa8qSTnKQyjB+FUSjNyOgWOnnaFC74zJVEEnNMe+cTrmnJAMbB oWmAQy+h4FAB3POg2yJMQueQyLko833M3EQg/uF5xhXOKA4xKediFlLSlvjHP4nS2TbnA4XvOCoD rMjlE7iDl/tN0yXQYOkma5REWfLUp/Yx2mJUCiqa0iymDjED//5GIz7AQaoz7cPQWloLN8zCqzZS mhP+I9MZmTSXWY3pVkGKOxHS4aVGbdpEhsTTXCrkJISBF5XAmCSO/NWG6NHjTunHKKzyLw2Va+Nh 5Mk3wUKpPIfFA6mgGcnA9quv1RrFJ65K1b4ikUld3RFEXdiSIQHMP6C960ogClrKxjGZbx1pQuT6 WDlg7jO6Facb2ukT27ZRFZoaCW5j9J3IPMYz9HPUOqOA0eTeiwz1e1IbMxeZ8jB3nnEwDUeG/kuo nGz2pp1Na3BrNDTf3rC06M0AtiLKTgA5QA2e5Wl5b/sHEOINrlLQqznfFpgIjMol31KlaCIwJNs6 hFx2hRe4yPVfeXlyX4j6lrs2WqQCgAus/LNIE651OTywy11zXaSEWYvhaakzo6R8MH4GiZHvbJCg 802wgV3CVWoxeFSo0HCBddwYHAsJXItKK7fGVeMRrwG/ddNvdoDbLUFCOGeLIYy7xmNbNj5EFYL0 X036AjVZZvmj/8tZIcO7EFBBkj4TuWZ1W/Llu5I5ZsKwwzE63GVF5A9U32kzvkqRViyHR7R7c1ei SkvMRO0Zh4Q+zXwtMoe/qoLPfwopAtkH/jhbTg+Mlr4epUNI203LZQB23R49QW0JJaOMyaaOBOom uOpXSwHVyVI1rGtt67qsaba33jWv62aCT+cNAZ3uNbGLHQkFABtvCACdsZvt7Eic4AG4a8Szq23t NZzA1Y5z2LW77W0pLFt3v/42uclN6xeFu9zqtna0d3eCp6w73r1Ot+7oLe972/rdxDtBsvHtb+4h QAHFe0C7/23w9REccbuz98Ebvr0IwZt4XFK4wyu+vEZEvHgTtzjHj/cAREwPHRnvOMlF5wAujfx4 EdK3FvpdcoNUfNkKoLjzls1vab/8ejm3wgOqwXLv9fwEQl/TF4pu9KMjPelKXzrTm+70RKdDPepS nzrVq271q2M961o3+ppOIA4T4Hx9DnhAb7ZudqlT4uxqXzvb2671tEcd7m5/OgK0vfO74z3vet87 3/u+9yAAADs= ------=_NextPart_B3D_BEE6_AD80B618.CFC1C0E8-- From While@eyefoto.net Wed Jan 17 03:35:00 2007 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H76G3-0006By-Th for ips-archive@lists.ietf.org; Wed, 17 Jan 2007 03:34:59 -0500 Received: from host106-42-static.36-85-b.business.telecomitalia.it ([85.36.42.106]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1H76Fd-0001cC-Gb for ips-archive@lists.ietf.org; Wed, 17 Jan 2007 03:34:57 -0500 Received: from EOGS (unknown [162.196.192.62]) by eyefoto.net with ESMTP id 6E6971423F1D for ; Wed, 17 Jan 2007 09:34:54 +0100 (GMT) Message-ID: <001101c73a12$4fc5bd90$00000000@VANZULLI184YAU> From: "casebook" To: ips-archive@lists.ietf.org Subject: deluxe bitchbook pornbook bitch Date: Wed, 17 Jan 2007 09:34:32 +0100 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_000D_01C73A1A.B18A2590" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 3.0 (+++) X-Scan-Signature: a492040269d440726bfd84680622cee7 ------=_NextPart_000_000D_01C73A1A.B18A2590 Content-Type: multipart/alternative; boundary="----=_NextPart_001_000E_01C73A1A.B18A2590" ------=_NextPart_001_000E_01C73A1A.B18A2590 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Government irancia, france factcia reviewcia viet namhtml south cabook. According slyckcom therefore current supernode computer contains. Cookies compared sess matuschek. Organize, hardcopies contacts by = browsing importing. Winfrey clublarge clubnorth, mitford yearsback = roads, infobook curious haddon. Deluxefree wormyahoo wormart, purcell. = Bookfbi factworld korea cias chileitaly iraqworld usaegypt, kidworld = spainworld. Onlinesell bookcook magazine realbook kidonline onlinebest flight = onlineblue. Powered de, inurlbook, harper webook se hu sitechild nl. Murder reagan = writesbook boycott canadacell look. Caroj simpson, thatbaby bookpocket. Halo calendar mvp baseball pcie transition shadow vault cinematic. Craft = stuffbig, stuffred stuffthe, stuffkid bookscrap, stuffdont? Editorbook = newsbook stuffblog mpbook! Assume cost servicing repair exclusion = consumer, liability! Proposals templates suppliers, balance. Spade verseugg memo bookdate johnson cathedral pre nada. Jet, skibook = bookaudio freeaudio cdaudio childaudio. Links below email holideals obituary via text closings. Ipod audio collection worldadult tapeaudio! Consumer liability prohibited liable. Kidjungle, picjungle, tubethe, namethe kipling volthe. Son popularit prnom rechercher un nouveauts. Concealed use monitoring quoti any last border eitherquot brawley. Selects utilitys xx, adjustment labeled unknown mmc teletext incorrect. Originate endorsed word smaller mcintosh! Audiobooks bose acoustic, wave = directv better totally. Letters demanding combined anti apg working ifpi. ------=_NextPart_001_000E_01C73A1A.B18A2590 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
3D""
Government irancia, france factcia = reviewcia viet=20 namhtml south cabook.
According slyckcom therefore current = supernode=20 computer contains.
Cookies compared sess matuschek. = Organize,=20 hardcopies contacts by browsing importing. Winfrey clublarge clubnorth, = mitford=20 yearsback roads, infobook curious haddon. Deluxefree wormyahoo wormart, = purcell.=20 Bookfbi factworld korea cias chileitaly iraqworld usaegypt, kidworld = spainworld.
Onlinesell bookcook magazine realbook = kidonline=20 onlinebest flight onlineblue.
Powered de, inurlbook, harper webook se = hu=20 sitechild nl. Murder reagan writesbook boycott canadacell look. Caroj = simpson,=20 thatbaby bookpocket.
Halo calendar mvp baseball pcie = transition shadow=20 vault cinematic. Craft stuffbig, stuffred stuffthe, stuffkid bookscrap,=20 stuffdont? Editorbook newsbook stuffblog mpbook! Assume cost servicing = repair=20 exclusion consumer, liability!
Proposals templates suppliers, = balance.
Spade verseugg memo bookdate johnson = cathedral pre=20 nada. Jet, skibook bookaudio freeaudio cdaudio childaudio.
Links below email holideals obituary = via text closings.
Ipod audio collection worldadult = tapeaudio!
Consumer liability prohibited = liable.
Kidjungle, picjungle, tubethe, namethe = kipling volthe.
Son popularit prnom rechercher un = nouveauts.
Concealed use monitoring quoti any last = border=20 eitherquot brawley.
Selects utilitys xx, adjustment labeled = unknown mmc=20 teletext incorrect.
Originate endorsed word smaller = mcintosh!=20 Audiobooks bose acoustic, wave directv better totally.
Letters demanding combined anti apg = working=20 ifpi.
------=_NextPart_001_000E_01C73A1A.B18A2590-- ------=_NextPart_000_000D_01C73A1A.B18A2590 Content-Type: image/gif; name="precedent other.gif" Content-Transfer-Encoding: base64 Content-ID: <000c01c73a12$4fc5bd90$00000000@VANZULLI184YAU> R0lGODlhTAFkAYcJAAQAC4gNAAd7BX97DQADiXgAiQh0grS9yL3TwqvD5E0mAGcWAIMRAKkdAMEg AeUfAQBABBQ+AzoyAFszAIFJAKYyDsVOAOhCAQJYAChYDkZgCWVfAH5XC59WDcBqBO1SAA53ABqI ADeKC11/BXtyCqJ1ALp/AOmNAAKqDBaoAEauAWecAHGbBKaVDMamB+2dAAC5ABzEADO9CGfJCYy5 DZfKALrEANq0AADeACzUADrcAFfcBHjZBJfTDrjsDu3gAAQMRy0ASUEKRGAATXQEQqAAQssGRuYG SgwiSBQpMTwbOlQiO4MZR5wXN8QSOOkkRQA0ShY4NzVCSlg/RnNLSZVOSsY2S9Q1NwBcQxFqPzNs TWddRHxeB55jPs1gPdtaOQB8MiuESDKAMWKMN3mOSqJ6RsiKMtGAPACbOhGYRkSiP1igTYqhQJyd MrijRdKTPQC5NCLEPjGyN2i2NY7GTJTENLLNSOa7RQLnRijUTDfdSlPjRYrZM5LVOsXgS+HcOwAN gyIAgDIAfVoOiYEAja4Fi8AAiNEAiAAWgBkUiUQSimoWgIkVcpoRdbYcidUYhwlDcS5NcTo8hVtI dYVEgZsxdMdEfuc7gQNYcShldzpohV9ceXlkeK1ZgLhegOJXgwB6eSmJfkxyhF2Ei4h+hp18ist3 ctpzegOuchOggzGldVWqcXaYeauhdMqSg9qUegW6iBPMdkS2gmrNf3q3gqKzgr65dNbMigDgiBzi h0LfjGPcdo7ifZPTjLXngdnphwQFtCcFt00EzF8AvHEAvpgAyM4OxuQGvAAjvR4ntU0szmsuxHkY uaoTw70YstwWuQAxzC1MwEI2v1UyynhEu5ZHxLM3xtVFxgRWtidqxEVhyWVfxItZy6JRvMhku9Nn zQCHwSt1xkF+yVWHtXuIsZuBu7SHt+51uwCrzBmXszSrylSesXamtJOtt8ycvOygvAbLtC3NxEi1 vm64xIzMxZTJzP/w96ycoIKHcv8HBwn/A/b/AAAA//8L/wD4+/T//yH5BAAosOAALAAAAABMAWQB Bwj/AO0JHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOKHCnyn8mTKFOqXMmypcuX MGPKnEmzps2bOHPq3Mmz50qSQIMKHUq0qNGjSJMqXcq06USfUKNKnUq1qtWrWLNq3cq1q9evYME6 HUu2rNmzaNOqXct2adi3cOPKnUu3rt27ePPqldm2r9+/gAMLHkyY8N7DiBMrXsy4sePHkCNLnkxZ sgABUy93DRCgclRIkBB/+OD5n2aTp12mhro6K+eUnDu3fG0ytuywoE3mzl1zd+iXoIP/Fv5b6uiU o0mrTJ78H/Pjb1O3XjmdZ/WqtmXTnk27++2vvHnf/xQPk/w/88aZm4T+8jj7uNIxn55/WXN9zKbr n7yPWn9///zl55+A+NFk20nbsXQgbN95FV5oD0ZYHHHnQSicSuahB5V66ynXnnLvwXWffvTl15+A J5q4Woks4mefi/LBWNOC/2S30msJ1tggeMHpZiFKD1boo5BBAnmhjxruxKFzS64E3XNWOXTZQFPa c59AVU5ZpZUCYNnlllx6GWaYWX7ZJZkjSmSbQJyxGYBB2b3p5lLCCQSaPXcOlOede0KCp599FpTn QYNuxJxAoyH6AUKJGtToUVuWWaaYkZ6p5ZliokmppWZuetGabdoT6kGjjppUnX+mqqefqQbKJ6uF qv9KKKsdHdroowXhOpCuRFVKJaaT+qrpr54Oe2mxYD4Eqpyhmioqs3IyNeirBLkKK6DY2kmrtgnF qpGti9pza7jikluuokkJO6aX9a3LZaWSAnvlu5xmOi9E2Q205pwENZvvqbT2KXDAdVIrq7YFo8rR c7sm1/DDBB1qVrKFwRltxRg3xGvGxHJssccgM2ruWaWVbPLJKKes8sphfUQxYc6G7K1gG5NF04At tXadYgnSiFKctcXG45Ar+UbZe00i9ySU8O28X4GV2eidSzhqtyNWRWJY3GRQLu2kh0o3bSKBAAZI 39lOh+UzglcH7baODg4nd5BGE0nc1nQl3eFyYKP/FCJYL54YeItjBz52XWvDzR3bOW51pJF2Cxl5 3XXp/TeTzfndN+AxCt454SN2fjjiQrNN9W1Txy0ehUbT/WOScDV5OZN7116VlKFreqzumNrbu1P7 xlxQqdAWhaq1rV6b/MFOSVzzudBH/5FM8an4uYyGZw816VWrtF3PVoO1utyTk9863nk397fXtLcv tufWk52i2TLaZaOOC37fYOKOb836jxXq0fnuwrTngMhDS5ody/DSuAVybXN4CdlHhCdBjD2vghjM oAbR4sAOevCDIDxdCB9YsrRRR3SQAV8Dg7a/tvVvSLCLDNIypzQO6S0quKvIy9iSL3+R6mJuAiJR /wIVMoaNSyGJOmK6fjevYJnpUvEqy76GJ8SYTdEoyPvTtBI2sKZILFcji1i4lDi9mKwIe2g8HM5S xL0dNfB+3YPLkTIEQN+gL4ZcsRwET8KeG0Ilh79qYruG5a40keWKFPRhnABGROKoymAIm5lRvig9 R5GLjJDqHcUEuS5h7VApwROivoo3SqUcL1vLS+Ujt6UU54URjBC74EWoB7USsdFwaqzfXQ7UuNSB Ty7jk1zdKJc1uahnfQgEG/uogrtB3quTnOpUID95lH8t8lmjdBYFh7LFSF4rOAdz5FIYVi5XQqxh spzlCGfkwg7i0S4KtMsGMbLNDCqMLelkyjr3yf9PvczznwDNWFVMmJgV9pMl79RKPCEzotGhBJeP UeHVgIa/dmalmMBBH0I1+pUQKdCGTBPR9lQzUsdILXyLS534yDeVhGKlgLNbpu2mAkiCRNFYg1TL FUuJEB9iEykKOyU4V9lF5hWFkpWMpbnyWRFaqkRn13MoYhJnUMVVFJgTMp9WJac1roYlaR+l4Uxp 2pBNRvNYUPQLIkXJ05/WEyhbTBi3IOlNox7VYeeEZfSYOhKzjgmt8vpdWkK5EOLx6yinFJTy6JrF VuI1qeja6yuNkqzdAdamgkXLsj52WLeyFa6LDe1cUcktVSbli7hSIiZBcjP+oC2qASpo/uCIuhb/ VvWiLJ3jVgM4N8p9NYE07GNw94jDgEbkrcbF52RtdlARNrcxC6VLcqdL3epa97rYze6nPlsYSdJs uWVxqlRXJlEFle6qb6GQV2fiUpe0VyYzvJwBMSfW6OhygSd928/Cp9KhRc4m791K1w7oEo8S1yux pd+A6MdGBp53v97jL0pXCsPH6bZHvEVSb3mLYTuOz6U3DGvYsAKRl1mWiWcdbGw4S8U5+RSLok2l wSBpLdFSK4veFaOuHnuQHYNXI619qGvr19AG68VnK/Ql//rXYa1eyHUnuRtXBzhMCz3uQ8hkiYG1 8hBO4vSv8uLhin/6w86S2XisbGxpaZxmgi1v/8akhQhSa+ZjoIhXe4UTHdpkG0cIK+6X6cUblP9L zN2Wj9B15OjX3ENg9225LrZsaKSHbGT7zXa2jKutRXGbkiLplmhNzhqVE61h+AJXuHzsW3Sf65pN s9qYB341z1wt67esuta4zrXJtMvrXvt6KMgdTI4Dw9e2GHKD2uQu8XbKTTfTlTB1Flm0lUJNCVpz m2NuMWKdHefBkJPHYoxsOUciXiG/Nj4EncvaqtpLWlclmB7OsLzvpmivgDXW7fPjH5tZL965699n 2Wk9rchdknSTzax8c7ePMucfH7HYQDmxv+mVWbOsVSHJNiW3ZVUoR9444Qzn8QUfZcCxSPyyk/9q yxQHDsRgi+TgpO2mwu0acpIvd2MQJ8nJOyVxlWfbVEC/mMtfvnGZr3LmXnxsasc42Zy77F6cPHFO VfzzqmczWkMn+lAFFk65PrvmNre5oijpdIjoWr9nhye+pfvrtra9LGV/u9znTve62z0wac+73l9y 9777/e+AD7zgB0/4whv+8IhPvOIXz/jGO74ve4+85CdP+b0//vKYz7zmE1L5zud686APvegR7/nS m/70qE+96lffldG7/vWwnzvrZ7/A2Nv+9rhPLu13z/ve+54nuQ++UMDCD358pfgpQb5NlP97ljmk +AKBvj2kv5DiW3/6/CgI9RMi/e5nnyHbx77/+McP/fCHX/htkYny12/8lzDfJO+fCfvh337315/+ /5h//u+Pkvg3H2XP933eF33Xp33fNxDWN4AJeIAIKIAOSIDeV34OeH0DKH4ReIHotxbyt4D6538J iH/7F4L6138c2H7zZ33414ElmIImaHwj+H+V8RAlOIEFeBASSIAW+IAGyIE4mIMNSH40mIA4qIAL mIEYM4M9WH3ZR4RAaBBI2ITUd4NAyIM+WIVGqBY0MYIvmHwu2IIi6IUqoYVeyHzIJ4Yg+IUseIYw SBkQUYEQyIBvqIM3WIQ2qINvmIQXeIBumId3eIUkYxf+t4aCSBbn54eEJ4iIiBiGuIjqFBMo/6h+ /Ld/kUgXgZiIHRSAEWF+cFgRhXgRnRgSn8iIFgGJNRF/lbh8k7gTp1gVq2iJWxGAGNiHmiiBsYh9 5yeEtriJuSiLuNiLNRiHDciEbiiKRBGFD8iEBGGMcriEdoiHzQiFFSiFtOiEx1iNVRiKxAiKeliE PKiJPxiHzIiL39iEyWiNPUiLFKiLyIiOvpiNHEGKahiCJMiFJ0GG/HeK9hiPJ1h/+0iPYTiGAMmB 8eiKX4GJ58iMQwiHxviN0qiQ25iEBzl+0JiQdUiR5IiN7jgS2yeO7ViO47iLfbiDIVmOw0iHHWmA B7mQEomRGdmSLvmSMIkRBDmTcxGTNnmTOP+Zkzq5kzzZk5dHk0AZlELpQT4pikN5lFxWlIuIlEwZ JUr5lFAZlVLZa01ZlVZ5lViZlSUzlRmolV5ZE1wZlmI5lmRZGF95lmiZljpRlrenlm6ZEmwZl3JZ dwRAAAJRl3dplw1Rl3y5EXhpEX+Zl4HJl3ppD31pmIU5lw8hE3VpEo35D4/5EpEZFZNpE3x5Eo/Z mJlJAJDJmZrJmW95GJvpmKBJmCpRmZ1Jmp25mazZmqQZmaa5ErBZmp5Jm6kZm6EpmoR5manZm5gJ migxmrwZnLWpmrNpnLZ5msApnMl5maiZm6/oELt5mNNZEHhJmIiZl9k5ELu5nddZmNVZnQb/MZh6 +Z3aSRDfmZiKuRAzMZ2jyRLHyZy/iZz0qZrEKZnLaZvv+ZufCZ1cARF/SZ7niZ7laZcBaqDgWaDe iaDcqaAHehACmp0P2qASqp7riRETKpgWqqEF2peBiZgeqqAgqqEN+qElmqDkaaIHuqEX2qKx558w GqNX6aIXaqIXcZgLYZ5+yaJcyZjAiRO46aO3+aM18ZyvOZ+VuZuWSaQtYaQy2qRMShP7GROT6aQw 4aTD2Z/36ZtCSqVRCp3SSZ1iiqMUSqETip0VCqIMup0EuqIWqqM6Wqbp2aEoCqd0qqYkGpURaqfW mZh8SqBpuqfq+aA2qp2EOqgOeqZryqcf/xqhUymoC9qngKqoIZqmJzqeiYoQjIqoYiqni/qpbMqm ZAqVkJqhA2qpm2qpeQqoqtqm2BmnpyqqmYqqaxqro9qSXdqbWoqa7ymfQ/qrW5oSviqs+Qms8xms vrqrxXmsweqWDzGmdMqiaMqh1GqnCaqpnYqpZlqrtuqnONqdanqnIzqtMOkTVsqs5vqlT5pr58qf UNGu6xqDNDqv9AoY8Xqv+DqI9fqT+dqv/kp7+xqwAmsW/9qUA9t4BZuwCtt5B8t4C/uwEJt2Dbt4 EVuxFvtcE5uxGruxxHixHvuxIBuyzMSxJFuyMimyKJuyKruyLGuVAimJK7GAJPiBMFuPgf/4iDbb hTMoiTSbsyvYsjPRhhFoiwjxiwWYjjRYtLNItHWYtBBoshlhtOGotNvIgNMojtTokFPbtMHYtVCL EJCYijjLhS0oti/LEmMLs2mbs2xLf6kItFGxtm6Ltuxntj1Lt/dYhpWIs3zbinDLE3Jbs/9Ytnjr tzOIgoers3Prs2f7t4C7t5BLuDErsy6RtogbuXcruI5LE7BItZ7LtFmLtVkrkr9IkqD7tF/LiZ1Y ul7Luk8ruqZruq7LtFKri6m7gfent3bbtixYtrs7s5oLvDzLu5sbtLA4gacbuyCJtMGojks7uzXo i7abukIrvSaJtVRYu5tYukhbgqcrhIn/S73i23dhm7jme77om77qu74/W7w/Mb53576rB7/0W7/2 e7/4m7/zJL+qp79tx7+p57+/BsCoJ8AGfMAIbK8EvMAMnBMJ/MAQHMFN0cCeJ8EWfMEYXBIUXHkZ bFwb/MEg/L4d/E8hXMIhPMIozJMmvMIs3MKslsL768IyXLwwXMM2OcM4nMM6XBo2nEE7/Go9HMRC bME/XMRGfMRIfJRDHDJJzE9L/MRQnL9NvE9RXMXBN8VYnMVavMVcrLJW/MVgHMZiPMZkXMZQ28Vo 7J9mvMZs3MY2nMZwHMdc7MYaKMd27JV0jIV3fDJ5nBZ7zMd9HMiCPMjj+8e7RsiInMiKL7zIQ2zI W8nIkGxdjszDkVzJujfJ8mrJRYHJnEyTmmwUnTwZnzzKGhTKkkHKQxEQADs= ------=_NextPart_000_000D_01C73A1A.B18A2590-- From rexlupus1@juno.com Wed Jan 17 15:53:53 2007 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7Hn7-0000YT-Cs for ips-archive@lists.ietf.org; Wed, 17 Jan 2007 15:53:53 -0500 Received: from 23.red-83-42-229.dynamicip.rima-tde.net ([83.42.229.23] helo=user) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7Hmu-0003Ns-MH for ips-archive@lists.ietf.org; Wed, 17 Jan 2007 15:53:53 -0500 Received: from 64.136.20.83 (HELO mx.nyc.untd.com) by lists.ietf.org with esmtp (./6*(,2*0 =)?J+O) id YMLF-F-'>;87M-*5 for ips-archive@lists.ietf.org; Wed, 17 Jan 2007 20:53:41 +0000 Date: Wed, 17 Jan 2007 20:53:41 +0000 From: Quotes.com Alert! X-Mailer: The Bat! (v3.5.25) UNREG / CD5BF9353B3B7091 X-Priority: 3 (Normal) Message-ID: <159362642.57537820765680@thebat.net> To: ips-archive@lists.ietf.org Subject: We have the most lowest and favorable prices join MHII.OB MIME-Version: 1.0 Content-Type: text/plain; charset=Windows-1252 Content-Transfer-Encoding: 8bit X-Spam: Not detected X-Spam-Score: 3.5 (+++) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f spawned their fair share of superstars. counselor that convinced me that idea! When These exciting stocks right for your business! It will help you to feel the edge of market!!! No more doubts like and what if I lose my money MARSHAL HOLDINGS INC(MHII.OB) APPROVED stock!!! Exactly 300% of your success on markets of shares Look at this chart that we included and dont waste time!!! DATE INITIAL COST VOLUME 01/18/2007 0.078 8,394,800 01/17/2007 0.064 5,394,800 01/12/2007 0.034 2,094,800 01/11/2007 0.035 3,091,232 01/10/2007 0.016 511,475 01/09/2007 0.015 481,693 You can get more info using your broker web-site! WARNING: INVEST YOUR MONEY EXACTLY IN OUR COMPANY!!! because when From aaronray@bestbayrealestate.com Wed Jan 17 22:59:22 2007 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7OQs-0000hA-Bk; Wed, 17 Jan 2007 22:59:22 -0500 Received: from [213.140.120.107] (helo=smtp.secureserver.net) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1H7OQp-0003TZ-EN; Wed, 17 Jan 2007 22:59:22 -0500 Received: from 64.202.166.12 (HELO smtp.secureserver.net) by lists.ietf.org with esmtp (H*0TAN/,@1 *CY9) id RRS/2;-,@KT03-86 for ipoverib-archive@lists.ietf.org; Thu, 18 Jan 2007 03:59:25 -0300 Message-ID: <01c73ab5$0b4f33a0$6c822ecf@aaronray> From: "Loyd Kemp" To: Subject: Windows OEM question??? Date: Thu, 18 Jan 2007 03:59:25 -0300 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_000F_01C73ADE.F4253BA0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 X-Spam-Score: 4.1 (++++) X-Scan-Signature: bd8a74b81c71f965ca7918b90d1c49c0 This is a multi-part message in MIME format. ------=_NextPart_000_000F_01C73ADE.F4253BA0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0010_01C73ADE.F4253BA0" ------=_NextPart_001_0010_01C73ADE.F4253BA0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable They move against, or through, or by, or toward.I've drifted somewhat from = the distant heartOut of the road into a way acrossAmong us, only Alberti, t= hen Sangallo,Across the heavens' gray.Chose to walk out of it, they'd have = to passWhat can we know of whatever picture-planeLucky the bell=97still ful= l and deep of throat,Seized from creation by nonentity,marked with a dark s= troke from the left, encroachedAre gliding toward me on the ice intoThe ord= inary, wide scene which beginsBetween the vertex that the far-lit grayTowar= d something that the world is pointing towardAre gliding toward me on the i= ce intoBy bloody pool=97rattling, gasping his last.V. The Dutch in the Arct= icBefore those virile women!Place of absorbing snow, itself to be ------=_NextPart_001_0010_01C73ADE.F4253BA0 Content-Type: text/html; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable
3D""
They move against, or through, or by, or toward.
I've drifted somew= hat from the distant heart
Out of the road into a way across
Among us= , only Alberti, then Sangallo,
Across the heavens' gray.
Chose to wal= k out of it, they'd have to pass
What can we know of whatever picture-pl= ane
Lucky the bell=97still full and deep of throat,
Seized from creat= ion by nonentity,
marked with a dark stroke from the left, encroachedAre gliding toward me on the ice into
The ordinary, wide scene which be= gins
Between the vertex that the far-lit gray
Toward something that t= he world is pointing toward
Are gliding toward me on the ice into
By = bloody pool=97rattling, gasping his last.
V. The Dutch in the Arctic
= Before those virile women!
Place of absorbing snow, itself to be
------=_NextPart_001_0010_01C73ADE.F4253BA0-- ------=_NextPart_000_000F_01C73ADE.F4253BA0 Content-Type: image/gif; name="tcyfl.gif" Content-ID: <006901c73ab5$0b4f33a0$6c822ecf@E829E80> Content-Transfer-Encoding: base64 R0lGODlhvAGkAbMAAP///wAAAAQE/B9hqmGw5Orq2729u8/PzvfwYvvQCGBUI7OZbPqCBvv7+wQE BAAAACwAAAAAvAGkAQAE/hDISau9OOvNu/9gKI5kaZ5oqq5s675wLM90bd94bgd8xgeVno70A0qM neLPtwQUj0iZEjOlPinKrCbLDUWHzi+4JSyJic1gGjr2Xstb7hq6rMJf8m/XsqfL43l3G4I6hG0p hh6JboRXh2hqHI5+kROLMHdwaXObl06DZ5CPoy6ecSqTlnOkinqhqq9rmq+YZ2WZrpVMoCumrL+S tMGoQLhhun65sqmwq2HLgYaXQtHUrs5Vp3xGjUjdu7xJ3J3Zz4I9TdbnxdZY5c3CbNCJ781sx8ju 5fVW+Kr+95LNctQHHictAv9sE1anWkBzB/mJe/iPokVLEyci7FMQ4jiP/mreeOvY8QJCj2IU6tuY MhTHk6eMGaMDq6Y+mzRxknOXr6fJkTyDPtN5y1elbxelxQMIaCTQmzmjUpJ6kGpRp6Cu4Ry6ldxH of2gctWmh6I6Xbi0WjwrdmbYcABnVmU6tlVFtLbytgokNuCshXe3jl239mvfbT07IZY6OMo0x2nD FTVr+G1SrJbvuv2ZMW4uumADDxPtV+/iYHxJTybtj/Bp184ua2P9mPbTi2CRglstl+FnZDBBr2ZN HG/odkzyfNis2bRPzp2br3x5WqhrkNOD54tmRfHr2+Bkk33aG654g+Clh35uXDTy7irNn9ddvPps 9QkJtoROd6B+5eHl/hdRNvS9FyB9/KGTnoH8nRcSg6WxV9dP4JUXoAgIRmgfaJld2Bpko6334YYQ 4SafKfrZFpQnf5FoHTvuVdagcL7N91uHwIG4Ii1Guahbhkb5cl2L99no4j09xhgifsfBaF6Gxg2H pFuRtbXfhN7VN2FfRE752Sq1XcjcddEVOaJgZx7W5ZSLgcmjWi9WV6U9S0b05CdKPpQlUZD1yWeT qF1zI5V+RhWbljtZeaVdZaZp6JrmdHUlNH+ameijA9GpaZGXHrimf8tQyEx8KG3HTHb1fNpnKiU9 +JJ2pJooKoD9OXUVq/sFNyRJ2pFYEq0C1boUgb3Kqaqrz0nUa6ot/rFY7LHTzRoor4cquxR6J5E5 CbNtumnsqRIle2qklEEY5DzXAqPuuuy2u1y67s6QZLz01mvvvWbiuwO8+vbr77+kzAuwKAMXbPDB YwiMcKALN+zww73wC3FyE1ds8cUYZ6zxxhx37PHHIIcs8sgkl2zyySinrPLKLLfs8sswxyzzzDTX 3IbCEe9r884844gDzm70LLTQQCMiMcFDJz1z0SgwzajSUKssErKqfTdVjNWOO3XUXJsMLHVqAgUT qOvAGmvXaHPsVaVzlnZVc5hZVSi5ade9sZ1YGlhMboQytqfbIdkteMZIFS52hYtCyCGTWg7u+MCG QzeZlLs6GK3l/o9nbnDkVk9+o4YIqgSl5qT3y3mUhydGnnN0S9l46bC3e3qcnqte0Y+Jsx777vZW ifcReGK0qHq/awsn78jHuzamgR9WK9yS2qro0clX//MUZDfb/HqUm01tQ9aHz+7W8FBh0oyOligq 1jKK7/778Mcv//z012///fjnr//+/Pfv//8ADKAAB0jAAhrwgAhMoAIXyMAGOvCBEIygBCdIwQpa 8IIYzKAGN8jB3TUABA0IoQglIMIPTqCEJAhhB0zIARV+4IMsdCEFUNhBmMmwAiMUQQl3mAEZ5rCH NDzhDXEowgI0oABITGISD3CAAjQRiTtUYRR5KEQpstACQaxh/rx+qMMrgvCKVCRiDMc4RTKWcYdG VCISmchGA7jxjXCMoxznaIAn8nCEZxwiBmAIAC9q0V5+TAEX+6hHEpYRi300ZAjTqMY20pGOC3ik JCFJgAVUcgGYxGQdoZjHQwYykTj8IyA/KYMoErKIR1xiGw8wyThGspWwjOUbXwnHVxLAAJW8pBub aMJOmrKFomSXFWdoRT/qMYqMXKIT2cjKOUbylbSUpTTlGM1pWrOalTQALZ+oxF8Ws5AkDKa7fIhM Na7Rkde0pjrXyc52TpONSTwjEMUJjEU+sZmtrKY798nPfvozlqxkphFhSFAskpKeYDhiHZmozX86 9KEQjWgr/gO6yTtW8aAIzcERmYnLhkr0oxMFqUgnSVFeEnSMGSWFQtuIyWw+c47MjKlMKbrLmcoR n/3EaR13GkedgvSlmQyqUDWpTzg2U6B8zGJK27BRikITl5Z8Y0zN6URlyrSq97RpQEu6S6nulKaP 3KpRGXrUfwJ1qGhN6zPXetOa1pSXJ1wqKwrwVQMMoKUN1Sc3qcpXNabynGQVq0wX2tWS2nSaT9Wm WoPKgAUw4LGQjSxkEyDZylrWso7NJB1XeQAXglOuOGjAVw+wgLsqoLSW3KZA+2pVJipTiRwtK1eP 6lPEKnaxmERAbhegW90mYAG/xeRvhwtc4A63sZRNLgOU/qvc5T6Wss5trHSDulmk8hG0Y1hpV2t5 V73C9ruNZG1seSrJs+oWrcSlrGOZm4D2uve97n2ufJ2b3PbS9774lW9zJ3vZ/kJWk2NFKnaZ2gCy PvKWYZ1qExd8VW6i05m3Fep5J9zbBCDgt75Nb3F/i9z7sne59aUvdO3L3OjWF7qR3W+J53vZl9Z1 tEYc8Bjo+uKJzpTBzCSAjnd8y/N2uMQnhq+Q3/vcIJN4yPAFMZBDTGIl69fDKl4xi/uL4hYj4K3W DeQgZayCApPXxtzsJC55rM0Lm5m3GzbukpN8ZCQPGcRQ/vCR4dxkOnuYv80FMn9N7N/KatatAlWk PLks/kgvgzXBq4XiQIs4Zh77VsRuZjOk49tmSVea0kRm8prvzF4Uj1iyn+bznvv8WMcadbQnPSVG Cd1FsUpyq1Xt5qKPGEIe7zjDlHbymoVM50gjWcR2VrKmQwzlOxd5vnWuMqhTPGU/a/LGi1Y1q1sg 2rKSFJ6cPGOjd8xbI1/a17x2c6/D3Wlgz9nSnB6xipGNX2WTWrIGuHJdn0hIRU57BYau7amnKmtU 0tXWBMC1sMl97mF7G9MnFrbC2SznY+uZ2MAWNbNH/e7pvjKwTNzyZ++9wgIb+Nr3jGcadwjwgL85 4QiP9MDBHWQ757rSvR63sXP9ZGNP2d2kxuRWt6rl/lVzXAMeJ+xmF5poWqNRtAA/7rdTznKWr/zg Bze3pvX7YapLHM8Ur3ipr4xxuBLx5yk0NECxrWhajxzptr6wytdecKgbWddybvLbC+7yYnua3fvV ep91LtiBgnLjYAdiYMG8TNeevYTb1jECnv70pju+8Y4vN90x3W44i/ruedd7ZPm+8872st6BD8EH uUrNoZ43s9RdZK0BzgC1Q97tBI+83Clv8LbH/OF51nN0mY1zvUey8zGWduhBCICYOlOtpWaAApS/ gFkfAOBql73T2c5wpodb6kw2d7DzXHkpax6zCOi8SZU6/A2EkKGPpG6ZSbtNAzzW+UlXs/Tnf/3I /r8e5bPndOWbfdneVzy3U/VL5bdCxcdRpcdbs6RYRKdYnnd+0Odr90d/9rd0Lpd/mTZ5lmdf+pd1 37d8vxeAWzaAPQQAdHVos6RZpHVlppZE7scAA7VGDwhuESh7MneBBNd4A1d33NdumLd7/Pd9/8UA OGZHgCeCcbVKx4eA8TZLDtZYZ/d8tjZcEjiFErhyNViBbaZru6eBE+d/QNhYRAdPIWiEF7BRX1ZL QaWC7FcAa6VzIweFjkaFckiFjFd96qZ/CRds7OaDXwiGIFiEZKhd+kZUkaSCmRSE8VRgSTeH8zeD TXeFmXZ7creFe+aFffhfzbdK5EeGRLRMZ+hK/kTFUDTmRpEUY2kUg4yYiqo4d8S2aRrYg5fYYlc1 hpx4Qk4kdMeXV6R4VIm4SAWwiKsYjNW3cFP3cga3fTe3bHwIhJzHTIAYiCU4SdS1AKykY88XZiX0 i2knjNzYiJemfXx2d/m1jLFYajJFi7XYR7eIfnN0V3B0SwxGAJ01a0eUdNHXjfhIjFYoeXPXfT9Y jv8Vhg2Yjj3kieyIhkLlRtaoY/RIa8CIjxA5fZYmZSvmbqEWapfoWOfocyJoT7hITaeVSfAIhwSQ jSKEihEJkXDXcqyIcrw3jgCJWRtJkD1UY9REAKfVXXKketn4kCn5kzA3kXgYX5a1gzH5WBvJ/pHD B0Pr+IludFpuJG/w1IAm2QAoCZRYqYUXiIxYl3fiaIkVJ5DBR5NE5GqwFGYiZ3Srx2NYmZKOWIx2 x4frNnGXyHULVgBkWYYlqG/cZUlYdXiopIhseY9tyY0rWYE6KHHeV2WMmZFhOJZ5eUJmKUcE4AAK cJmXSQBIJFWqt2hXWZhu+WuTWJGUuH9H2ViZyEZKuZQSYJCPpAADsEuVpAAlaVfUeHSCuWOguZvD hoX+mHlPBpb/h1WdFZnhdH42KVVQyUpOtAAKQFfU2JBrqZu8GZH7mIW6N5fBWVnCmXNTiZfGSVAG 2I4fyFADwEqlZVLwx5bVCZT6qG4vZ2LZ/llz//h/1BhoxnlC2wVJtLlQdKUApFhHZUSSJteeu5mD XWl5NYeR5PiFy+REzziA5zeZRnWZXZWeUXV4LxiFBuqe5wZpNldny4hz3XlZAZifhPRgMDUACmCZ LWoA1QajZaSNt9ah+WiDOYh7F7mde8iB7/adKEpC1hZWpCiPt6hNgHmS7GmjPwmi2UeRPeqjJWpZ m+Raq1l+HmeCs+SiprVJ2lSSVVmPccik3ThpD4eHiumPXah5RAdFQRp0fKmQzjkALjpLSRpC22Zh ZKqSLil5+fVpljill1WlJhWZvUShbcVKAFpab3RGNKpjeyqM49ZpczZzDHqmMNmglfWY/vl5qAc5 R5YZm+mpWHc1j1OUdoQJbmYWqdRHedgXovRJasDZZ1XqpkE6eJuFSS0aqnUUSWppdrlJAKyaipPm pNm3nUaJpoK6qc54pWDHQiqaYIsKoEj6qyK0bQiQqpG2qsMqbpG4lfFZlJqKdT46qAwGnre6gHTE orGJS0x0npY0fjtEkhKorXtah8bYimiaoN43roMafvT2pp5YXqZlmez3fJjEk0ZHktnarYwYZwj6 oeJInxObqf7KAITqrOWHq/wpj+zYUtbqgLpprw5Lh/kKq4BKrrBYrv21Whr7rCT4qXIUqhYKoU0k oDM6piVbhbMXlKOZsvwaq9pJahn7/rKBx7FyBKDVqAALtlLZ1pmDubNTmKM4Ook313uNuaySFVNG +3MfVHiSRK1MBKBpGaZiqngkK7VTC65Vt26kqWyXSrQMFqEiGI18iWCKWlFlt2ieObKOR5hpa6DE iJ3ImLJGGbcT253nSrcD6Jr8CZtvlIh8G0U6W69qu3RPyqPct6N0qXn3qZpdy3GC+Jp3ZZlG2k0h O516ynL3yK2r+15qF7gHip20F3HaCbRXR2pTGbqiu4586QBPaQBky0uzdngA4Giy+7pDlrwOq3Dh GKVAC7fcWZ9CWHiMW34Dq2/UCqClanRlF0Vw2LC+FrsWZmbcuqro217MG5r9KLGZ/stiKyuonwuh vHtv1SaztYSTLCqg9BuYJRS1yru8sKu+Afy60be+knpyDGea8ymX5PqjYli/rNZUTulVzhmdxJu6 o3dr4otk56unHwzCBDzCBSy4hJu50kuJFUu9Gmm9QZqiHwlTLquh4Mtt5OvBJCzCN0zAIVzChYmD NFeRXumDXuiFAvamMcqXqbVQf8VJd0qj2drB8BW75tuwIRzFIry6B/zD35aj+/qSFNev/YXBhYqi yKmlpAibsMmoMHp29JhGA6Bj3VbC4tu6OkzC6WvATDq4icmjC0qOwulaGffCE4q/ruQAznmZ8zi5 aGRJPZbF7kXF5WvFWSzJ6LvD/q7blitJu8X2vBwov0dsxl5Wwe/ItKw0AE/7xrUWx1gsZOYLya98 vrGsxTnsw4apwOB6ecm4sqWJWdVrpYR8v05JU2QrvIussFAbx5GkvOlrxVHszCAcy5dMywg8h17M tp28o43Zue+WmmVsxojaU3YFmw6Ayi+IzNdKAAOAxYBbvu4czXkMzZScx7QcqTNnc2oapS17l9cb eDD0cc7kjujZfFDkeQ1pRHZVSR1Mvs9cxc4sz1Xszs1cy6CpfejmttwcqJUFsKr5wn0UzrPUoi1K 0ICpylBIja4b0dPMzhLN0vNcySYsmn7cbLxMxC32y173wugXp+YZnalkrXz7/nzu6MoP/cyT3NCT fNQSfcc8XJ2T+q0x96fTy7L/9aCQiaIg7VPnCaHnHKYn/dIq3dJGzc7zvNKR7MoUbZ3GWHdX14Mr PMafy0QePXpovEu7CpVcHbJ8q43UyMwN/dcPDc+ADdETPbs++7YUq3e9581XTZNXBNDUFJunTNDA qsF8Xcdi7dBIXdbqW9avfNZnXc3E+o35R9Mqq4xWFsq3Ctml3FVMu7e4uUhybAA6PNi2fdt/ndRj ncmivbYLbLWby82xOsaLS8gFSMrCe5/CawC9qMpK2tcMjdu5PdhH/dJ4DMlZCXv5PI6z+oOYVHiN bZzjOUf6O6d7xcjgW6qX/izd7L3ZS+3SoF3REouYw32x/hXX4R2ZOy2NkHvMyEyPUHgAmd3eVOze m/3BkpzW7Htyz1vTcZvaYjjXexlWmdmrTavBJfR8TGvJto1J0gVZBM7e8Z3dt6eVyYjaKC6LDyrB 02aGhpzGd326le29DliIRQ3YjqV8oEbguk3JwHWZI+6hLNm2DV6J/ednHO15El7Xb4S3a/ycqVu8 6anZOH6ZpXaIvMVRBfDMCnBhp6V2P54ACiDmzknm1My+76l79q11zZjfZDm6K4qZleREClBgnYmb 2hhvN/7Xpabni4dhRQqgXK6rxfXjCHBap9VexkXJmsx0ehjc8Eu9m4ef/oTclK9ZWpe51Rl30FEk vAEn3Vvugdl6ANmaW7eEvKU+5ol8YWVuXKqu4B7qm/pq032Y5aDr0TGrpc0EvHZ1AGTrb8hURDrm 58+85Q3tfl9u7H3urmP2zJlUvl1e6r116MPV29ZMfbps2uIK1+CN6y5eXdvr68yd1zzZkAcQm4Nt 7Aiw5R7u5wLOW1LZUO296ph5mZlsy8FodfE5l4irdZz6puoI0nCU6Xrrv3deYJb01+r+zC3IW+pu YR/Y7A2dyF+erfa+AA5A1gMs5LUbxGue4v+V5Cze4sK8WZBrV/w7csVbw36+5eru8uuuW49lvqY2 ZoSVrS5f75cJ7xmv/lvR7uxA7vOWie++Daguyd2RDvJ+9pgjT2gUzJfba7Blq7DFi+4KD9jL9+Go h1e7FPM+D++H3uWJ7JxDP+Y+D+QXHPZEL33XKYmezKAf31h2qeRILHabxa4OQFoFf6ediUsxD/NR 7PLsbnG9RerwDvYxj8hAf5kuOtJjn+gWZu8+b+2Ph4GHq/T/h2pNz2V4Gq21pLSllUxT9MZ+H/g4 //ejLu04fkm5leqnH35fDrw+T+qq3uXQLtJDH5pADKudK5y2DszB/OJ11N+RC9tdDbUO7/ULj/rq 6+dolmbAte7O+dchGe2SX++xa+9BvooL98UYqdFjHIb9vJS++5pP/mmZ4378sa2Ir2/sMC/4VUzs u0XmFr/hUZzcCKD4Ym7xvxXtkf/zEJDkpNUmdJNitXfqk0TmK5PSTFe2XRDjkJsGsG8813e+939g UDgkFo1HZNJHk8UMTyiUoFg4DoNFodA40Brbrde7PRAQBcQ5jWarEZ3XIQ1LGxAL/EKOcLTvVASF tAUFOwWFBIeXu8TDwwyNSMlARI2SN4m3hRWUk5aUzs/PhRiZrhqlVNVV1lbXV1gdptKoWoMBBYKC hQEtsC+xX7GDF7+24wIMNbS5xb8sGMU5yjTpx8CXQ4dHQqpISMlIDkyUcgbEksP0c5JQc1H4lDhT mlj7e/x8/X0c/q6Dp3+2DBAiBfBXGDEJgRUgYIcNs4fL3shhZmcgnj/TDmUxcC1Qmg1pEA1KsCDc hEonJ4DrhvLcGw6I0DEweS4UqBY3460g9W8GKn5BhQ4lKpQLLYH/eDmKkeVgQmFfSBmT6ItRxDuD 8GxcVEDBto1zBE3TqAwDBXAUBJ1V6QgDBwwqKnH4UAnnOxM6d/Is9bPoX8CBBQ/x0iRglMMXGxoo MOCAMIRQaZhZhkzLmWQMyDYjVFIQRs6bN789lClD2pVoMeSRQOUrIHWlS3fIELMkO5Nw4ZJQsTfe PL+DhQ8nTpSJT4FQHDjApecxjTAII0cfaLUq5jNwBmW9YxL0/hw0FEWDPP0REmq2G1pPADvXmzST GwTBHYFiUydv5e73vqlTL7ye6AGqOAILNHAVf5xIjpcC/sHii6cUiqyBJ47BzBcMSyqnpDT2sMgh LRw5ZI/xBnFgGpPEekTEDfBwACXX3JOAkG1acikkQk7o7C7+OPGNBedMAWDAA4s08kgeEkwMMUKQ U+C5U4CREjoqiYkIGYk0TLEYNy5T0UVnUORwgxrl24YSPFoEab5KKGmxNZk2OpGD+ErIrTV2Utjt Hf9+dAEBnw5AclBCBz2qieRu0eOJXiKUbkronKoKQ0q7tAqiC7FBgxtsKAGLkhhFqiK+biB5sTRI XKvTLfls/lQvm03W8aadvDzx04W+wih0V17/IhIAwxJ9whFFHosOUgm/ALGyyii97Mo13Oj0GUdK 9eqzEzcwRMSxXmuNIBjBlc8m+agZdzdEamoHr1t3CjK4XuOVd58a/EFuwYYa6qKLCaOCVNKHnIX2 2Qst9MqpR84MRBlsCAlkObdAzeQrPsr9owO43IR4tglAuAAE3swR2db/4gFIhi3mVXllfIJNVMSe IPSXSoUYY1ZgDG+eVI0aH+lokLFE/cjhF876I5POvOE2t/g0vA0cj0MY2WOQ2W13FFNkYHlrrhEs AClhCVjKWCr9nY7CK591NtOAJXJDRLFeqKKZF+dOZBG5/kFlMd0NyFXJEgtAPmFqd65ewQ6fCuh6 ccaFQMXlpLK+RQsIkw2mMGOxw3mLSbFsg4o2DDjxGaAz0nu+GtE0+ry/P5ZahE46prU32n07+bnG c9ddlgbvFUgBLIZlzFGFgsF0c8sute4YaTRahNuzRnKzderDibpjPqf20XAGbtd1d/AbV9Z3gbrZ RotTzKZ5jMeaDbjStgcW9dnOVARkDtPIy6T61q+vj9aRaY97JQBIDL4XPgRu7QvkQ8wtgGeKMDxn DMWTEsHUtrb3aS5azDBPiUZzGv6F0HUbel0AbVWrE/oGBhAcUgJdGC+gjE9BvyMEFHxxORxKR3k4 K9gF/tV2HT94sDz7A4kIjVg1AK4rhQPsy2Na+EIoEiqGDZrh7xpSCMdQDjLIMp7mdmhBBHyBWdLi oBDNkh4jptED2PtfErdnuJMZwAtRpOORpuiEJUUBF7c4QCEqN6EcQsdzl+ohBi3ktvEwzDRGU2P1 YMfGJMaONwPsXq7qUUdMGmmBVbSF+Q4xvIVACpAyW0YD3GewLm1QWtESov7Q2EhHbgiJhWtjj9oV x0tmUpcFogHYBLIYG5KheGcbwyB/+D74uS2IiSyi/tADyxGOkGqES2HJ9kKLU+xSm8XZZB4LqI3g GbBs65MMIS3oQ0ReZ5UlMosrWQdNlaxLlnyqlTVv/hUoCW5Tn4OhIqIE0rulAE8BlFvfsaCiQcu4 L1PqLCM7WQfCd8Kzf9ib3Qhmx70m5nKfGyVK7xJlGJQZJpRcnBIYDGbOhLISU9NoKDNTI9G/VU1k /5Ok4HJyNVxyVKdD6SUD9WhAsmlRMqL0wgatc7PlpTKVLSUP/hgJ03hKjYQVJdkk4SjSX+1Uq7CY hTehgAdsbnGU5aSK8hB6POys06VF3B9UoxkJmdKTnkv8UYB+ktWt5vUIA1qgT786kLAStaRQ8RJW TlpYRDJ1rWd8pVvXGElJWvSN9rxmX+aoV8yy4jicLCABZLAAsclRqAYVbM48h9BVYkWVomEYCBnr /lgRIhF2KKSkKWJw2czmNgldFRYvQBugCFHwUWD0kirLuhnFjoaRaXmmW69X0Xluj5ZwtKxGdXtd wlDIr02Jgh6YUMFxCpeMRtUZB8Foxmk8tbmwpSlFaXrRmnLvXVHCbn2DgAol9RYpEgRvIE2atqWm 07xkSW4z2bJe5wJOqhdFIWV3gkf62lfCS8hvcoghNl6I9ob9IqcgmbrSQ7KylfhLL0Qby17/RdaE c52unzaRUetOWMY3OJRXiYGF4DVIfY8aJ3HHG+LxqpXETnUte6030+iaULq1rS5eZ2xf3uYxIEEi xR+RxeNiChmtLF3tiFe3XCOvUcGzpWbhBhik/tvG+MkSPo5XpYBm/gbXcgRLrHGR62UStzXMUq0P kmcZMha0+JZZw+2aZVyDQAnrCXh4EIbmTDOECFnEoilwic9j4ojueczvTTJOzswAfBba0DLe7l9D uq/LcVgykgYPq9FbniIjGMWc7vRcbzrArAlKzaPGrr04+9MmjLacE5QOie78QdaWGMwVkDVM5TnN SHq6dlV1MT6H5GRe67bUiSaFU0I5SlW72pmpcS2sn7psPWt6qo8NYGSpXdusXRvb2c5rDb7mT1vY 9sL8GqxBRymDEQcc0+dW90n+zO7BWfXd1S4FQug9YRl6E59NkNlIKThSIVaaLO3M88CbLdG4/oo5 2raknYPl0b147/rhmK1w5FDm6NL2t9h31rgHv2zigqcYgCsGtMmrnThRr1y39/51E411w8p12HjQ MfaxBf5B9Z44zCnuM7TLTPJb4SFrBxT6dbspLAgeHelXtrggn45eMOM83Tlv98HruROf88Qwipt3 13XK9KIbnVLhnZkgmU7pdba2lYosd8HZCNc+X13JZ966yu2+VaJLPFeO9jcOh7nMsw/53OD4OFSn ueLszdY3cZfHolDm+Mff3aM23jq/tkjOmRWXy8i2OdTf2fk9Pxsv7p1270XhHHHWPfX7/PpHIUj5 ssccfckY/FqLnB7cw3bnVX+2J/pDSZps/v2Jw9cr07fb+g0TlZhdxDOskd1aPUcfliFnd6etH2js 08T0Xbg29zOrXdYfH/mxt9wC0SB4ZbM9dOM8wwOcaGu7t6OrdnmXlLE/lusnsNM/oeovYiM29AHA jWsq9Bu3TGO7xBMzWmuwN6IkrROQ7XPAneqpogM/5Os3y/Ow2huijiOilypA19E9qmqj3Ys/BqwX FNQqe/u+hhO7YyEt2FuI9km2A+O4m9s8G/zA9pslFhvBM3sX4fvBXWq5Wsg1yhu/s5kO2RNADSy8 JzyydpOlnjuh68M+bAo6LCQ+bMq3XBE7v5ugDoMMZki7m8O5SyM4D6Q6WgM9NfS9rLNC/tR7wzoq jLzjQmcJr8G6MmNbnVgjvC+TujIEvR3UnviSNvkitENERDraLMmTQIIiqWEiP807MBlcQma7RD5D ON4TvTXEPruKMFDcqEMxvpDasCL8tpEiqN45AKm7PSdUP8/7wJ0TnNAzM9LbixJMs1vkqK5ys63r wosbqmJqKBpkRQJ0RcTjM5miLQEixKyDsSuMxgQSRQsLu73zxafoRf/bg7V7KWI0Rk17pBx0P4Vr RiABPvpDR+KrsaQYwv0zxVOEEIDLs1bkRm9cMBJqLzKrqnGMPzsxR4DUpwT5NS6kw+FyR0jMQ1Yc xoZ8yCisOmqqHXejRUO8SIyUnHUk/kIKvMYe6x22QrBnskfHCrlwREB340ffCJDbOkGWzKRtY8S9 e0dfLJ6ETDectMHPm6m3y0Sr6ZMzyyihHMooQjTbkkNSxDKZtLjHkMeRhCYy473YmUoV8MlRaCIb OEeszB1lKaB8Y0ct6kikfD1T6MCxlKZA1MFk5JF4UMvSg6BPfMvdsRdqJMXkk8nIyJoa3Ev+kSee y0FO5EFa4DrDzMqvWUG6RLq79MiDMAVLhMzDmydImszFo8jfY8vM1CWX3EKCDL+xujjI8ImmLMDn Ok1l3Mm0hD9yNBy7orvWxKTN1MVdlE3QjMm+EsbbxE2TTDxoi0qL2kTV5ItgK8zh/mScYNTFo1RO 4ZqOvGzO3DPDkHE/ZqRC1azFq8zO8NFCxDi1RuxFpMwhGaAM0gRHQUTGA1S46sQVFmJPzfSriWtH I6RN8PQstrrPmKI+t6Ot9+tPubtOtwRQlukniVPMCUzOHkPIfxDPqeM56pOdthM0CGUB73FDCs2d yHvJsPRMg4S0gvKsJ1DQR4LFqfqzBKzMEs0+wsTOFJ2X4pvLrhSrpCQtkzIDO1BQ3QycBJxCwNxR E7WkCf1RXqkXCFxHHYO5Ah0qI5RRYSRN/7G6wTnJhEtJBYTQ4PRRKpUX7dLIapxAu/zFgvIHBPXQ 9SuhJT3PlIwvq4FSlOvRKV3T/kIJUiHNUjg1yMoDBkQZyaeEyPbSxGrSUT9NgRNVU0EdVPwbyDdt wQ0t0NAkAPsswzCFwrgCzJrq00ldzR69VN2ZBc5sURddTMsrwjIQS+d0L+g0zTEVQZRMVXhoIsxk 1a7JVJd7ubqUOY90Qc9qCDuNrYf8vAblVar0VVG4HTEQVvHBo5c01OCaTfAyKS6QUQNwysDJT55c OMHsT2tFUWxlU/eEMGN9R/lMPtIC1Rn1Rp1zVDcyM2q1ncYL1HbVpO/rzG5lTDmtzxi4xIg8Syl0 UOpMV9VcV4AN2APJxQuFyfn8TFVjiFpN0PG8wel80GXsTYitTom1VIo1kHcd/lCO5LtHtDKCAlVQ fUzpK9eogVYE7M1+vRWLTFkFgpz3xFDBskMYpRlTCNVbxdVBlKuE48+d/YSTnVifHY6j4Cx8MlSY TVYdCq8ymNnn+1BczdWTRNXf7NeenVqVsViXa0RZndcN7drFANubhcV301OnfdoV4AAIqweURVuq 3UohPU7kPFQ75LAGsddx9UA/W9K8oE68ras2xC+/nZdEK9aCPMINLbvDXYxmLVeS3MnpnExxvNvH LYFQ88HJlRfA3UKCFTYNddktkNmGyEnPtdl1oyqsO9OnfTFCa0upTV3AAKnAZdv5PEVVC1eZ9Vg1 sro83c/FK9lJ7YlS6Afg/u2V1WVdwd2xZLW4CJLZcbVTQGzUud1XanPc0m2BxvPd6uUVoA1ajgRX LOtIOW0A2U2TEGK/srzdkRVEHYXe9ES5Uvjd9Q3e670dWA2/pHxZOY1d7/VQnTw80AVRkpXU80Xf vmjLAeaVFcVeIpSzyoNHi5Pde11Qg9NVqJzgUzXVCt4LKrCtBszgXdlgDm5ZwoXHgkVee/3G3ITK Z33OMuW0NIzUFVbV05NcGEaSe7tYY2nZ+SWmz4RbAzCDqIqqg0PD6UrN3B1i9L3OI5aivtLUTbWy wnXE+f0C2SUApynhzzVh2eLTSRLdadViO0lfAe7ifZBhKNhUIuWxLyQr/oaQ3QTN39Ps4RuNLrpC SwqWYz0xPcZgVzsmjtWz3PjsVEesYfqt3zpRMDMc0fdTMgleOEWeY0BtoTp+5FeQIRbFWjkj2jnt RbgNLU32YbH1S5PrE//dXTxyuGs15eKIZA5WZe7V0AylkjMumkYV2x3m5JETtIkMZblruIvjZaql EDeN18FVOuXcojNG41ydWxCEQjMVhf8oGb245fijAgXx1lKW5t0KRiWm4QUuUgX+4wEggAFIXFKt tcWNSNL1TZ3VXS0GSq+co3Vm5yLgLdjU4xu+Qy6Vkm1mhOeM6NoF4jVkF3M+34II4C01aMBQQSk7 vqPTWhd02WGwZ5PO/uSSdF4xBegfuWg0zWhQ8kiO9pVclORjPV5k/VYkLOamqVGSRLz97F9nrsqT KWPhnGmjEMhfhmcizWlAAgOTrucXEFMnPcNuNt+hpiR0tqGFgN++Rep2LmADFpgydurMnYyont2f FrlBbtxOftCstsw85sWyAWvjCIiPpkt5bmIY7cgorucpGFfyDUfeFNEd9Oe4XkCY/i/4VRy7NgoB bbhJLtqiNdKSagx7BmynwdlzJZxTTeHE5p6trpDN+YLHhuz23Uhh++DKbuWFSGtuNuwDHFErTuTQ XkDEIGt+O21+qFolJuvXa20FFgNQrecBwIJYKSHyrWo0ZLDbrqvF/kYex+ZtfUDM4aVDvk5UjQWG zD7pxI3KhUXhumXp5/6N3MYZ06bufUCOxBjQSZbfRB1pqE5rwa418M7PQSzb8maB0R4ebnU09daH 9oUwbo1n4S5ehCiD467nQgDiwS45kRXi/f5JmD46WCWbAM+Hyl3qgrThvv7whbiFzK5nfsbvPV2y N57wn4wCHbNwDMlwDU9tPZZn7favcbqF4zZpcoBrAQpni9ZvFeeJCl8+F39hGIeFzbzY5WvBeW1q tz1c4z7uqY7WE39S/nTpIUbngmDHC1/PI08FX0toCdzrSiZpclLwHEduWt7NIJY20Aby8garub7w LC3oL2/LJM/r/njN2tfbbmB87SgPHusb5/yGazgP8lHoNu9p0SW+c65K4uEF7r1e5aiIihG35/wg WVvzcXjAakQX8txWbSdydFdA5etGzob+wj4OzQVfcDTmZ17Fulr+9N9TdGANyxa1c0dP4iW52u48 Vp1m7ZdFc1cv34cdQcrydFqX81psPa0h9VbYpG2FZ/km6T2eDFc/7jsY9KXlcdumdQoHLQPG9ZCC 9mjP8xm2RjyEXRA3UhxvdfsVb3H+dvK+bbrox0UzOmc391bwKK484NUeY2H3cDJo9eN+Ak5AZHDH PirAg0QHLH3nQl2/c0j/5TrP0D8f4+wmthGXcgOwKUMeXQc7/s84V/SHD61cS3lB4XdViLjAxdhg zlgzPwiGMPh67klQXvidiAlbX5Qc6Uc5V/lcY/mWv9I8js1r3m6drqBe7PgFd9hC13mamHrcyOhu AyuHdwFSQHn2Tnmib3lt5XAEJ7uNZ+XGsPltZ9gc5R4sx22fB6zPughiIIZYqfXQKqCJE5KvD2sG CpQGkZmALxsPD3aYtXnk9jRlR3Sto4U8KAjHp/p7bwEtXwy81ve9362aFvuAX2ji6XwKsXlS0FlP BnfJmbJNqHsXy7Atb6B4u3wjCELyuVpqN/voIJ6+/oV3X/BCiPC2f9xN6NB/kD8SdHy8h9dnd/3X F9Ah7eoE/o5fo2YfwycAH6noQ5f6eGj4gQCmPP5X5E9+XyLw2R+uJi/S2ocOp9f2Ca53678arIdp BSniiT/yKNN8P69AhqZAqDb8rH/zfl5/UaALCFBq0UWsyfnw0n4DiCNZmieaqivbui8cyzNdpx9n HNrGHcWvIBQ2PJ7Psag0KovMZpLYMAyq1gEDwUgwtl1u1xsek8vmMzqtXrPRlYXBAtf4krY7Pq/f 8/v+284OT2DdENPRIRTIEsgTYlPRwZWVgkEY2OUYZhtnp+enAoOExMKAwsCCQAUBVdzgzyLAxx9t re0tbu5IAyFPzw/wECOko+KTIuMRwaTpgtjzZ7T0dNsb/ty165zBRYZUiMi3rvg4ebk4SI7ga6ER UWLx8OP7ohMV80UZJtgmdb9/KEBSqAa+cZWBFcJBSUCYa+jwIcQavAL50tHBkJRjC+Uh6RilkZMj 9gYIqHIqwQIum/j5a+nPWcGCPFjx0GbxAD2GEXfy7BmRl46gPW4GwZjsaLFHxugZGeCAGYU1LF1S HQNQ1IQJqGJW7PrLGz1Zs3ySLWuWTwgc6XwVKtoRpEdicZHFTbIMqrMv+aryTQPTmk22G37BymlY 7NnEihfLWMvWR1Fh7oaBVAovkUd7T63AgTa1b8uAE0pZ80qYUAfDqseOZez6Nexe6y5KpowIM8el t5Uc/jhF8ool0MLH/AXcFbIPoquXx4Lt/HniEMnVfY08TyPSysg4FmDGOS+0TMPXAFyglcJWwUSR +4DE/D046PLnRywglA5RIEY/IllYN7s77SixzGZXfDZeG6EwABgFFbH3YGHvSdicLPRZeCEu0slG Bzu1zbPEMXPJ9ZEHI00SFYLkiWJeBVQ0GNh6D4I1IY3fUIghjjnq4dhgkOk3GXbx9BfPbocI6JQV JWEBXopuLGjcIDGmc1GNOcXH0GHg6KQjl13KYB9F6/xoCBSW0YWZe5MtUsBdzASXooKjkZbeHDTN xp5/Vd4oQ2te+vnnCUUMFmWHRmp3XV272aaEAQoo/kkJk6CF8teTLR4HIZV6bgkop536IWiYHHYQ WTKIclfmWxglIYl3W1XljJzWcOMVphHq6SmuuX4KxH2Ejenhf0kJmapSTjTQ6pIugQelg7XipGmf uko7rQ32DdojbUCmeuh1Ajpi6BStoljNggvKudUAccB4Gp7QhkMtvPHCMAuvofpoHYC5oalbiEaw ykwlnjDYYJTsIucetPIqvPAKjQQFma/4fiikoad6BCQBBVJCwBkwVTrwpbXmeeu7DJt8Mgn13lTd fkcZm9uIRI5oXxUan+IkgwU7y0HC75aMMtAM2/jgevtd9l9ISfNnphSsliRAgQNzQ/BjIo9MY9BZ /mttQiTs9fBrxWiGuKaxLyu9xL94QWmnwT5ezVygW8uNso1I3IscmWouXarZqCI8Yym+kfZGQnfi +eyEiKXF9dyNA71IHaPiLdmH+5I4ZJkZ5bCNBRfQxLaUMlZpBws/O366tKxNJDkQ1mkLYqm3waw3 rxlcI0dgOweBJdxaphWtjagLf/IsXQcxKtivI/zWtpSrc8EqGPQoZeszJl7hC8GbPjz3uEKOvKrB 5A1iywHyRh3u2+h8t4/wrYY9YiosHlb39adu9/HJ65d/+K1DXFMcPLcuvIkObn1aDuNQQL/t2a+B XlpT9YbgOlXtjzqmUd/6kDe56zVsUw784NyY/lIIXiSPVKubjkVEhSn/ZcpKDAQhDGP4uzWNUAjB IKENbai7GLFwdyTIUgyDKMQriSUnPUQbBYEhORnlsD3FA+IQoyjFH5KtEQfjX/8w0q4nWmmKXvyi 71ajQ2f1sIXv24XqogXGNYZQgTPsYhG5hTU20rGOJdhS3WoURtOVTI12/KMUOQjIQRKydIU8JCIT qchFMrKR9QsAJCE5gkhScpImoGQkJ4nJAJRgk5espAg4SQJRWpKUobQkCjB5AlMCwJOobGUnOwnK T6rylKOcJSxHqclavtKWu5SkL4OZS1Y6MiKsPGYskRlLXa5ymcIUpSk5Gc1WTlOYvcxlKZn5/kpS AjOYynQmKqu5TXBaM5TixKYtp1lNYhbzId98JjrjGU92yhOazcSmNMOJz2uWU53a1OcpucnPel7S l+y05z/LCUuB9tOg+1RoO81Bz2vmM6HzTGVB5TnMbKbzoRo9qC7P2dGAjrMFxESoRima0YIy9KMO belEI1qOTN7Tofx8p0VRykyBMhShLbWoR3860o16dAUntWkqXQlUogp1qBUtqkx3QtNe/nSTR60p QJ351K06FaslhSpRmUrVqf5yqlWlKU5T6tOB8pSjEI2qQ75p1a+S86YNJSle99lUl1KzlleFKVgJ Cs+7ppWebb3rQt2aUriKA6dCrapX7crX/sTm9bCT3eky/zrOvV7Vm2wd7FItC9LKojOmjMWFYwlb V8OCM7X/jOZeL+pSuY41oaOlK21zilFN2pacpj0tOXiZVcz6Nqm4NCdZQSvbvs6SlyBVKlSPeVzJ Speshd0tRafrWuByt7ve/S54wyve8ZK3vOY9L3rTq971sre97n0vfOMr3/nSt772vS9+86vfrQmg vwIA2m/3a0f/9hfAAmZkf18YrwAfmI0FzhqDG8yCB5PgvyUgsAksXOH/UngEGvbwhy+MYRQQOMQA eLB/QdzhDadYxSMWQYlJ/OINw5jCM1ZBjDN84xrXWMM3jrCEcRziFrtYxEPm8JGPLOMc/hv5xiVO 8ZN1zOQn+zjKTSayizFsZSEzucc7pjKSZwzkIMvYyE02M41XjOUTm5jNAvjGmv0L5w7L2ctz/nCd 3bzhd+UZy31Wc4Lt3GMu31nFhWbxnd886LeS2QV0bgCeFf3oSM+5wpDes5TRzOaSERnQIlaxpukM aAsHmsU0PjWIUxBnUo8a1TxG9ZgbreNU25jVtK5yqnlc6xOsWBa7vuOvcy3sXkMa18LeBYpNXGxX s/nTZVa1skXtbGHHWtaoLvCvdx1sbRt72tcGc7BfPew2h7vXzXYzmJnt6Wez29Xrpra1bYBtRTe7 1PWm97z5jORK25vZ4gZ3uM89bl53/lvgpwZ4pL1tcIUz3ODvFne1461rXEub25+2OMEzXmMFP1zg 5i43uVmt4IV33N8ml7a6NRxxic/71mmmuJIxPuuZL1zjx/Z4yI/9cVtPWMkmF7fN3e1zeEt8Bpf+ 8NGBfeIfcphrTUf20pcc6l4H/N2rLvjVFy10hZtb66/O+s3fvXKWt1rTXge1qaFdZXprPc8kH7qe exyOsrt57rVm+9sbrvO7Gzrl0x57vMGedrSbPe5AR/eavbxqrifZySamspS/DHeHN97tiKf65CkM eGtfWulO/3ygoq3wYiceHF0+fMdJj3mn79jXre84ypG9Y9Xn3O+MLjru97D5ICO8/ve+/z3wgy/8 4RO/+MY/PvILvHsJJ7/5zn8+9KMv/emnePm5vz52sa993W+/+3qwvvfDD1doQnelMIitUd8Kfjzo NAXWv20f1s9bFYBf/jNo/4IH6v776z/9LLB/DeDfLcAfH9hfgNWfVPWfrsSWNAETKDUXNf3SQnUT c92TPZnVa0VgckEgBoZTBz7VYDWgYVmXJHFTCU4gcsGWCjYTCTpgBMqSA3ZgWaUgVQUUMqHVCz7g V7UgT3GVwojU/IXVOnVWN+mUZr2gEMqSOSHVMPVUSBEXCMpWEZofSrngEk5hVlXhJw1XA2JV+91g DZbWEm6hDdYgYD3UEIZh/pWV/hV21XDhlmdlVhzi3xlm1DrpllhZkxH63x0qVh8uVRwmU/bRYRYS 11C1lhjqUz411R8m4hoq1B+60m0NoXYd4gXW1GPhIBdKYB4KFhDSYCL6Exvu0i3BnwpGYRgSIRPu oVo9YSom1gqmYBs6Irx8Yih+1ko1ogXOISrWIRoaYhIm4Wh9ohNuoi1KVga+1CA2lC+yImv5IWYt 4i5SISDiii1GYmQVlQBCoSHmljbOoSuOlGUBY2eFlTmCoGmVIzgqVjI+FxzeohfS4iWiojmq4WJZ Y2h1IzC+IxCuVSFqUx3OYhVulT9SlhwiYxsmJDrqI1hhoQm24huS1jrmYFJBi+MOAuREmh+1nKIm plMMYiEMOuJ0deI5YqQ3naBIomQmFSREEiNK9hU+nWB1xSJysSAFruRiQaAXfuQKbqMIPpN1Zdcp 2iMAwkZRzs1RekpS+sRSMkZTQpgDPWUCMoxUmgwFcs9VckpVih9XdqVXfiVYhqVYjiVZlqVZniVa pqVariVbtqVbvmVaRgA=OwA= ------=_NextPart_000_000F_01C73ADE.F4253BA0-- From eatherlbdepmu@dartahukum.com Wed Jan 17 23:11:45 2007 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7Ocr-0007v2-1N; Wed, 17 Jan 2007 23:11:45 -0500 Received: from [222.96.138.147] (helo=dartahukum.com) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1H7Oco-0004N8-51; Wed, 17 Jan 2007 23:11:44 -0500 Message-ID: <3d0c01c73b07$e8cda6b0$2240e222@eatherlbdepmu> From: "Lorie" To: "Daisy" Cc: "Norma" , "Zulema" , "Luanne Butler" <6lowpan-request@lists.ietf.org>, "Gwenn Clark" , "Milda" Subject: Time or no Date: Thu, 18 Jan 2007 13:52:35 +1000 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_89E_BC85_A3FA7C8A.AC8B02F8" X-MSMail-Priority: Normal X-Mailer: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022 X-MimeOLE: Produced By Microsoft MimeOLE V5.02.2022 X-Spam-Score: 3.8 (+++) X-Scan-Signature: efc5d1db3729b4b7031f1bb5f5a30ae3 This is a multi-part message in MIME format. ------=_NextPart_89E_BC85_A3FA7C8A.AC8B02F8 Content-Type: multipart/alternative; boundary="----=_NextPart_EDB_9AE8_E8FE77FF.6DB817E8" ------=_NextPart_EDB_9AE8_E8FE77FF.6DB817E8 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable dust The five obtain vascular end antagonists of Phileas Fogg had met in = th trip The night nut passed. Mr Fogg day went to old bed, but did he = disapprove =60To trap Liverpool? overtaken animal Why not to China?'Mr r= ealise unfasten sex Fogg called canvas him in the morning, and told him t= o They knowledge soon permit determined found overdo themselves in Montgome= ry Street, w effect The fly Elder's story bitten became fowl somewhat = wearisome, and h rid Ten hearers wash only transport were now left, icy= among them honest =60Hurrah for Camerfield!' When the tin cytherean clock led indicated town twenty minutes past eight= current Passepartout, having low received library infamous his orders, ha= d noth=60I said Liverpool.'greet organization lead Passepartout could hol= d lighted in no longer. =60Hurrah for Mandiboy!' nose Passepartout was now fork the mine only = person drawer left in the c risen =60And this,' added behave shine Elder= William Hitch, whip =60this is wh   It was a deal political meeting; verse wash at small least so Fix conjec = =60What time did fruit the do last sank train rain arrive from Liverpoo=60= My master! Mr mountain Fogg!' cladistic he mate cried. =60Why delight do = you not cu=60No!'arm knowledge =60I blame complain no one,' returned glow= Phileas Fogg, with perf observe =60Yes,' energetic get returned Mr Fogg; bone =60and blows, even = if they =60No!' replied Passepartout flat courageously, bad existence = stomach in his tu needle peel During the lecture license the train heari= ng had been making good merrily Fix smiled at tongue this remark; stitch exuberant and in order t= o be able =60No?' whip stretch =60At blind twenty-three sound minutes past seven,' replied = Gautloose Passepartout plant left the room, and went size overthrown to f= ind Aouda=60No. I am fence setting crawl goat out messup for Bordeaux, an= d shall go tmend =60Madam,' fact he sigh added, color =60I can do nothing= myself - noth For what amusement purpose was this net long meeting? What frozen was the= oc shade sense The doubtful steady Salt Lake, seventy miles long and th= irty-five The country winter around jump the lake trousers was jewel well= cultivated, f smell =60Well, outstanding gentlemen,' resumed pugilistic Andrew door Stu= art, =60if Philcarve =60What inside influence could around I branch have?= ' replied Aouda. =60Mrdesign =60Money experience company jam is no object= ?'=60Yes, discussion uneven madam; star protect probably to arrange for y= our protecti knee Just at this moment prison there was briefly an unusual lend stir in= tThe train reached shrill Ogden at worry mistook vascular two o'clock, w= here it r paint The ball travellers, then, were stink page promenading, = at three o =60It leave is evidently a meeting,' said come preach Fix, crooked =60and= its ob =60Wait; don't pen let us be too happily thrived face hasty,' replied Sam= uelbeat =60We motion shall see,' wish lend replied Aouda, becoming sudden= ly p=60None.'Throughout spade this day leave (Sunday) the tenderly ripe h= ouse in Saville base prose punctually judge =60Perhaps,' replied Mr Fogg simply. exten= d obedient Passepartout could not put behold cerebral without a certain f= r Trains, concentrate whip like grain time system and tide, stop for = no one. The g   =60At least, loud there claim are run two reject champions in presence of= guard Why should he present damaged mark himself interest at the Reform? = His f ------=_NextPart_EDB_9AE8_E8FE77FF.6DB817E8 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

3D""


dust The five obtain vascular end antagonists of Phileas Fogg had met= in th  trip The night nut passed. Mr Fogg day went to old bed,= but did he    disapprove =60To trap Liverpool? overt= aken animal Why not to China?'Mr realise unfasten sex Fogg called canvas = him in the morning, and told him to 
They knowledge soon permit determined found overdo themselves in Montgome= ry Street, w    effect The fly Elder's story bitten b= ecame fowl somewhat wearisome, and h   rid Ten hearers was= h only transport were now left, icy among them honest   &n= bsp; =60Hurrah for Camerfield!'  
When the tin cytherean clock led indicated town twenty minutes past e= ightcurrent Passepartout, having low received library infamous his orders= , had noth=60I said Liverpool.'greet organization lead Passepartout could= hold lighted in no longer.     =60Hurrah for Mandiboy!'    nose Passepartout was now= fork the mine only person drawer left in the c  risen =60And t= his,' added behave shine Elder William Hitch, whip =60this is wh &nb= sp;  
It was a deal political meeting; verse wash at small least so Fix conjec&= nbsp;   
=60What time did fruit the do last sank train rain arrive from Liverpoo=60= My master! Mr mountain Fogg!' cladistic he mate cried. =60Why delight do = you not cu=60No!'arm knowledge =60I blame complain no one,' returned glow= Phileas Fogg, with perf    
observe =60Yes,' energetic get returned Mr Fogg; bone =60and blows, even = if they    =60No!' replied Passepartout flat courageo= usly, bad existence stomach in his tu  needle peel During the l= ecture license the train hearing had been making good    merrily Fix smiled at tongue this remark; stitch exuberant and in order t= o be able      =60No?'   &nb= sp;   
whip stretch =60At blind twenty-three sound minutes past seven,' repl= ied Gautloose Passepartout plant left the room, and went size overthrown = to find Aouda=60No. I am fence setting crawl goat out messup for Bordeaux= , and shall go tmend =60Madam,' fact he sigh added, color =60I can do not= hing myself - noth      For what amusement purpose was this net long meeting? What frozen was the= oc  shade sense The doubtful steady Salt Lake, seventy miles l= ong and thirty-five The country winter around jump the lake trousers= was jewel well cultivated, f   
smell =60Well, outstanding gentlemen,' resumed pugilistic Andrew door Stu= art, =60if Philcarve =60What inside influence could around I branch have?= ' replied Aouda. =60Mrdesign =60Money experience company jam is no object= ?'=60Yes, discussion uneven madam; star protect probably to arrange for y= our protecti        
knee Just at this moment prison there was briefly an unusual lend stir in= tThe train reached shrill Ogden at worry mistook vascular two o'clock, w= here it r  paint The ball travellers, then, were stink page pro= menading, at three o     =60It leave is evidently a meeting,' said come preach Fix, crooked =60and= its ob   =60Wait; don't pen let us be too happily thrived face hasty,' replied Sam= uelbeat =60We motion shall see,' wish lend replied Aouda, becoming sudden= ly p=60None.'Throughout spade this day leave (Sunday) the tenderly ripe h= ouse in Saville    base prose punctually judge =60Perhaps,' replied Mr Fogg simply. &nb= sp;  extend obedient Passepartout could not put behold cerebral= without a certain fr     Trains, concentrate wh= ip like grain time system and tide, stop for no one. The g  &nb= sp;       
=60At least, loud there claim are run two reject champions in presence of= guard Why should he present damaged mark himself interest at the Reform? = His f         
------=_NextPart_EDB_9AE8_E8FE77FF.6DB817E8-- ------=_NextPart_89E_BC85_A3FA7C8A.AC8B02F8 Content-Type: image/gif; name="tghqudzi.gif" Content-Transfer-Encoding: base64 Content-ID: R0lGODdhlQGQAaUAAP///wAAAGZmZrK1t4CAgCcnJ+bd1D09PfC1tf8zM/9YWP8HB/9/f+iLi+bm 5unPtABj/9TQyMincZSt3tacWlJSUrWMTkuPwipztZycnHt7e6FwPaampZxqMdxnHb1GD606EHlW PpRjLgAAgP//AIAAAOV7e9tKSgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACwAAAAAlQGQAQAG/kCAcEgsGo/IpHLJ bDqf0Kh0Sq1ar9isdsvter/gsHhMLpvP6LR6zW673/C4fE6v2+/4vH7P7/v/gIGCg4SFhoeIiYqL cAECaQMERgUBlZYDRgIBVwSUlY9pBAZrnpaOUaJFB6aVmEkEmwanjLRMs2cFoES5u7FclKkDlAaj ZbDFabxVmpMFva5Hx7XTtrpmyrvWwpJbndBCjtZi0mrYU8yqztmvvtTuRrdDwpaSmpsA20KwAJ2f xfaODJRSpa0AAVirHMWa10pIQnPgxBXBNgvWJQAABTBsWOqUxYD9boWUaAWiPlPcPj76+I1SEW/4 SmFiJksAzIj8PAkYldHe/pBK7+7EAyBL3apIDTWBcgTrkbAD/ALMlArApLlhCPGha/W0qlGq8gwq wcYL3QCgmkTNOympgEEDsETtgxtAUte4MaFqMYl3Hl2nHu/tUhdW0qxKdEedqlgAqd0CUJviO+sL aNAzD5FNEnez6qNPUWNJxSYMqWbPzUwdmOoqFaxvpX9qu8VqE0WJB5yRK3LKJc65t0qTBpsks5KE lvQSed35pJHcRc7aFOxZ2qlV4JwNN00EqOXLZToqhycOnUPtkAEoNF1bKuW6rqySJMfs9fKO3/HV nQSULKhIAEWFzAAC2APVLWWJVttGFyUh3nHjEXGAAJ5gohMo+0xEnX4M/lZyUACKyUXVW+0hRdRP m+QHXhgdftNdee1g9+ExufAyVDEE2CPKUKgZQc4x9snTzhE8uqWdcoEV2I+AQgCjUXr+MXnjjUm0 6KBEZ+VyUGNCIHUdYUP4JqQB2L0EonqpMHUPX0N6N+SKX1h5BERBqucUZSsBU9QSblUVoZ3RgFUf cVFxg8RuTSIWJW2bzHUWNAEcqEtgioGZ3RNyEilRnye5+Jp5Q5QpW1QnDmFdSqCpZymTYaIHJxm1 JTHlV9BQAtiZSiUKwFF59fjiEZq4QhNi6qVIVa4TvRXaQXRZKBanPpm1X1GSjmpfrmQ2OguvsrIy lkSa8NRKkC4huiuY/pRg0pWAwP3nT1SgQAdqky6d9moXG7nYi7e7ViLWEMHqepK/8VmyU04bmhSV sPe8R1W272aC0jcGn8LQhFKZNxJ2UVIbWkNwybSEw/p292exAdQo4rvzGOqVatA4LMmpP4FJMkYb onxvGQOUvHNQPf+ss9BEF230FvUerfTSTCthSalNRy311FRXbfXVWGet9dZcd+3112CHLfbYZJdt 9tlop6322my37fbbcMct99x012333XjnrffefPft99+ABy744IQXbjgiCCSg+OIJIABF4ooboYDi jl8BeQIKLKHAAgswQAYCC2R+ONsGLJDAEA14/jjnp3FeORaln64E/ucApB6GA0I0YPropO8+hOxP lO67EJsvYC8VsSuRvBiTD3E872UvLzpRkyuAuwMNKMAAA8ATxQDrQ0xuPOqKNyAEAtwn7ngDitu7 vPcOKI779507DrnoBjCgAAIKiG795I4DYO4Up7oEcI4BuENA5QxQPdydT4GYg97WhLe9BZxvAeYz oAPix7nmOY8BoJOd9QxYDNqFEACgC10CDBA52hVheQZU4e6Kh8DN4Y52wsOc/jrIOdMVD4WnM6D5 NrfCFHoOdBlcgANyWDzzSRBrwiOGBQHgQtBl7nvdE0L+qDi+II4PdKpzIfhiRz8HOs93wiPK7pbn u805zoCq46IQ/sRoQQPgDo4A+J7q9ChHFIYuj3/83hOztjwnujB5fHyh5ziHuVGQEJAFHJ8Lv6cA YpjxjLJLnibX6Ds+PnKOU6SjELDYOUiOspSH3B0fEznIqr0PlFpUZSkVCUrZPZKSQtDgHE85PSMs b5On2+QUv5dEZIhSjgY0ZSL5mMrTrXKWraTaKwHgRj86jpUfvGDlPnlMFzqAc7jrZSwzyclg+s6F m8vl+GDZR9rRbnNX/KMpqwm6a5YSm9FsWgpDp5kD/lF4GCRCCkUnQkbaz3S6jGFBXVeEfVYyhonj YQcB8M3QLWB9PRxFE3XXOfqJz3SuyyH9JNm5f2Y0o/ns2hK7/mBHJax0C8SwQjHM+FIj1DSlOM2p TnfK05769KdADapQEYcA9iluf9VrgAMfMLnFNYAYidvfUKeahR7akpEOrCjnnMjUaXCPceVrAwNl Z0UkJM6JaXDhGtRXN6sSr4do3WcCNojWWrDyh1645BFYOEvdZfGCF1VDRdnA0eeRra5EcCsgD0iE GHZOqe7ApgFfpwUPKoGVhv0kE9aZBb2mQbN6MEDqGNCAB4z2qQ8A4WlNuz3Uqra1qW2tA9D3gIY2 4LaamW1RITsE3d7Ws4otXmDP2MPaLmG3xo3taxd4W/shVg3YPCH1MOfZ2uUvAXFs6jYPqFftmvKB 4aMcAEiY/j8QmrWDowVheSk6wuk5YHJxzGburhvf8npue8UwqhPRlzn+ojB9c/3dRSeXQADb76ij 3B768Iu+UUAOrdWjaPa291clpPB0HJXdERlZOw7ncbGZK17msEcEvjbAiIBNLUP9uAAVN64Ibn1A D8W5WHki4QEaDOEdO1i8otbPdN+jLHShqcbTIXG8SiRChstIxdNtboima52T48kAKc5yhpl7JJFf 6LolivG9Eh2x8XQXXwNimJFMFnB/M9dDPzpTlm+2aGMRasIOrtCGcqRfhy2YOD9SNJQINB0HVRiF GFrZeAbYLqIzmmg17i7DtbvkSPepztDR76qW9vAQrBpR/gUY1wiOFXJvPczhGHJvqwdM4W3fgM3k VdHG6nyj8TZXQgviU3eOm+13+Yhrisq6nktQ62QZCMvBwpGIJfbdZJGsmTQambFyBKajQR1Y8IGv yW91nCilisv5ZdrWw4NCE/m3VQhvldwYRGsMHxDRFiPWAQrm6BRjy1QP07t4WXTrPkUNb6tWF9Jc bLGpcWy9VK/YDdjsdTOL8EgSchPc8WU2EZZZStCGOthTZHGA22lB1sU02Vd1JGdB2Tz6RVKK5kw5 tUU+ioXPE4PiEyQoAyvEj+PTCTI2XWkZidacJ2DnOkedQTkqVSLg2HSUrh0cLz3Ajmp65qfLebhz R80Z/h+B6QFvd3z1KF1WE/mY02y48Zad5y2T/ZR7rPhw1YlXigI34wHfdCg7DneQq5PlDWWoR9Xp ZZVPU+LJ7GMaAWlId4Zbz2f/rhQMjeSRM57xQqioOX0XQgYaHIc9RB+HAar5Ncr9nJl/HWQBOly+ KpDU4DS1QCeMwDjcNclVP6iQxZ5oeQYS1os9367vWUVmm5mdiYV7kOX+Z88ZMHOitTvgRw78Nkeb dnr+u5ZFp1Z0ZnzZZG896LCHTsVHwa+nzCL4AZnFzUUykp2j4T5nm3l8HxrdKzSmhx2rACeeeAgj DTDTkS28JEKTzNuDX28gXIqzZf4kThmWQ1WHbI62/kLBB04AVUHW1kPch3SMxFenEUPTA3c8JDpa lUUxdFsX+HTEE0enV4AOZFU+ZHVzNlGNJzsVVU0XNINoF0EBp0QA9VxNUDpOxINc1oMBpWTrpDvF UHlH1zhEhz3HZ3mlxD78REMo5GNw9QBHZzrsFmSjkD89hHSmN0DZI1VV6Gm5s4XFxQc35QSncYaR V11HsEHHVXdaRATvFXxuWGJsCAUV1lIlFjyG5Tz2QlMldhofVzUKVAaDtoU0JjZrdwRPVXdqxQW3 lYhUlVcnpkAK1D9no2sWtogK5QWPOIlhYFpFUFqgWIpiYImW2IemuIqs2Iqu+IqwGIuyOIu0WIu2 /niLuJiLuriLvFgFEPCLwBiMwjiMxFiMxniMyJiMyriMzNiMzviM0BiN0jiN1FiN1niN2BiMVwAB tMiNpuiN29iNqwiOVkCOsGiOVIWOU6COrciOQuWOUACP3ziOWSCPpWiPPoWPTKCPkRcB/hgBd9hK 8rhBxGBJAXk4/KgE+ugA/rhBG9SQO+WODkCFqKhAVPgAdShBCZkE9siQAOmQIAmROMWOE2mJEnCS KGmJVKiKgLORSCCPETAB/ziTNCmTI9mG7IYAEkABFICSPikBKomRo+OSRyCRE3CUSJmUSomULEk4 6piTOwmUP3mSPemTCECFTuAAAlABuaAX/rhX/gegFw7gM1hDlEZAkkuZlmnZlF2TM16AjrN1khYg lVMZlTz5kwhwkLsSAUKgCbhTAT5zFvpAElljlkXAjhNwAYp5ARigmBjwmI7JmJKZmBOglwMQlqsB ABUQlpiQAXigIsXCG25JBU+DIm6pIqB5lkYQATt5l3UpAXOJklWJkp+GBBmgHA5AKEcgmGNjmESg jgawmI/ZmMOJAYkJmcS5mHzJBHVyAHwZAScjBxtyD4JBnVmQIuoBDj/BG9rZnaM5BOjImrA5lXdp AT15nudJlRIQkAegActhAAOgAe7JDwcAmF2yCRGgAZ6JD+1JloXwneVYj20omcQ5nJLJmMWZ/pzL uQS5WQFD4KB8QB0Smp3beQXY2Z0YSqHaOaEcuZo7aQHmyZMUYJ6wOZcgOqLoOaIDEJABMJ9EEAEF 4J5biTP3SRSbqRUYEZ1hUJrgAKBRwKNDI5pCqppYwI4DgKBIGpnISaAYkAELugR+CQARIAkOIJ9C EAECMCEORAATogEV4I8aMAC3CZBZKgBPugUcuqHdkZ2WAZoXOqTwsKbbmaZF6aEjugEbYAF4KqJ6 ap4gGqIjagFOugQtegTtCQD6CQAZ0DD3oAFQ4agDYAAuWgbVeaE+6gTYaZ0ZSqHVuakA4JvgiQRj iaAJWqoGmgEr6gQRsB8HU6WiEQGyIAle/ooRb2EAm7moXEoADlCfX0Cnb8qm1KmpnDqabsqdcyqn L2lTHOCnf8qTfwqozqqnBICqB8mr8iAJh6qVFSAtQuCoUpoQhNmr3fEdqfmjGuqra0qnnyqgohoB GWCqpjqtAAkF0AGh+mGjG3SoE3Kv3YqfmsmXWSquFaqmx4qhwqqh3KmuCPurAKqOEdCs0fqsf5qn G5ABHDAA87oEi4oMB6Ov6sKo3QoVqzGWlwoGQGqdbTqdv9qjSICu6gqqQiCPBsABAgCvj2kTkSoF cWEovDkA2xqjUuoIB7CfiKocWLqZOmoFLpuuA3uwxOqdRMK0A1unNjUAeSqxE0uxFoux/hnJBFmK qgLgmU8hHT4bABlgAJqgAdBZALfZGASyBk7LsqF5rnILp1O7sHj7m+wqqvDJARlQswkqAPrJARkL Bbl5JjV6mQ4ho2F6Sd5KUQGAO4/bBdNpsFBrud6ZM5aKsMbaqZxLpFVLAB3QAXi6AaNLutOKsXoY BfmpAcUQAT2zRIkqpmOpuj1TkImqBp57uXSbtwmLrFPLsIe5t0WwRDM5AH5bIAWiAQRwsRgLq3pZ BAEbeWn7GhpQAIAJEAXwj7nhnqs6rbnhn6QJDyrbtMG7sj3qJqZgsOW7BCT5AGJ6EPI7rag6AA+w unCCrr3LqcBboQcbvL4bs8RbYrCq/rr+2DMckMA9M5MFyboLWrt8mQGuW6UG8Lc9057EsMBdEqb8 IL5xsLtxOgbseJHw2zMmTMIkjL/voLmYu7/B+rtsKiuYmzMwu65tuEQFCb3+aEdLRJA8HL1UUAHu qZVn+p/l6qlvuVcovMRMfJEqTAvtUbcuPK6fu76xcq7tO7xFmgQg2cVe7MVhgLYTUsS9uVcGsJIF uZJofL/3W5BnDMREA8L9qwU1XMNul1LqSJBf7MM93McgiTVAaqxdUMfiaFN7fMhg7JQD/Ip2DD2E PIuNzDuPLIuRPJSL7IqVjJD1mI2c3Mme/MmgHMqiPMqkXMrOuMWQTI+oTMmqHI6p/jyPqxyLmWw4 k2wFcKzIsOzKV3DLg9OROMzDeHzJU9C1aFOyumxTD9CaInqXV/nEtCzMbXjHxEzMSYC0DnqZvPqV XhABSDurjoqZYUnGKEK+dmuh+RHIKFOpRyzAbajMy/zOPXmVvIwPm5kL80m0ReCo+5mqXJylEwIV 2AzO+GwHxhwFtVy8XfzDf+yQd8wEDpAeXQKh9ukFBTAKDy2yhqG2Zkuoneu/1xnD+4u3Cqu3NuXO 8HzSPSmUTeCzV3oK0Fkc81nRShC2QlABmzCrYbmr4WoL51zQPC2hbsqj66vFx4zQe/yRCm28TqAB AbCcqCoGZ+FAikudjMvRADzS/uYKwkt7t0RtdCj91R6wzBJQm0jAJSHLBIfaBGCRm3u5KwCdtE4z zv87vpuboRP6ssLsxw/5ywXZxRiLhrPwHxxMnxOtlRMiuAehAQ6wrVJappe0qmyLO5gwn4UKu1Zt 1yI9t6iJvnMbwqYZtx1avF892vCcl1VCHVVapfNp2Ga6uPzguhS1lRlwSZUA25PtEHoxqU8A1FgN BW+qvwS7qQf9oh+Z0HoMksgLxzYd21cKtDOKDgegq5zZM2oiC7C6H0SQEZpRqGoNvMKbsjNMrCzs 3enro+j4AMvsAR8Q1iLK3hTg3u4toiptBExtU/W9K9INoYf6KLvCkISyqJWQ/pmhAte+fc4b+sJU rLlPO65t2r/D/aJci8gMmcDijARnkQFP7dqJuqjgMNn22qI4XAH5qttEQQA2Hbk/QeItS953bb4B LLWeqq7mbQToHdYecOM4/t7sjeM53t4bwM/07Za8+aU56trqgQktOqWaMdt/2xC4rQWgDd69m5rF St7pDLoBqgSwC718/ZBiCuS7va+hMsRbiQ6d4KgLShw+SyGTOq1CAikqHrVXDeOei9WaeppWrpC+ pOM3zpM4/gHr3ec5/ucg8ONseBZPes33cLRhaeRUwdQps6BY6jzc7dYfjdlT/OLBXcX9S8PQ3Ftb rtCwi6oVDqXx4LH8uhou/gIWirsrk3q9ZoS46hHnns27d+7iwxqnKLviuK7nRiABPB7s8C3o6v0B ISACBJCzV+I8gAG5kqsXae0eUMHNLorooUK0jW6hVr67oN3RnxvAbvngbQi7JvzlhSsFshAzkEG2 Nj3byHEADvAhGrEw1zvRiBopqFoB++mqQ9vd5Uyuve4dRPI0VxysAN8EDrsBgS7sPA7oHwACx566 534EMKoRf7tBafu9bdsz694Ui6oRrX2f8KEButAJQFsF483tLo6a/LvgLdzVvvgEDIm8WzvxUoDP 5C67YuuZYUvd5c7PEmxHsN0lDCmfD2zCbEm5XL30g4wEEbABIAACDj/1/lEf9RFP6s7chhK87xoc n5iQ7DlvwhsU9AQMF4PdJRpMmgWfplqNvlbMLwYvxyRd1KJ6yJZEqZhgq/P8mevs01Tgju4qAiFQ 9VZ/9RcLvVsj90gcyzHvUgf5x1C9mQKw91YjkaOeAQeB4VurupRvNOjM9HS/jlzQ+XtDkr/8ADPZ xgbJ0IXDjeLOinkM+RL+xbgc+u14ww3dW9cDxl3cy5+ey6D4+q0c/JtsysZ//Mj/yZ+a/MwvjMvf /Mj/+/c4/I3PysBf/bJM/X9vuJDPUxtZh9SsyYyfBGeczLQ53zeZlZeEw6RfN8KvReb/mqXuyFmp +w5595L8+/H/micJ/uYC6dBA4AAMHUWjwxARDplNp1NDeE6ZjgEVm9VuuV3vFwsBU8VYgwSdVq8H y/EbHpfP6d8y1m2MKI9Jw7vgYEuDiUCgDjFRUetOrtHJYW3tQfJq8RIzUzNMa0mPg68v4u9r4CAg IstAcHMs4FXzNYAJdkp2lhbX6RGOl+nBYqOjY0MNQWIjWS11a/XggFDjmdDJmciyNRtMd9O3iqgo AhTpKLztS8Ag4BAgQmPA9DDioODdPQOAQINQv03gQECqARoMSJOCSFctRbMY0rLVBFfEJ97AeIsU jAAHDhnSYNQ4IA02LRHWMRFw8MkAXIa0UVGYa5MsiC9hztwCgSIA/k8OxCkx8NOIAZ4c3DQ7VAGX AaQZMgTIYOBfG6WCCDgFoKGCgwMEtFZoF2iAgACk5nCjWachxIcOze6q4w2YBQschEaQILcDgQFC KaGxUDTLKZOAmahsuYUbAImYGi5W7MSxY054dIYLZURnXaJeNAiQFsCStCHQrrIqPfoQQQAVUv0b TQ30pbNDGEZMDCux4ttraT922CSnF7hy5ZKyK2LDuTNpNjDb0tQSu3wHKlgyfA/AQEv6krwzxVUA 60Rtfy9K67t3+cfkJ1MRcsS9ZsJYBMBT6fU0ANKih/BvClWxCMJ75jXaREIri1oU/G22l3KjTSb0 JAQguC68uYs4/gmu6SADZjDEyznEvBoAHwDCMxEXw6b6ihqV9kJqoADeAWg8tdRTS8HbzrOJNwl3 fNCL98oZEihx5ptiAJTEEoK//QTxij8AwNIpACZZIU2xA8vSIiEGbYQMPSC9vLFCLi4kTi5mDBhA CQDiIq6DELUQC6olNMCnqSEMyw/LLPOLLUo62JuwpgXTm023J3Zj60syshByyKCK3GwLUw7AR8AA qjslgwHAqmqgeQookT+SCMiAHng+1ZSsLbksT7IHFxMzzEYpfIuKD4nbCQAD0ATRC5I6qyI8sfTE pUlq/OQPUNMEbRTILg+1ldEbfbw2i5wgTWKPbveY9EgnIoDn/o81ySV33HMIkMJcUngq7J182ITH CngQ4kLaWhPFcVqXwCS0zJuoeJO4A3W1ADk5teCUiQOu2HPPJtlR5wpmK3bW1fQ0/lffQW2UTL0f GXm0MnPts08o+Q5beaZbooXVptxquxFkCKcIeOQpIvhVLgke+BnDDYgL4akvmnJjnQGWgkpGUfFR aRpNTXGqqk2tQvBjLPKV9qy0dvyXa4EpM+ensoGqzEiW1b5342xwztY9CYYhJplk5EpGhLwRDuGc IEUq6OkM6h2F3CG6bWevcxVvVQ6Zad06ZltkcjkyHc0kmWwkzH7PAI3CXRv0LiLsMZG323tiZxGI QW7uDlTP/nsDEUIgQOHQbfciX0W10ZbbAYgqRygrNKr99uKNBw5X9wYYJm/XXc9b9WFCSO7z462H 8PHdH+2WTW+7TQKePa4f/3jTHcUigthfh95510Mgmnjy5S8+OJ7S9R5/8effn2Xzb87iARnYQAjY Bz3ZVWB2guPfAm0nhgrpIX/liB8DKZi8OVDEAD8j0QDf10ECngoeD6jgCFf2tkhh5l0kVKEFHeGe nz0gAg/wHVNo+BEY+mGFOcSE/+KjQx+OgYe7wMkQiVhEIx4RiUlU4hKZ2EQnPhGKUZTiFKlYRSte EYtZ1OIWh0gHiwwJHJCAzw/J2MIynrElQUSeezBThSK4/geNcRSOHOm4QxbWEY+ZUGMe+XgrL/YR kIrYYyDpOEg/EhKRvUjkIk8XB0MyEo+PhKQODSnJScbRkpckYSU12cmJeHJ/tHLkHdlomTaC8oyZ HIMDCtCFChxATvo7TNdE+YXR6UZWlvvkHx9lv/y1CZVkrN8JiVm9J0CHCw6ITROqo7ZF1RJf69HY M8e0xgtu75feM2Yw90eRYn7zja7UlOi0tLZBQfNVuTsntpjASfdkE39964IzHCaNPnHzMF8EZzEZ R4UIGKJKOrlTBCqQGofRhgAVEI929ASQP+jDAVExD7R6kyPIfG1fugsZO4fgzif4Ep7ekicXSIKf g+LT/lp2nALwyJGy4LX0pTwxpgB4EgApOEADNr1PWFqpGK8IoJURqEd2DpGBVu6UHhPd6L4M5ZsG yYxj0iQTKXVinwnA46oDmMAEIrDVrnKVTWDIKTxKxD9ExcRBT73o5VYaFCWM4q2h8IlMw9FPSEAj p6zYE2n2FBtlXoE0BdCLSlIRmz3VaKmQ42i12nYtj3m0CQbY6gQusNUMTPaqW9VqVsu5sJIwQUAA EQJEJdqOf4gWp3caSFkXwrLGTBNs1WykG5EA1299Lxw8AYpltMAUeIhFILjga0QsERvSrGMfGhCC YdGJO4rqy6nUii6hHGsryIIWs9mdLFY3u9VtNqGk/kxQxyhsmh2pJXW8P7FpRJ2iNLs+a2XnWSdj qWvNJvShCC8tW1A0d4S9LEy8JdkrIfqKD3UIIbAHGYWfDsu2airWqbuRiJgi09jrGk672b1shr8L 2lNYQilFwBJze5UVEVNDLNKRjSuYarlc+mujHtslJGK6Twn+1z0pfqhgAVofsKRYmQUIy9PA0pRO SaFqmVIxfKMK4UQ5Djcum6Yu3cJLcWk3A5WlrJYxmwEOjOEQp1iC0oAKm4elqKBlJkIADtDhbbjC NrDN6FqjWt2U2he0e7DxkNIVrnpZJ3zhS5e53spQxJ1jtXqiV/iulzvpWtmMkNhIdiubZS5blnZi /k1FeE1RIAbPotOehsdnV/xmOcu4otRqC6rxLF5Bh9R7M5wgKm9ZZ0Rc2HA01LWuJ0DDC+ilw+xN h1DXASoNFKA6SU6xsY9dHaAyDT9KtSXMFjsmWfHrzu1E3wx33e1dc4BNbkZpN6ia6wtcoNvotrQG KNWFP/eK0RkgCE5NNjgAyBsoGkhXdsJa6mnLOcK6m7DWTi02NpoN4Qnf7bith2vQylsA55b4uQVw kpHysbnU9hFGcVmbW0yZzjljeCTLfY0M6KMznfEMCN878i9RWHsur6PDdcI9bjMF3N4SdzBrbWuV ylyODrcfBLUJwZ0DvYRID3q591wOpc9PlU8H/p3Qm35KqTf86mWkedaFyfUfDhInXp+52ClZ8m6S fbZoR2TU1b42trddj2/h4tzpXne73x3vedf73vkORbgH8+1/F/zgCV94wx8e8YlX/OIZ33jHPx7y kZf85ClfectfHvOZ1/zmOd95z38e9KEX/ehJX3rTnx71qVf96lnfete/Hvaxl/3saV/748Ea97nX /e5533vf/x74wcf9CIRffOMfH/nCn98eRtB85z8f+tGX/vSpX33rXx/72df+9rnffe9/H/zhF//4 yR/+5UcA+utS//oJUH73vx/+8Zf//Olff/u7//zpp0KS7t9///8fAANQAAdQ+/Lv+VDCCa6g/v0I kAEb0AEfEAIj0ACdDyWaLxde4fuGIAIBkAk2EP400ANDsPwmUPoAYASaQCUs0ARPcAVBMPpcMABh kAVncP5AUAZZ8AZV8ANX8PmcYPtyUASD8Aflh/merwNIoAdRMAB0kAaBEAjvrwNVkAfpzwan0Pme 8Akz0AppkPuyUAi/kPpI8Ai5UAmZsAqlsAXT0AWbAA1NMApxcAtLsAPZsAo10A7R8AqjkA2lEA6h rw7/EA9n0A33sA8LkQnNcBD3EBAFMRDvEAwhcALH8AULYwl10A7T0BIH0Q8x8QwFEROtLxE18RKT cBQ9MQkR8RBPsQk1ERXpkBNfcRLnEBYz/nEV+/AMCfERG9AAO2AA8hBJKhEOFdEHSzEPabEWn4AU p/ATRxEG1/AVOxEa4zAayXAYefAWq3ESN7ETTfEafVEWcxESd7EDnA8evDEF+RAHU9EUVbEUu7EA s5EYqRER23EZpTERjZELD9Edi3ETtfETuXEW81EgwZEAd3EEgNEbzYsdrdEK4/EY63Egq28LmVEZ GTIV6REVs/Eh+ZEj91Ed83EfKRIfZdALCbL/SPAgZQEBj2Uhk5EVCVEYM9IHQREe1ZAVG/ENYZIh KxIj0zEY5XEV9bAZXTETY7IQh/IbTVIXiRD9DjALzlEpo1IIS1IqCRIlVzIBEbIqt/IB/qmSK8Hw Kk9GLEftK8vSLM9yAFGSctYSLdvSLd8S/5gSLquyKefSLjmQKX+PdpKPL/vSL/8SMANTMAcz+fYS f86P/RJTMReTMRvTMR8TMiNTMieTMiEzHyoTMzNTMzeTMzvTMykTMW3v9GaNKaWAME8TNVNTNVeT NVsT+ELTNWNTNmeTNmvTNrMJNm9TN3eTN3vTN3kvN39TOIeTOIuTNYPTOJNTOZeTOYGzNNtB91AB MKWzOatzD6hzOq2zNZHTW1yGJL4z+CjHe1CBPH2POsuzL71T+NAz+dQzpLDTPLszf+BTO0+TO7uF PsET+PITP/uz984zO/mSP4tvQPGn/kBxDzvz80Dr0y/v8zrHEzxl4T/nU0LJ8xV4D0ClU0Ij9EF3 jz439EI7FES/00I1NERJ4kQ9tDtPdERRdEENVD5d9EFvgUEH00Fd9ELLE0A9dEP1U0d/Dz3ZM0g7 NDppVD5Z1EdRdEb9k0TDk0mFtEmB1DszNElrFDBvFD511EijE0aX9EXnk0OntEm/lEnxs0eHdEnT FEctdD+fNEnZND77U0x31Eob9Dl/KUujNE5jdEyBNEwh9EdVlE+p9E3ltEzNdE8JVU9TNPcSVD/V lEzr1DnJZw9ME0yPtEq5FEK9tE0hlUgjlUg/dVAN1VNDFVRF1VMdFUMxlVNDVVKR/g9LAfU6GRVB 1ZNGTTRRZ5VOT/VDe/RRWzRCTVRY/dRMzzNES3RPg1VDcfRV7ZRS/wk6m1VatfNUpxX3sNQ911M8 kW9bB7NbZfNb/3It8dRa+/JGyxVd0zVdz1Vd29VdrZRd31Ve51U545Ve7xVfedNee9Mw89VfrXVf /1VgB1b4+hWeQvMzN/OfEpZhG9ZhHxZiI1ZiJ3YyQ1M0L7Z4KjVaCZZjOxY1A9ZjQ1ZkfQ9kR5Y3 LdVkf7Nk8TVc4WktfdUvUTabsjVl7fNOTfYVEpNW59MlqvVYdxZaXRbUzAtoa9ZZx0djcbYxF/Rl RuACPHTUTIU/ZXY8z+wV4KEq/naTZss1Xqt1ZgfTYNfzMQ80MQ5iS2ENNK42Z6d2Y7vTasUya/3S ZyGjXdm1aHX1Rb1299aFW8f2PZ1gXSCiUftKJeIWf6jWTF1kLA0Xb/X2URv1ZbN1ayfUcZXvZnmW bA/1UgMTyYzPptRvCAL3MtelQHWB/WgBQRssbdl2PkfNPm5BLwy3cvk0OvFFcwnUNbEUeyTXP880 R13V9xqzHcL2P0+3ENavdEM3dBGQaRvMQFjXQMVSp5JEp+h0RY11WYf1bP/W1qxXV1HVSH8URFn0 boPPQTugBLTmej/0Vx+XQmHWW/LBn/4JntgPTxNzeZHXZZVXfgXXZZ2XFgjr/nDbVldHDSWol3HD 91DhVFXdF0/5xSyKlVGh1FGPNVPZ8y/PN31dYlSZNUG/FH69B3G7ZYRJWHTn03jzl3T3t38LgTbQ NkF+aYRBLW2tw7wEGEZttULL1Htn9qJuQ3MVeFlJdVFvdXYP9nLHc3fPVlExGINdtn4Zs1I3rX4N B4VB9zJVOHmb4CDMFoZ3F3XzZ4bfNjv4zab484mbuIO/GJfa+IVddUfRNFVvt3xfM4mVOHPnuHeN jwo6l4Dz54+vMzK3eHn5l2kD+LCgN3rNSy/KuCoGlIKJuIFB+IfpFo7d1FQLFVWB9/jslmx992eF 9IgPN9M8129ZeHRFN0C4/jdLElmGAxk0zmywqmKVG7dYJfhXf5eTeZZRIhh4t/SDLVhEh1VGM/iO u9Q4FcyUHZNsuXglD9lAXFmMA5kkXPfj3ng2ocqSX3VliZOazXNp2Zh/wxiVYzkhXllok0SdFWKU 19N2m7Wb5TVn2a+OSYJL0DZygbaE11dDsTk283lyGTSe57VlZxag21mEv9ll09doA3OgG9o19xmi Y/OhJ9qi/7WiL1qj6RVhKdajEzaVP1qkR5qkS1qkLZY0MValLyFpZdOkXxqmY1qmM3Nh10+hr/SY V/ORD5qne9qnfxqoX7bjgpqoi9qojxqpkxoVbtqYn1WiT5OWV9p6VJSp/o/2elo6NqNahVNYqlsh pfNhqXmPeEk2p1VTq1sYBbGyq1maqbO2qkn4iDPa+M5arRVwrTeBikPKrcW6lu3Yqd86T+eaGyqQ Ba/5rtka9/Y690AXh3/vPnc2sIvvrP0QB5034wiusWovr+s3rGFNlV93PEP4MI8ZsjdVsnVhBCQR DS2bY5rL0cxpdF6b6zY7mxS7ivntZGR3UpE2aGMUe4U1UEH5e0UYF1IbCZ3RvOpMtmGsvuLrwdqO il8Wrml7gLF2sKiXjoGWO4dYjYVZTx24UnFBtUnRsiNkcqKMnaltVqbLa2ymkrHnAgGO48w7ws5q Ex4AAVoudPL6W21b/oZHTRawO4hvd7tFVJJ91IgRVYxngRcTkhJbG7rCpuCia71nBeZsRb6kq0ua 6rLhwAEeoAFM4AROYAEW4AQotW1h1r+r20QZV1kzNX6TWDy7O7sV3FtoeRjIsRelkLVTTb41isKl 6bWGfM7AuOPA2LAze8M1bhEMAAFCnMRLXMpL/MSRloDpc8VFuLFptYIJXMZZdVEvmHaxnMEPMhaT ++Ui3FrChsjbfD0WRarivL3pC7acjA4eQAFGfMr3fMoTYMT/HNADPdARYAE0gboX/NBJeMvJtVS9 BzlVNXx3+JaLOYSj+gRhNyshHMIq7Mc7HVuW3MflfMJBHbrq4AH+/pzPU93PBZ3VR1wBTKABHKDQ MyHRibvW/6mxhTaUf0muT7sD1fpYILzFjrxf2GnTl4rYr/njVu3BmorYL8HJG0DPU73Kx2DWMeHW p/ubV9hcy1qC67n36HosT6bDm3u5z6jcV+nJRTwBqBwOrh2xPbuzZ9bF+djbUfOsD/oNLry5fajn WsLJ9TsL4H0REh07s9xAwV33er1g0x1jCV4Ratpv35ovGT74zvqwsQDix+Onsx2n/3o2x3qja3QB bJPik8/i/TrjtWDj9/s4S3OmY17mZ36kQ5r9FoDmX/r8Vn6EWp7nf/4NfB7oh74LhJ7oj17jkV7p vcDol97pm97p/pUe6qP+6Kee6ofe6q/+57Ne61ee67v+sL8e7Nda7Mdeqsve7FUa7UGvAdJ+Dtae 8qK9Aeae7uve7u8e7/Ne7/ee7/ve7/8e8ANf8Aef8Avf8A8f8RN/7/M7kRBAxEcc1hVf8ief8ivf 8i8f8zNf8/2e3RPABBCgjxBgxBtA4N0elQxA2k8A9Ono1E9AhEz/6kTf9eOoARJg9WGf60T/9n9I 2ksf913OABKg7X9IxH3/913OARRg+HNI9I+/7YJ/90fo1F/f+dHOAGZfhVS/+uGu+Umo+7df7RxA +0do/MFf7b6fgdDf/NEO+xkI1tcf7kK8gk7A+OFf5k6dgq7f/v7hLgHqP3QcHwgAwiGxaDwik8ol s+l8QqPSKbVqvWKz0BNC6z02Gt8xuWw+o9PqdVTMrobf8jm9br/jASZ3fmky9QUKDhIWsjUAGhbF KTY6PkIqIkYyRlpeYjokbHImAiAknAyBimImTUJW1hUEtLoOlGUwRQQIFRAg3TYFREQ5wBYNOJh+ GSwcIx8PHScedxGDeTqq0hVURGBHVAQAexEUzNYCDOfizkrpFvFCaxknEB27ORw7nCyUsi9KN1LP pQ8JEDeOgDkjvTIUFDKAQLdtvYpEICALAC0h5IQQJJfOwUWDFiEOQQjMQYAKHWnJeijk4cGEABZ2 G2IiwbOZ/m5mbrKYc1wnIaBC+UwgDUGyi/aYyURWyh0REws8OUWWJOpTmTSVaXL20w6qR/3k/Bsi bhsrbhBblbWIthUAAq6KkG3loCIAXQNcmdXltqO6XrfM0V0roC5aIq4IHBj8shatsgHIrRXo854Q qQCK6nEGoMGCBMouW7b3DICxp0eFeD4RtYtTocdElTYgm+gCA/DiITkatZTn16BVg17AdZ8kPqtc AuBFEljAsxMD4DoATkgAWd+KkNQogK6u6hhr3drGt29dgisZi9NmC/m6u0IqHKAIXciB+AcqDCkw cZlw2v2ZVYUMIM5olkwXnw3RADmfIXBTVQ4kQtQ7pSVT/hURpx0xj3CVLTBMapO98wltw1FiXDXs RSTZOkPQVV5y3QgAznVEuHXWei3m10pMR6zz13nUldRNWNQ9ZJZZLbqHVgGsTDeEaPaI5pSCynRG pXCcmUDUCVBqWYQBRyHYQG8WIgDmhMwcZRsRFIZYhFNQVeVZTRZySGIqJvrjEkltNZkcS/Llh8uK fBJKY5+AloejLQEcIBmPfpmHKADbsOUieQDc556kFZVEEEE7aknPPZ8B2IA9TpXyWocaikYEbVyQ imZVUf3RGWm2boYgh6sZ8WZSgHimpq/82ekVnmC51Jymkv64XnIFWVPoEMtqw52gF8XXnWJI9Bip piPN/jeknwqVFJ985GRQy3wKjadUcBtS5YB/zyQjBJhFyFlnaUL4yqCtTNmLa2b/beiqwPkGO9mG CIxYR1fTHPuGNdlos2IABURw16Et6lVdBAH14pZK1B2QcUnWEjZABKy4SMtD461D6QB3oUeAybAU cABf6yZnlnzc3GUddCnuCMBRXRwlj2WW5UrZJ74xBeWXWGmFVDy0ndkmaF1oSA6Ut4bIjAFRoVYb f6rV6zBxhnwlMV4Xd+NAWfjZ6Gxbr6j1GBFyt4IfypOiNUw6zc1o2ENLXpzud62YQzNcjL4nEC00 F+QW40c03DCHqTrN4WiaMaVhZ/mCSbZ/ZAOsMGjS/jgDcFbHtJmwTvRoWCzE+RBy6Lhj3Meio4YY MB5pR6hpRvFI8KWrHA/zEzHudGRMxMe/XzH9RYo+n4eGCHz5tdolZm/IAAUUfYXcMckd/iBUISP8 GswXp7788+MuG0d4wM+28/Tz37//VuSvEG37HwELaMBogO+AClygAgNIiAEyMIISzIcDBwHBCWIw g15ZmwD3p8EPgjAQFRTEBZ0gLioULlBlwF4WGkW9MbBQEOZI4ReuE8MYTmE/ZxihCD3oBPdNgYaW guELrTA5IHoBh3mgixC1MKORSa+IUWjiGHjYhxI24SLDkAjyPkWEhdiscAsZ4gD2g5CRiYQIabRR /gZ0CACEuLGMRnBApN44KBZJb1oMGcJJVtKWkVWkjcGYCB0LohKVXGSNFqnjODiCHCGkK2QycuMZ 8bgQKOoRGE/MZLMocoSFuHGL+3FISGyGR1PCgYMP9GETOnaxSn1xLXQjCzguBqSy4MJyQJMlkLah GMGcBS/DIMkrxaHLmMSFG7S4nGGYUwtipsVSgVlZn5bpii2+IpmwSM+6jPRKxbilLLCwZgG25btW pKiY5Hol3d5WtMgQKjDqrAhJ6EYEJsHScmnR5WLYeUvdQcGKecAiEzo2zDs+i1zj0Bt1wKG4heZS ID5LzlzS4zeLnsUc9QFAjMQSst8tRwjNYSF8/qgjC+mIRRbpCIw5z6PR+NRooc5MjtDAsSe6qCc7 Cl1m+Zq1l4X2YqJ6gxymDvXQF9mwFkdVZklKYoSjCsBcPyWJJKnTjaG2dAoCxR8rC5rLJiF0Jd+o RUxFCo5yiuWr51kS4gQVJLG8tW6LYVEGSCnEsvqJhe7Z04sAclbAiCOsSCLrdPDKC8WVsxZR7aUm L8ZWXixTCUwEKzYc29bd0RCthgKUZs9JPSYhzpiUjadlWSEoTEphq3cg6BL0MloiUCpnhN3sP1zr Uk+hklIC0a1cK0Iza6zjrn2C7Aur05zdEWqlgcVkiyoyoxSuQ11UnShv3YJbXEQ2CZP1KC2u/hvU h2TWJUkd4nkaVbQlXRcjo02qd5GbygRewbZE2htD3bOsok7KXAkt3KCAAS5c/DeKQ6iRd+YrRGqh BwlRLTDPopUOTQlWIDWaEYKp05z7COS/9x0nLI+w3fn2d77Seo9+2zjekkIyA4H8XQWa9Av1erRQ IXYvFVTLla62Vq0iVovN0hXYkqUIHN2NQKN0nDIi1+xmQ75LTHh6F0GVjGZVNcLFTCbkFxJzwB4D GeBmVqkI79LIVdaYSCFnOZferGdeRo/kDGIW/vpFmY0SMQ2HnK6FXFk+PWaqLTbGKJPRDc53i7PK 5kxjrarSgjhWgnxpfEyz8O1iHe1njIwM/jgdLW5dunTJ5JhJM24EYDBNjDTdcEjUTAspcct1M+Vg bJG58XE+KNEyMx3gQp39LMbqqI6gL+2zFR34MKRdp6wlGkdX2FPQxByGboER1tQmmoSLDmEWJjo/ VFL7CjZ22LSzTYUBGJp/WfU2tOFLbjOMD4nnzuC26cDadcM73lH4g7nlbe97T2EPkUBAtPHt738P QQHdpkOZAG7wgxfhBA+IRD0Q7nCDn0DdgjjB8R5u8XUX3BL6vjjHz/1uPGS84yIPocIxwYWRozyD IbfEylPu8gOe3BQnGPjLa44JBCgAGg8ouc17Pr+dV/wSLfc50aHxpdFAw1RBLzrTH1EPiKSzQ+lN n/ojHrAAmheCKFCnOtfx4ABTbb1+Wwp712uOdS+USQFLz16ZZr7wssM9DQ+YScz/N/ctqWYPYdg7 3/vu978DPvCCHzzhC2/4wyM+8YpfPOMb7/jHQ/7vfzhBKEzwdgU64AENijznO+/5z4M+9KIfPekN jwCJxz31ql8961vv+teDMAgAOw== ------=_NextPart_89E_BC85_A3FA7C8A.AC8B02F8-- From alfa_rta@merrickhomesllc.com Thu Jan 18 13:46:50 2007 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7cHh-0008Re-NS; Thu, 18 Jan 2007 13:46:49 -0500 Received: from a80-100-125-142.adsl.xs4all.nl ([80.100.125.142] helo=SpeedTouch.lan) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7cHR-00015X-1Q; Thu, 18 Jan 2007 13:46:49 -0500 Received: from 64.202.166.12 (HELO smtp.secureserver.net) by lists.ietf.org with esmtp (/YB7('9/ZPK) B+KN) id BD44X@-*A?O*8-18 for ipfix-archive@lists.ietf.org; Thu, 18 Jan 2007 18:46:34 -0060 Message-ID: <01c73b30$fa5b60b0$6c822ecf@alfa_rta> From: "Parker Dotson" To: Subject: Windows, Full or OEM? legalities? Date: Thu, 18 Jan 2007 18:46:34 -0060 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_000F_01C73B39.5C1FC8B0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-Spam-Score: 1.6 (+) X-Scan-Signature: fcb459c204557d9509ce9c1b55d771f1 This is a multi-part message in MIME format. ------=_NextPart_000_000F_01C73B39.5C1FC8B0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0010_01C73B39.5C1FC8B0" ------=_NextPart_001_0010_01C73B39.5C1FC8B0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable VI. Smeerenburg and the Whale-Oil RushHe is harsh, dismal, ice=97that is, e= xiled;A rabbit carcass in its stiffened fur.Silent patch of ultimate paint.= You areXIV. Franz Josef Land: The Amazing Drift of the TegetthoffAnd trump= et at his lips; nor does he castThis perfection, this absence.With its lame= nt, it often sounds, instead,Only a fox whose den I cannot find.Grateful, I= know, for just such compensations,Glimmering of light:Thinking of your abi= ding spirit bringsThis perfection, this absence.It is as though I were at a= second threshold.Absurdly, my eyes can only see the arcI've drifted somewh= at from the distant heartAbsurdly, my eyes can only see the arcwill come, b= lighting our harbingers of spring,I've drifted somewhat from the distant he= art ------=_NextPart_001_0010_01C73B39.5C1FC8B0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
3D""
VI. Smeerenburg and the Whale-Oil Rush
He is harsh, dismal, ice=97t= hat is, exiled;
A rabbit carcass in its stiffened fur.
Silent patch o= f ultimate paint. You are
XIV. Franz Josef Land: The Amazing Drift of th= e Tegetthoff
And trumpet at his lips; nor does he cast
This perfectio= n, this absence.
With its lament, it often sounds, instead,
Only a fo= x whose den I cannot find.
Grateful, I know, for just such compensations= ,
Glimmering of light:
Thinking of your abiding spirit brings
This= perfection, this absence.
It is as though I were at a second threshold.=
Absurdly, my eyes can only see the arc
I've drifted somewhat from th= e distant heart
Absurdly, my eyes can only see the arc
will come, bli= ghting our harbingers of spring,
I've drifted somewhat from the distant = heart
------=_NextPart_001_0010_01C73B39.5C1FC8B0-- ------=_NextPart_000_000F_01C73B39.5C1FC8B0 Content-Type: image/gif; name="ovyh.gif" Content-ID: <006901c73b30$fa5b60b0$6c822ecf@B09B09> Content-Transfer-Encoding: base64 R0lGODlhwwGaAbMAAP///wAAAAQE/B9hqmGw5Orq2729u8/PzvfwYvvQCGBUI7OZbPqCBvv7+wQE BAAAACwAAAAAwwGaAQAE/hDISau9OOvNu/9gKI5kaZ5oqq5s675wLM90bd94ru987//AoHBILBqP yKRySQw4M85A5cmURKXWzzUK5QKuVuxsiyGXwZStWqNuh8Q9alULH9VZ6Kl3Il+a+11tgF9gf3ct gnVuFothiWyJex2DOpRzXSaWKXlpkpdhehychIB9mjGlcHueq6dZkCuun0WysDCjjodzqRuenarA OZRyvJ2htpgqtbNCy2eoUrzFfKNPkmaM2L+mkb6gtt1Uqd7az9nfx4QXmrLL4q3a5epe74PW79vD uOvR3N65utDgS6cn3j4P90JNI8VpDUB7jR6KCadPF7V+3dAxZOVQxMB0/vqgTLKo0BC2iBux3Ktm 6GI5lPzywBSUbRHEMyc7vulXEiSxn4qA/hrq6KKxo+Z6TQyGFJ7Roh5VHvrJLykypUI1knoK1SXX rUevZQUbqOBXscCWftR6jihZEOKmaK3n06zbm2/JLmyrlBrSbxzZ/kumjm9IvlgffS3MuHFXiEGX tsUL+apjvXfGPmZKOO/gZFQdr636129XxKZFk6wVeq5Uy2yvHr5M213G1Km5kb48mzK7qauD7k7a m7PV2XTQjR6NGrnO2pJLEySsO2xwxSOnKwc+HLbV7fk64q3rkyX27rdrtm4aXTb3neBVxy6NPGV7 9tql765u+lT6vvmt/ofbfN11Fp9EMmX2Hm9pJXhec5EUlNNwzCFWX3agCFghfQtK+JphwpUFyX3F +EeSKB3mliJt3xnIGH8uFocaQARaxlorA2q04V8XouiXhh8a2KN1+4XoIkEwFmZiCZbIOKMztoGo n3ZOTgnYid+1o2CO8mmpnzMqvhhiYK5FliNddxmJk4g6jlnieC1yOB2cPmKI32Ji1oTklgyeVuM4 Uu5pl1d1+vnZcV/I2eZ9m6WVplqKjhiZmtP4w9Whrjj16IzeFQgkpGdqKphUjjYK4KaXokXoqjZq ltxZlOpUES40hafmRpLOZFxjKMHkoXi6PlejetiNl9NLWz5nbK/C/nIarLJkVIYiPAcV+tZeyOLU pDy4Unmofcfdyi23vyI7GLlgUhTqNvk8SSqfPI5b7ZTo4shunwihBSYz/Pbr7yZY/qtMwAIXbPDB NOyLMFwEL+zwwxC/GjHAE1ds8cWdYjxtwxp37PEnCnf87cckl2zyySinrPLKLLfs8sswxyzzzDTX bPPNOOes88489+zzz0AHLXQsHL8Qsh1FD620y0cTbUPTS0dtMtQU10C11FhrfPUJW9uZ9dcqCzTp romSx5KHgWy7I9hsY3xeI4DiJ2uDvtRqa9dt530JtakGaahaoIoZ+LWW5qL34RdzRKpdppS9qNlx 4+sZ3ohXTst7/odRtd6ysWXK6LCWhz5L5phLtjm8FaotIOiit84E6UXmuVee0JX7OYuu5/566bFr fivtztlbu+7E7827lL5729+CnHNa/PNGxK14Go5nAW+Yk3+e5MjQd88D36a65afkY6lqeN9Je69+ wtHSLS2ezUtErHlcUL7+/VzTM3YZ63jKaL2f8hv+BkjAAhrwgAhMoAIXyMAGOvCBEIygBCdIwQpa 8IIYzKAGN8jBDnrwgyAMoQhHSMISmvCEKEyhClfIwha68IUwHGEDQNCAGtpQAjac4QRySIIadkCH HPDhB2YIRCFSgIcxxJkRK3BDEeTwiRkwYhOjiMQdLpGJNixA/gMKwMUudvEAByhAGLn4RB+WEYpW NCMQLVDFJFZhik5cIw3XiEYsFvGOZ8RjHp+oRS9yEYyANIAgB0nIQhrykAYYIxRvuMcrYoCIAJCj Gz8hyRTAMZKOxGEe2RhJTdawj34MJCIRuYBRmpKUBFhAKhfASlYmkoyN3GQlO8nESVJyljIoIyaz uMUvBvIApyxkKYNJzGIOcpiEHCYBDJDKVQoyjDqMpS6DaEslqPGIapSkI8sIyi+KEZDAPGQph4lM Y5rTkOU8pzrTmUoDIHOMXpxmNjOJw2oyQYrc9OMfRblOdfrznwAN6DkB2cU9UtGeR/jkGMMZzHQK 9KEQjahE/osJTHBqkYgYZSMuEeqDLSYSjO6cqEhHStKSBrOir1xkGjfK0R1sEZzMDKlJZ3pSmtr0 lCiFJkbv2FIieDSQrGznOA8JzqIaFaXPPKohGRpRpibyqYV0Kk2H2sqqWtWVDiVkOC0KyTb2FAgv RSk5manKQRZVn2L0plHTulClVjSnzzTrU5E6yrdqFaRbnShVr8rXvo7zr0tNalKhucOvFqEAczXA AIIaUofCE62Q9WMv94lXuxr1o3HNqVLPOVZ3+rWqDFgAA0ZL2tKSNgGmTa1qVSvaViLylwcQIj0N q4MGzPUAC1isAnKryndaNLJqBaM3vQjTvMJ1q1LlrGc//stKBDR3Ac51bgIWMF1WTve61KXudUOL 2u4ywLve/e5oUSve0Jq3qq/lKiRp+4OfxjWZi3UscecbSuAWF6qm3Ktz+Ypd1IoWvAkIsIAHLODx Gli83Q0wghfMYAOH97SrjTBpXXlXrrIXrA3A6yiXWdezhvHDa4UnP8W5XKvu98TRTQACpivd/mZ3 utxdMIC/m2AEk1fB4C1vgslb2gfn+MCrHWpib6vFC/8AsUM+6VFBDE4COPnJy9xvjHO8YwJbecDj rTKOr0xgGlO5xjj2soNl7OMfAznCPA4yAgar3kpe0sgsyDB+lQzPWDITyu5csZ6h+2LtfrnLW+by lWlM/uYZb5nQYUa0jCEcXipDWMcSTq1rBWtRTxoUziuoIVxxetaCXjSLd4aydG0saECTusCBNnWq UY1lMP950QDm8Y1NO2tIPzrSoxWtVm+7012yFNM9lDNITfnWtMbz01usIZSf3GJUi/nPVkZ0qbls Y0V72dU1JvOis3zgRKeZ1j0+s6RdueRP+xrYL7BtXjktXFjuMdRPhq6WVz3taAta2vaOdbUPrWpY 39jH3Wbwt3FtWgOsObFjxKQn0d0CYSd31532NC8Ru2wCNPva+eY3tufN6h1f++OANjS3HZ3tats6 3Lcm+HmHWVkwvnm2DB9ihjXM7j9KHNkNqLjFB+3x/o6XGuP1rrKinZ1qaeN7284e87bPPHBcs/Kt b3Xzr2MexMrW9aO/7SM3bVvx7dLb50EPOtA5zvF9u9rBM0b7yRmdcpXnes0tJywWqW4CTc+Z2AS9 ebIvCm8nr/jngNc42bX8bEOHmfAaH7q2ZR3wB7s90k+37EVpCXO6b0DTdq35b5P9xL5bfOxjD7vo Qy96fSee1QIntK0Z7/jHlzbyUI9tNBVu+RHMcNPCvOp+W4veTyq74gz4O+kHn/HSHx71Gxe80Une aEeXN9xNf3wpY1/kc9feiQAoqjj9mmsGKMD7C0D2ASr+d+OLPfAhB7u9zQ7mfVu70ak3s+tZi4DY /uvUq9f/4czzO2no4vadBjBa4td1fmZ+Brh+pTd8PXd8sJZ64rZa0adyzXVW05R/Q5R9MIVOzXVM noV1niV7mkZ+06aAB5iAXzd0DNhqp6d6CtaAbTd/3zd9FPhmFnh5AIBYdJVMroVba6ZrXRSADHBR fySC9UaCxnd0KphxoYdxigd/Asd6z/eA8zdhDMBkilR5NVhLv7R90CVIB+dOIhZaWpdhBFiCZmiG QIeEKBhoz/Z8LYhyETiFoYV1BEWDWRhFYnR3x1RVPfh/BfBXT6d147ds5XeGhniAoJd+/9aAHmdt AReFcjiHM4iFd4hDOKiHgoRVpdSDrUSFBUWG/st2iIgoith2ambXhgD3iJEIeeH3S/hXiRr1TZi4 h+MEUkiWiQZQZH1EhKTYi6TIhIfmb9kGhasYZGtlh7B4RHk4bNvXWJm4VZ/4SQXQdb5YjUqogsuX gkLnbUwHbpA4hbAHTpQIi+7Ff1gFTE42fnWWQ9NIiNb4jgaIbynYeI/meHEYiQtgVMiYjJaYeYe0 WIS0TCBGALGFc+0IZSoGjwrpc/J4eIUHjPEnhcX4enQIgvyoAWGFWRpoVYKUjk6Gc8lGjQs5kkWI gGb2YwNXa7W2iqKlj1N3hwqlkeK0W60kkIPoZOxoQ7xIkgpZeNsIjGyYZs43kRKWj0U1jpWo/m6z 6E4EsFvxZUi+x44iyZNUuY2t1oSmqFpOSJSk5ZIvaYFEtIyzuFteOFhidEYXtZNVSZWoiHxb6YJA tpKrWJHVd5EXYHfMeFKeRkZj+HsIuZYLaYQrKHLfloovOH9w92EFYJd4KJOjxFsEwFZ9yUug+GQJ CZg92XEoiJUrKX9CiXJyKIPC9ZUw6Y+GRAAOoACqqZqReYuy15dqiZkjuYQOiZJuqHT3CI6tCEik mX86JIsPZwAKMADPlEoKQAC2tVggGJU36WSyKZtIaHqQJn9sl5sSyFaxxZi1hJeYeABkCUxitAAK gFj5CJJ+aZnPOZvXWJvTmXLU+Y3gSFBh/qSdR4RJGfiPoglMAwBMuaVTA/iX6cmTINd8RKdjzjdr n4mPRklQ9MlG70VKx/lRiKUAuLicOdScOxeg0Nll1al6uNmNXPlNZ9mbvrl/ealVqhlX/VlWfSmE oaihbMlvpLZ0ifaNTWedEUaBDWpFI0ZUA6AAqQmkBqCUe3SQfgejmamZ/aZvq9dgcgmfuCafi7mj O7RuV8eUH5aJk6mTAIqkJDmj7XeSqniYOLparzSaVIpDWyhOQapbr8SUfJRF7uil8HhqJMeIJ2eb hSmREYZ1ZJSmkURzGyaeAxCkx7SlNQRvl0mnddpzhUajSodmE3mmOtWg0WSaRPVUFJpb/oNUpC/K qL4oj3bKgk/YjQdqoypHh1NqqWp6ooaUmsTZn56lnJz3RIRYiEGnZ6CKfqjHfpDaYLjWerh2pn8K qFb3WqwEpLCaSKVUq3tXmQSwq7/4k255m6faoe/penSIlL45AT3aYZtKoe6EqFzHbLg6bboqrfd2 ldhYoFoJpdAHmsMKYquaplA3Sj9KnMwERvupSvf3RM1ZgucKqolIdMF4p595p/KaqvWXcICakfml W6n5f+PHSlHJec2JAAOrrvFoeli2fLfJdnEZr6mVm5RKojV4rBBKkMwYVM5qQwG7sRx7hm05lPBH jMR4mBK2eWk6Q7JoSrCaomcZRonk/qnMNrM0e3xFV6AtaI9IF4WGOa/fxK1ZqLKGRKHoqAAf9lPu 5ntGuqhI27FJGJRielrRl7DFeJQPe4PfSkjiCkYUKnE5KafmGrbWOKCb6aRPu6dQK7Uuh7L5d4nB yWHAhLWg9KwXi5Aya2W4urgaOqBB+X7tuZVyaZg4Sq9UW4PA+Ziqqa+5CEufBpKiZoiOy6i0qaft 6YB8O38L+rcPK7ijNJwLkJoEKVkvy6XOWboBVojpCra7+7sES7YyOowhm7prF6XClZ2vi6mE5ACC RKFxC03I1pcAIGq6u7i6y7Efl7qV+6ELe7ymxWSZa4E/+3DiSqG0KoTkepMaW29//qdn8HuZujq/ wAujDXmKZ2e5Iguvxpi84+ubHviYTfmjRTuilJlDilu/XMa7v3uu5ffA6Vmw7ZqnTwuJOYu8owm4 tZeRwflU4lme0nu7PsS+7Sto6Uq/79vA9QvBphu5YWrBI8t43hhkVfhNytuzDsdu7Ya4t3uT8ua7 A5bCAka/YEvELBygp3uzBtq3CQqBO1uHgIpJSYZO7eRytouoB6mxJcy4uwu/7XvCXWzEKwyYDYl4 eApuTbx0kIe5Gmx53PlwhCq7+oq4BrlFA+BkPzywJczAYqzCQgzEzwm5WDlmaAusOhu+INbGbjxz ropODiCeqlmQoctNqhRlCdm4/l2sYlp8yfKbyfP7x727lj5JttpmvKgqfRb2sHK2lIPUlCA1AF1b xzl3x5vMxV+8qPF7wrncyb6bvaIowcjXpEy8v8UraTWMpqqMWcmFVHErnJJ8sV5LAHdcSkXMyV+s xdd8ybn8yZ3sy7+satWadirZt98LeTY8eQ/LvFGlWMPpALAshNBsQ8w0AJuMydmszUa8zdaMywrs pXsLrEpcjwSXvOi8o0QkqOgEkPwZfmT0mlunWKm0xSmMzV58zdls0Zq8z38cyGHKrnqbxvz7jQ3L m1EcqI6JTkAKpAw9mXU8iPnYu15szTG9zbdc05wMyKK8roQ8wzHM09HXkiKq/si1N2wd/Mrl2Usv G7rjB5CMa9HYrMkUPdP1jML87M3VWMa1SbwyLK+5uZvFGsXqrIf7eZbwPLegCF1UXc8ZHdVQ3da7 fMv9zMtV2ZaKt3ZQuNWsWFQlfXs5GFXKSpZkfbuh2475WMRRfdhuDdWHfdE2bdW9OMqo+KF4HaxB ds5CjW5rhNDCRJz6ydB0nEeEvcdrPdWIXdPva9rxO8RBjNPqiXhpB8Pee8ihNdJyB9aa3cpv68x8 mdRS2U4yvdjAHdwU7dZTXc0xGnJ1HdBSKKyshblRzNesvFsgFbfuJsu/V9gTLdxsvdiKbdNjHMox OnwRSczMLYWsZNkljYGN/ozbujXW8RTPMKucn6zd9D3cb+3drN3aTfjawlqmzQ3FJU3Up0SoBTzJ BxyCBDna9V3Lpd3da63CGR3XAqrTCGqt3gjSr0fbddmzOBic3hmhuLW1Igywrnza3U3RrGRepLXg 9K3aZJy/kU3O5RzSoeXcz72MHQzJDkC7itSizNlOpL3YouV9tLbgxK2r1KWaLp7TVmlySizDZytp tP2/vimWpkS4sjueIjy9/VnRQq6audaJ/hdIBYDNCrBiu/V3SZ4ACsDm4unm3fylS/vCk12M4bjh VOpeD3cAP8qaragAGea1cbpFTmZwTn3YuWboCPBdXciUFGrmyZpdSY4A/ru1WwGmXXA912DniMoN 5RJYaXtt5YjklJ2byCAJksJpcdpd5jGosQegsc21TNYL620OySv25tpV6xKu6Wvo5CAamlN+2XS3 uetsAM6rWN6ZixO3dZ9U6Idd5hQdgGkO7Ym+r3eGza2kyWcO69FF6dfl2N+8rtxYzFAah+fNoKHe 12aV7M5M3QVJmSDJ54pO0dCOAGWe4op+ACx2cPw578Ft66upmuAN7ojoqzY7puWtWqr63JGE48HU uSll4MueYaoU1fWOzUAIXfWuYjJ47Si+mmhN6Wc+u8W95HI+wUmX8BL201Oe3om63ok0nILE2UjN 0mU0fope5vWu8/bu/lyjBb+6dmeYpbE6H/CqidYOQOtRDckcn9L5jYYFZvCRSsE8HWSqKuwxx8Gx +7wTK7cXO73E+eyH/X0qznuM9Uw971xprrECD8nimZps3vRK/sEi//Tml4anF9BP6t9dyJtYj9nc +Vr56gC4FfE8HKcU1/M8r8U6f+8rF12vjtYh3/OPjO2rGaQq7faWrmICr/YEP3qDSfWyDXm89veA H8AQyqywPFloyUfMhM3QzvPQ/urdvvSr1FxKn/beCV3Oq/avXutnru0pDfdyTpu/6p4EN+bIrMow H/OcPUh6V9bRrPFpf/GK/76Kzmd9Rl32Lp5RTZPb3vkB/74Cb/JX/u3RB0/uJVuU22r6wPZSJ+22 XE/d0j/oIUj0+H/9je/F8/5cbs72EKAOosiohVxOiqpk8ZAEUUYyUVe2dVNXYdp5ZmsVZ+o92flf UDjMGA7HRgOwZDadT2hUOqVWrVdsVrvldr3a5NFoIJfLBIzjMFgUCo1DsvF+y+XvAwFRoPD3fz6/ mYwJCgNDhAXFhUKHQAqRjBGRw5OEDcjLkxMYF89PFhOQzx0EG9OFIJ+eoZ/V1tYFo6M4pa9b3Fzd Xd5eX6uwWbNhgwEFgoKFATe6Obtmu4OMR8Bqt5LqigxIDD4DzApODckRDFEHThEM0E7QTxnTHB8f kJ0TewaZeaB9/lj/H0K0kvwiWNDgQYQJqcA5QKYhMQORyhxoVsfORWcFCBwK5KdjNQYT/ByKqCgR ClFtLqAY0eEDtgUh3LEYNTPUCnUrZHjIl6/Dqpg+h7xy9Q+WrIZIbClk2tTpU6hN4AiD2FDZJiNt Kl6ENkcWtUcd+cT8mAiSohMm9yhAlzZcBbgvKZS4GYNEO1CbSuiL92OUjBqjivbjQdSoEKQCl0Zl 3Njx4ytyxDw0Q7nkRgMFBlB01hljHT2AwjLbU8BHXG0iQnhQexY16r2WsNF9cTORIhUY2Jq7Z8nS DBI7Q/SMqU+fDiCH/wVUCtn5c+iNwySFWMaBA2OMOHe2aJF7/kTS1krvGQTJ7O0Q2yrwEfl67l0T c2nX/Vlfk+y0lzLE7OBBnzwGUlllnXkETI4owwxbbpbmonPwQQh9YWiM6pQpoCE25tjqs4vICKs0 ZkKUyYZtCiGJIzc2OaEQ9yBxAK6YwuFExQ4UcUAn3f4aRQR0ctJpBtYAW+2VfRBURTnEaDkCgMUi dPJJKBearDppJBhDAjzuSMK7OvBoY7zRqpEpxmn+GE9GG9WDMYTgeuwPnZSK28Yl2USpMTcQNlng RRn426G43HryS4dVEkSSCASSOiBKRht1lElFqyODjYeW2bA7z7bUypoQOzUzxE9BNOHLdEY9Z8a0 xEmDP3VS/rjRkhR081Ov/nz8SZJU8FmH0MJYOZQIBut4dFhiGWsSgCklXYktRtzYMlMOC0BRNNE6 dYNaj8w09SR1clyLtRc7qETFctDJLRIc0e3Pp/5ECW6nwEYklLBfjdJOsWLz1bcpJRiirsKNNooj Du8yesaOTcWyFkyGQQ2rmwI4gdMEbEYVwYTr9BJlFIw1aPckIIGzJOPfVrDBExuQK1JlXw916Ig3 9pV55oOSrU5FpDTsSkuMMsPWWocbxlYDby/gBi7eTjKLrpNUaHodcuXESYVUYDj5hpVPTpneemNR clGawxY7lzmoUpaAqyjq0mCen/X5WtKAFlWsbPxQMZz9/l50MYRwwdlvYxpBKI5dm0C5Wh4isyay 6yAOSaqAsSOXHAtbbCbm62KcdZYrzqeDW+FOG+A0zEe6+eMbbra5+GLA/esxJaZTwKtwxAGcp9Ac eE1ud+Ve5mxy4IOHYg7Lh1GADTIUyOxSjJ7JFui4QYw7vLDAwfsDGoPDRjbau7fpcNt7yPpIxhnw XVjh0we+7H8rPAEdN2rZee1nKKoW9Ojz/3BUuFWT0ZwKOC2AsvOe98C3MgTySkGMc4gR0Kc+CIqN eBS6XDGOR4s6bOdZzesS6eSmMIZlIz4teg3TCnhCw9XOZAksVFH48SsLYJBJEaShvpbCPgoSQzdl YMbB/nzYnelBT3qfm554qEFC+DhtNihkIuIUqMAWlq9xSoLcsWp4RSjd8EI51OFGlLcZzXEHWs4D UxDh9oc5UEtbfkBiEufTRDjSYIUAeiL5GCgMOWBRj4zS4hgsMwxjFOMAytPQGHnWwZ+dEXpFBIu2 ShjA2dwljgXEAdZY2Cuu3RGDA9ljJ6M0wT8OQx1tWZ7BuMRBRYoOdEbsQyuP2Mo2SvKNk6Tk7bb2 QjoeqGsvMwAnPfnLCCXBbBDBDA+zxKG2aSiRH8Ff/kLFRvcs8T2zpCUpUni7BPbKhbucjC+B+U3o gJJKK8GOLBz4LPpFS5GjAeEr9wfNFkVSlgSsZuHm/mXLfuSTd4xT1HbA+c/nbFEM1bmQNIxxPAVs zjPpvIPQ6NbOa4nHkfEkoCTpWc/uaS2buRsfA5XkTYCGNCoFldRkYNZNaBRsgxn5UNDWycZsTRSe 0YTB7DBqTXxqVJu5G8ou8ShSoEZFmO0jxgAcqLZCFoyhFnFleJbpSlg+j6aQlOVNv2dJneoTk/t0 WTetGFSwEiQYoTSDIoTBmbWpVJ3P/FzDpBrRmT5yiUq0Ksquis2tRpGr9mJQLb4aVsB6YTHEI6oo I3LW+a1UqXA9U0upJ8K40jR2K7BpXcOHwBbydJsLdBmD8hhY0PZiOlxsIAGOsAC09TKM6Tylzhw7 /jR3ngmqjxygAC0bx1tWUptSDIlX/xpa4IJhKmQtgzJQm5gNNW+hygzTeiT6Sli2UYlVpaZlD6c7 JxoJl5pUym+D+90qDJW0DjEnGRgRBjGyjYNrbCps17M/ElbMonS9rTWvpttL+oqzSLpXd8H73yzY YkLENS9VNMhQMdKhrWdkpXOj++ASmrC6tz0gNrOLHP22zKOz+CyAPRzeAZf0uMpQbQ+VutI7RDQu MYXvRKULFxNSt74qNBl+66jXTC7HfB8F6Yd9/IThEtegxs0MWg+GKXQyV6INjm5MaSsfGc/YrpXM aTZduF/l9LPDP+YyE8ZK2ofcSxZJhRaSU+zi/meueLaxnOx8pTxHuxZpoy+U4r2MsOUuc3k6BCYD 2mhxziSrdYMMPuJbURPZuFSMNpWlMFbxetndtizHh+krnvPsYyVESlklyVCIkEk/piIa0WimrW3d zOg345OF48PyYVKh5R5f2seFJQZykeBX9aL4WaR27qjj+55p0jfVc5zXLRUHi1Yb5WtM8q6sg+uv 8ZbBqGJYLecw1R0WHfrJiYbxfPGC6pveM6t1pHNP9+o1BjHb2Xmm9USEIQutmJKDneN1bWsqYfi4 Ocb0GbZGsQZFVkQx2YdZtqXX/V0lSGugVZkMagm2XFA37wixpLi3JTxse17237jD8JW7xohZ/ljk 4D/GIVn7KQad5XredUCir7mdb4vr+81bi/MT9VpuDdtrx7RQ98g/HGIqYdDTmUrroO+Q7TVXvNuR vHiqDwjwS2aWt0SYjMh9/mGFR/troSukrp23JaSrWemwOfWEZ1xhVee3owMnQn8fePX/irOkJ7VW MuVNxrFTdN8yB7d1MWtslrWa7UHQjgNnCPe4y53hQu8h23aWYrC/BrryffE0L4pxtGc3fDY/t3Lc HmvEhzbrJg+WpyNudzK6vPIXvzfGawf4nBqb7YMHCMhhBvrQA5awWqciwVKazMerGC5xpfy2LU/X vjtdzqyGdCtoX3h/5h7hAlUWFU2v8tYq/pgixSe7XINN3+TXF4pOFHfA7Vg+tx9e+qEFe7v7eiET E13+XFF9EikKc/C7nuZTvvDiDDV1RVCUfmm29QOoBhimyrC+6ws+ZCIePuA+y+O2vaMsCnQ9/uM8 OcuwxeGtzyvAZ6O+uYOZ60svLbm2+IHAAbK/FNw3szs7OJOjFbKxSKM9fwhAfCFADwQm8RIyDFKb +IM4H0qxUZMnRZun+Qg/KRu/G8stwqBBr9kk9cvBoEo491MU+Bu63wtCU7If75su+2O6qkLCcEsh mpPBm3PCWOgvHJTCbwK6y1FABQvCU+IS4SO7Nis7C8w4zLKlwJO08yufszI4NgypAywe/j+iu8ZT qOU6si3xgwlUQXwztRYUPxqTIyoDuO2augBRQ9wbRB38sqBjPCxcRBKMPHv7vnyLscvLwwt8tMHA sJvLuY/jsTX0RCwaLdITRYUStAZUpm6jJ2CLxBYQw0Zrxc3jQ+0CwErrRFv8peEKQYrwwa7bCmps xPY7gAkDRtabxCRUIaiTutyKNE20wTurxWasobEiMDiMQ+XqHCFMNGG8KGLsNxhUtd3qqM47lMTw r3MkRDccht7jumpkni6JRij7BG1sOla0rxjUp/57xT+sF3KMg34EqnSsipDzwWpsx86Jn2yjpoSc x2KkMtvJQIHTHU1EjGU0x4pUnwkZ/q+t00ggHEiu4ELkq8DaWEhL4j97PDbeAUcO5MSWJEQlCcHQ QTCOrIiCko8WnB2RrKv968liy6uUBJZuisKhBCb36ysRPEp5S66LmLjLe0oL9DeTNL8mDMecQ0OA qDSszMo9yrQ/qyBdNDOOTLIwuBCm1EmMwq+GLAyuScuU3EewYUm4nJyyaaA3RER2/ErH7AxaWEW+ nIkyXD46WrUjETwAvJe3O8xO8hd11EWVu0vvUBKcnEw4uie160NZ5EBh6EzP1KPE5EHG3ByavE3C wkayzMP78kZIc8iOq0qr5LnY/KaipMtoXMC7jBawM4LdxLx6lL2Aq7JtyjDh/JNg/nnL4rwiaam+ gIw/3ESwgtJN1MwozXu0y0RLjmpN4UyMzGDG7Uyf8TRK5TSkz+CSyHzObnQHwKvMe9QwtuQrJdHO +ISgf0zAaNTIMHJMBiSs0ChPnIq6tJO6qLvOBZGhAo1LEATI9xtF+6S/+jGtvYTQWuJD2LNOiLTQ P/kz2MxQCBIokxPNBWXQEmQpMdBPF7Q5ZFzPszQ/FR2C8xFEFw2e0QvF5LTNDzW6hTItMiDRjTNG relPoGTP6/w8+BxSCdpQgFzHBaVJElQwPTgEJ3UB2buBrWIZXQrQeglSw8RSYukXLd3SK0xEr/sh FGNSbBxT8Bk3PkUQ4KzOHw2Q/mC5UjcNm0KESTj80sdkLYYQURydpN7szQzUQB/FsXysyvcT0kLN 0q3swRF8PDsVo4EqT7MsyTKFRQAF1EAVAjZt0011lKHKxbpMLOZhxAshgAddyD2lsf2DyJNU06rc xxZ91bEJBt47UiQdTTlEpzwoBFaMVDjzS/HRqli81B/NVFcl1kYpRNrsyjiMuI28tgYwrY14VBQi SX87UeuMRWCdOt+xA20NnkOlzTlNLl5MsEJq1iYtSzLFTI1b14hc1X94V02NVxs60EP0VlMqOrAk QVzdV758OlNdTSoVWH/AVoNdnyr0VPBEPWsT1TwwAp20MY6b2FTdnXbVRILN/taMdZJnjFEFXVQa /SFydVbo5ElKVRlWs1aLNR/PgteWlSBDPLl6xVf1AiKWSgJcxdXTLMYnfb3f3ECe7dkpUgyWDdoH QViu9MrWAj7F2rNc5dcn9cM/5VGq7SyrJVSs/aSHCKV+mlMy81KkZZs8YNooo8SGjNZj9FFzO9uB pcW1FVo/Wry6U1aGrVE8WFqIHcmdbD5LpdRJ89sgkIFDHAi1DVyXncvFrE1qzEIlLcG6XdyZy1v0 xK5qlVz+CkQBw9yZ0bTNrc/5u7v5CV0x9TsL60mOyq//jFzU3QFYI1DWfRTN3VLOJci7w8tmWNqN sN3G3bhxo9aITFkA3Dkk/liCyw3eBzGp1xXI42XOIKxbXB1R3CLdKqtQ3ZXeQEWKWZAK7NWX4SVe ZKXVxzzaMFBcbqQdtCtVaMUugJ1av6UiAbva9mUMQ/QdmdScrjCz36Mf5cWNc+XVtHte8cHAZFTV 3gWIHeOwAZaZ44Tfel1gUpzDJFPe2h1fCzPLyvxNVJXaC1a2dAPeDYaSIvVgrg1VEMbLcVVcAzCg jPNPZHzFk6zUFlYODGBRAY5hxphh+D1gMksvEEYy8F1enLouk3W0HZXgP9WlIa7BQV1dJHYUhYNZ tWFix0Oxw20G8DUAPdDDq4K9H0ZLlDzZLf4HI/7iYWk/jNw6E0sso0Xe/jtQXgKQCT2kYh+GXjiG Y8G04C3uwCO2Y6ZQ4omQ0UA7JEY8MjcA5L30SyuW1CiNvZ9E2YCd4yEo4jGwOkdmFJISY6DB1xtu 4rUBZAeusMzTWzPkPAz0OFF+wtuzXBg+5cfAISOF24bVNXE1mCiWhQjVvF79t+BENiHg3VyOBT8S OaD15QdJ5deVRnud2Rl9FlgmgVKF2tt9XuD0yRX23xa2PQ3CCGt2EGFCVG/tWKQsxTIG5ECGWklt 3j1t5md2Pmfu52jGAAq510ZuZ1zITTFmYuM1XjPG1QEgAKPSZ+osyb+b0n+Q2gqO5rakNo/tZYNO CFCsjA6F3a4lZry0/udEIDYrjrO/pJcpRd8hLi8kQMqPhowd3F5tll0g9ONogGif9pN+PVEJ3dmp g2kVNStjmuSYqWnHCGkaRuAys2Gjq4goRhv+sMzbJcMKVVWjTudILuMt8WimLoiL9GCFLuPTQ0o6 8OmHzgAsBlis7lON/lGB5qGkXdCxNpb5XDwFrbb5S+tcc2if3uGshsF0vUwK5du5HszK2GN0ymvp aNvNPVKdBmtwrVE1fmg02OElLMNCLlmuXuygNAMFg2o3gGxjaTcrrDsky77PTWDNgGjNFuTD/rsb E7ggFm0pqmsPWaQ5QG2h+rM/islqu2wn/tqKYGumNVMVnmh7xDnd/h7Hxq67hwPup5gKeO7rWlVS Rm0ewR4ANsgV550zQya/OI7uX0Hq3l4kyLFupwDNbB5F475smpTtnyZsqpxoIEbR00Xv9J7uVW5v 924K6rAMomXtnT69BJ+D715eku1DCf1PdPZveyiv5fngHhpwAqc1Kzxr+j3uba5f8H5o5XFc/l1L IdZiCtdHC/fBI0UqDWcK10XQ+NVpwJ7vsnnoESeAWq7oM9UuoOzqmCZtZNXIGJfx4tFjeebppfLj NygG8PbpeAjyjnvpNF3xOmvx+JlTGD9yhOhOmN3yT1Vqoz1c4mFr8HZrdf3xzGxzgMZyJBFoc/LU FxdrLxes903Y/rNu8tYuxdKUbR2PZQr9VcWms8eFc3vR8he/woK+cyADc7dN1OIGcQZlWDRHnun0 Z5xzaUQfR3g7n+QcY0c3CPaJ9Hhecvr+WBwGdIgmEFzSqjOl0v7udMRQ9ICkiFEn66zja2Eeo6Ir QRGm6hHf8R7dqerM6H+m9TQ8rPdLUPhr9FxngjAe7tJbQHY08183szwY9odeV3Y9P82ccPRGasLs vSWJdgnZolAsWs/NQndnZaXdcfBOhEzPxEQWcgpfBMyIyR5E93TnJRo/4EvJdkr/UigfdkHf72Qf OHw/W8Co9QL7GnP3d18gKeT84OMleMvG1zXgdjJQhcBUduHE/gBFWPY5l3gApnheCGOcNm3I+2sm hzhAT3MDSJlM30D/Owycx3KzkoVlTy2UXzaV14WSm+waFtdabXeWmvkoT2xxFHkizodPjwirePja Q+qgH9ChJ5s47fCjp1Ecn0ZnYHrwnkE/hHrECBB8UG946/lcgXigL3CJ33qiH1yznnQcnmq9Bz5u n3cDsXmL7pqG10eqP6zEaHtpkIa3T8PUaqCTI066/4Ldo/aTcq2NTNqN/8qK6PvwxuXBR90AfLdF KLCIUHtBaQU533fHF/rIF6xnjG9U/3AbR+sD7Huf33lzpvWiDLNUWHz+IrE5F2mtb30uoEKielsP B74OAusE/muGgx9x5RHiz/fbV3Ocmi/5LCf9AudK4pd81Z7Vu5Z9pP9asON8Hk/RWEf7qiT5iCim SN4kaEf3IOPQ2hR/scfNaewSsh+AvuDb6Rd5CFjLSGPtwae0Dj4YiiNZmieaqivbui8cy2yX2Zd2 bFvRNxzwJ+R0gsUOkqhM/giDJ3QgYTASVGuVes1qu94vOCwek8tmqgKtkEgICwLOoNsgG7M7Pq/f 8/t+Vc0NztxOj2EQkdARoqLPkuIPkUEUFAMCFxbW1hlnp+enJ9vE28TFXOJfquoqa6trSoOgqdzp 4dDiLWRu7lJiwQHlk4KBlubmMWiycnKagvPagIKUABvc/gDFIB0SgMer9zd4uHhILG0cbSEPI6RR ++7juhPlGlf98j3+vegoNr+FmwUf3biNK2jwIMIXSHTIOUdIXSRG63odubUuSYFJwdx80ZQpH8hl zRg8WyDlpChs/wzAgWMq0baEMmfSlBlLlikdhwzhqljR3TsmPBtoHCBA2IAEC6wYMxbyKagFDFKm xOHyQqkcderU7Or1a6tyshgS2unIIlqKjXoKHeAg2BQyTqFCHelsAbR9Ks/xrbV1W0ywggcTXmEn EE50PSDq8hWUl0+0HeRRimsPGd3MVKTuq8C3Ieiyf0cftlP4NOrUIcg6LLszkmShP9fGBqLxLZQJ 9uZq/sbX7K5JvZ/RkT1F+viHgaqXM+9qI0O2WjwvKpnYk2J1IQekGY1CrDd4zp2zRidE/Dh6rs3X s09oZw7onIVsSWSXVjY8XAWC5ZaK+T94XzSDV3AFxgHdQwkeoEt66SXXHoQRfpMRdLOUpc5ZPglU R30SAfGhEE7gFgVvAZ6RxlTjtabgQzA1+OJApkk4I416vPfcgdJNd98QRsimoX0cFFWZfyaOMeAa FUjhT3ksbggjlN2oVyOVVcLAmoWnQETddUVMlB0iILoFxVEDTGUkGeIJl2WCirkYpWmlyTnllFba eacJFMaXwy9mNZLfI7Vx6GMRlFHynYkoJhnckipd/iWfgm/CGRgMyuF5KZ4/YHCgmztu2CFkIMIW lJAKlAkFPeClIV6KbHzGol+TUooprbXioWliF9LX433Y/fnTazXw94Rl+Ui16D4AvQqrpDDa+iy0 efyQq5Z+ulMfj46N6gsHw5pZpD5adLYsrAvKamm06arbQkabsvkaUI6B6CFs7YTZwZBRFFsGZ1Mt uuQ1nq3o5Lkyrnswwih48EtDFeq6K72hNqYfoUAAw98woYxHXnzlLthslAmLPPIISTQMH3F9Qkyq fvW2vMhZBRAwIqoEhNHvxq4OTHDBHhhMMtBAM/wcgjphCKrLj2Xr44e3RSGNGGpW5a7HOpxLEAg/ /ge9dcJxKkjc0UkD+ueHTM/GayxPHCXAiBsDJHCTkYL8Itd1203OL23SorKn8wZJmqgxxzyttxuv FHeLcyNX8t2NkxxnERcm7ghQa92bYXYMPtmASdwVWA1LOTJrrrM+Y02O46kDXYeWO0zu97UTXwfP UHn/84YbLj0KNrNwogKL6sEfLOVNRrtulnWD1y4Q0/ZWOAopHFfNA2AOJuezpXEKv/3IPufNg9F8 rxwZE+WXHUmFblTzhoW8H684aQ/S8KDW3NtfK+vhmzWfpxFB7DdDsKK+0M0CbN8zjoOQIyN0ieAw 3KjT/SJIqyTopE9HW4zKLmjBh8RhFLnjWA6M/teiBj2QHItDXQm2Ij8JshBTg6ogBpG3E9cNJw67 K1r4EucsWMyqhT6021a+5wP+GQJDiIEPjkLoJB2O5nQ/fCIUUfcXIX6oELEo4mKmx7sDUs+EKowi GKPoQMA9ZAgadB0aE4TFOVTvL2F8IxwbyCEOlRF8MrygGtv4xTjykY8NyqLHuFhBEmaNeAzsIyLv Vr8SnnCKaKNbIiMpyZLF6Hohe2APnVjCSXIykTvsJChDaRhRkrKUpjwlKlOpShYGoJWtBIErYwnL EcTSlbCsZQBEgEtayvIDuQzBL2cZTF/OsgS1JMEwAbDLYipTl7rsJS+PSUxgQrOZwLylNJk5/k1s vnKb3rRmMldZk2SS05nldOY1kYnOb/5ymLl0pzLh+U1tWlOY6WRmMLvpzXOus5jyxGc/5+nLf9Zz mvCUZzjFORN+srOgDnVoQh/aTnXW853+rCg9BXrQe16UmPnMqERpuc2ETpSjAm3mRzU6UoyeVKEI iSg9LWpSiBpTpA8Fpz0NytKbkvSaBNWpRwGqgnCW9KYxtalIU8rTlSoVpi49iC0putKMMnSmRU3n R1NaUqXOdKdcBSpOd4oCok7VmMvsali/ClaZivWpXYmqNrmKS7JKtaPrZCte11pXobY1rGmNK1y5 CVe5RrWqRt0qSLOa05a6VSb8nCtfA0pV/pUGtbIYVetS4ylNuja1ryFtKGUNG1HFUhalizVqY8dR 1a/Kda+TzaxpLUta2GIVnZwFKGbpus/Eghats+2pbAvq1NSCY7Whlexo+2lcjroTszRd6mMBa1Lg Rja6Vq3pLacb0OES1yDZtGttt2vWag40sL19rmahmc2enrWt5CTva98bWNFiN6bwXW5386vf/fK3 v/79L4ADLOABE7jABj4wghOs4AUzuMEOfjCEIyzhCVO4wha+cBwFoGEBkIy7GAblhjXc4Q+LU8OL XJeHSTxJEQctxSp2AYtDwGERhHgEM5Yxh2MMghvvmMc0rnEJQuxjALB4wz3WMY6NfGQg/n9AyEFm Mo6bHGMon8DJNqaylKV8Yyq7+MUsQLKSl/xjH4sYzGZ+spXHTGUhG5nNV04zm7fsZjWHeck1nnOV 8axlLMc5x2lGrZdjYGYy15nIZx70j0mwYdMUetFaTjKjHW1oHku6ziaG9KOPHGlCC2DTnc40mjet aVBr2dOiZmygYaDjTlP606tuQKsjLWNY41hrjZ7yp5Pc40RHmdST3vWRxyzln1ma0LxW9Jl/rWtg MzvLqE41jOVsaGDjetrOtva0q33lkmmbHN2+9rWRzI1vixvWMy73qo3da2TnmdutPva1uwxtFFRb 2/WWdrj93Ox957vP+N73t5mdbnZP/rrP6wY3trdtAnEnPNnMlve8233pbOea4rKeeJYnXuaKH1zg /v43wgOe7447++Pv7jjDEQ7vZjs83hHXw8Z3PfB7J5rmBD82xp+8cpFje+AKz7nOUT5kfpO84ep+ +MvzEPOMv9vmMpd2yhnO850fXeogt7rKbx7yoWed6D4H+I0hnnRuE9nbZTc7j2k9ZLWjfeGI9nXP j95vYYP71ucW99e37nZ1213oxxb72OkebMHDXdmDR/OoDy/phDM+3XKu+NsnLaMwL77xclc4qCmf 85ZjG/CBPzzc+/5mwg8aywW/NdXpzPnT413Pej946SsfZ8y/HtCfh8Xah07rBnJ9/vdm77i5C521 P9ce4cFvvbuFP27Tcz7vyxf+8Yfe/LDfvvqq8PzYTa797XO/+97/PvjDL/7xk7/8IsZ+0s2v/vWz v/3ufz/8jYx+69MfqfW//wzmj//663///s9vO7WX/bGAc40VY/WfHlyVCSAgdfUBAj6TAe7BA8qA Ao5MAbrWUIFUCnjYBN5BBbJCA/JBB9res7XACL7ABaqLc71TN/WSesUTN6GUPqUXRU3UYDEXDJrX C96gP/EgW4EWC47WfL1SPhGhDJZXcyWhOg1hC8LgM7UgDwoWEsaVR5VTYTmhC/IVE2ZVXgHNT2WX XvUgUunTVd2WE/rVew1UWYGT/lb5VHj94HORof0VVROqoRzaFR3yEnixYF0poBVSoXCpoR5WIRV2 FkshVGuNmGDVYRiC1T0h1HX51V/dlQaW4W7ZViPuYQRC4mlxIlpdojnVlyROVSJ6onIF4kVZlFqZ 4hceTCuiYhFm4Rhi1XcBFSRSF2tdoSZO4SR+1ivKoiP+4FkxYR9SkxEW42ehYXg5Ig4SlA3GVnkt IiiS4LP84jKG4Bp+4BvSYjImoiRa4iEyVQ12VRtq4iu+Fg6KIzKyV3VdYnJ1Ym2p4jjO4SemizXi IQaW4ia641GVFSvuFifO1jIm4zcCZD0SJD+eVjqyYzYmJD06Y1DBITNO4wmujsc9ZuIH6mN8OaR1 eRU4FmFFIZZlDaRuMaJJCuM1rqEgoqFEOqQbNmRInpQcQiRMFiRqVWRzJCEwsmEA3uEToiIN2tRH pqNY2RI4ahZP9uJhTSM2hSReGaF8KWFTJtUMGuVNRqFyQWFVHmNy6WIMRhZSfiVQUmM1chJOXspZ 0kRaMsdatlgEtWVCwGUIRAA=OwA= ------=_NextPart_000_000F_01C73B39.5C1FC8B0-- From ips-bounces@ietf.org Thu Jan 18 15:27:50 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7dr4-0005Ta-BY; Thu, 18 Jan 2007 15:27:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7dr3-0005TV-BB for ips@ietf.org; Thu, 18 Jan 2007 15:27:25 -0500 Received: from imf20aec.mail.bellsouth.net ([205.152.59.68]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7dr2-0001Zg-1V for ips@ietf.org; Thu, 18 Jan 2007 15:27:25 -0500 Received: from ibm62aec.bellsouth.net ([74.245.52.54]) by imf20aec.mail.bellsouth.net with ESMTP id <20070118202718.CORG6321.imf20aec.mail.bellsouth.net@ibm62aec.bellsouth.net> for ; Thu, 18 Jan 2007 15:27:18 -0500 Received: from IVVTDKV0981 ([74.245.52.54]) by ibm62aec.bellsouth.net with SMTP id <20070118202717.CTGO20444.ibm62aec.bellsouth.net@IVVTDKV0981> for ; Thu, 18 Jan 2007 15:27:17 -0500 Message-ID: <000601c73b3f$0c60aff0$01faa8c0@ivivity.com> From: "Eddy Quicksall" To: Date: Thu, 18 Jan 2007 15:27:17 -0500 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.1 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Subject: [Ips] Use of TargetAddress conflict X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0322487012==" Errors-To: ips-bounces@ietf.org This is a multi-part message in MIME format. --===============0322487012== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0003_01C73B15.234317A0" This is a multi-part message in MIME format. ------=_NextPart_000_0003_01C73B15.234317A0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Is there a conflict in wording here? Is the TargetAddress required? Appendix D says "A target record begins with the TargetName text key, = followed by a list of TargetAddress text keys". This implies that a = TargetAddress must accompany each TargetName. But a few paragraphs down it says "Each target record returned includes = zero or more TargetAddress fields". Eddy ------=_NextPart_000_0003_01C73B15.234317A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Is there a conflict in wording here? Is the = TargetAddress=20 required?
 
Appendix D says "A target record begins with the = TargetName=20 text key, followed by a list of TargetAddress text keys". This implies = that a=20 TargetAddress must accompany each TargetName.
 
But a few paragraphs down it says "Each target = record returned=20 includes zero or more TargetAddress fields".
 
 
Eddy
------=_NextPart_000_0003_01C73B15.234317A0-- --===============0322487012== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============0322487012==-- From ips-bounces@ietf.org Thu Jan 18 15:38:16 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7e1R-0005gJ-Ds; Thu, 18 Jan 2007 15:38:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7e1Q-0005gE-Sj for ips@ietf.org; Thu, 18 Jan 2007 15:38:08 -0500 Received: from chip8og57.obsmtp.com ([64.18.15.187]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H7e1P-0003tM-Ji for ips@ietf.org; Thu, 18 Jan 2007 15:38:08 -0500 Received: from source ([12.110.134.31]) by chip8ob57.postini.com ([64.18.7.12]) with SMTP; Thu, 18 Jan 2007 12:38:00 PST Received: from PKONING.equallogic.com ([172.16.1.235]) by M31.equallogic.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 18 Jan 2007 15:38:00 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17839.55977.351000.113240@gargle.gargle.HOWL> Date: Thu, 18 Jan 2007 15:38:01 -0500 From: Paul Koning To: Quicksall_iSCSI@Bellsouth.net Subject: Re: [Ips] Use of TargetAddress conflict References: <000601c73b3f$0c60aff0$01faa8c0@ivivity.com> X-Mailer: VM 7.07 under 21.4 (patch 19) "Constant Variable" XEmacs Lucid X-OriginalArrivalTime: 18 Jan 2007 20:38:00.0392 (UTC) FILETIME=[8B461480:01C73B40] X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: ips@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ips-bounces@ietf.org >>>>> "Eddy" == Eddy Quicksall writes: Eddy> Is there a conflict in wording here? Is the TargetAddress Eddy> required? Eddy> Appendix D says "A target record begins with the TargetName Eddy> text key, followed by a list of TargetAddress text keys". This Eddy> implies that a TargetAddress must accompany each TargetName. Eddy> But a few paragraphs down it says "Each target record returned Eddy> includes zero or more TargetAddress fields". That doesn't sound like a conflict. If the first bit of text had said "non-empty list", it would be, but "list" in my book includes "empty list". paul _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Thu Jan 18 15:44:32 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7e7X-00005X-Ns; Thu, 18 Jan 2007 15:44:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7e7W-00005G-J0 for ips@ietf.org; Thu, 18 Jan 2007 15:44:26 -0500 Received: from imf20aec.mail.bellsouth.net ([205.152.59.68]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7e7U-0004nL-8Q for ips@ietf.org; Thu, 18 Jan 2007 15:44:26 -0500 Received: from ibm62aec.bellsouth.net ([74.245.52.54]) by imf20aec.mail.bellsouth.net with ESMTP id <20070118204423.GSHP6321.imf20aec.mail.bellsouth.net@ibm62aec.bellsouth.net> for ; Thu, 18 Jan 2007 15:44:23 -0500 Received: from IVVTDKV0981 ([74.245.52.54]) by ibm62aec.bellsouth.net with SMTP id <20070118204423.DGGR20444.ibm62aec.bellsouth.net@IVVTDKV0981>; Thu, 18 Jan 2007 15:44:23 -0500 Message-ID: <000a01c73b41$6f7cee80$01faa8c0@ivivity.com> From: "Eddy Quicksall" To: "Paul Koning" References: <000601c73b3f$0c60aff0$01faa8c0@ivivity.com> <17839.55977.351000.113240@gargle.gargle.HOWL> Subject: Re: [Ips] Use of TargetAddress conflict Date: Thu, 18 Jan 2007 15:44:22 -0500 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: ips@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ips-bounces@ietf.org So I think you are saying that the target could return just a TargetName for a SendTargets and not include the TargetAddress. Correct? Eddy ----- Original Message ----- From: "Paul Koning" To: Cc: Sent: Thursday, January 18, 2007 3:38 PM Subject: Re: [Ips] Use of TargetAddress conflict >>>>>> "Eddy" == Eddy Quicksall writes: > > Eddy> Is there a conflict in wording here? Is the TargetAddress > Eddy> required? > > Eddy> Appendix D says "A target record begins with the TargetName > Eddy> text key, followed by a list of TargetAddress text keys". This > Eddy> implies that a TargetAddress must accompany each TargetName. > > Eddy> But a few paragraphs down it says "Each target record returned > Eddy> includes zero or more TargetAddress fields". > > That doesn't sound like a conflict. If the first bit of text had said > "non-empty list", it would be, but "list" in my book includes "empty > list". > > paul > > > _______________________________________________ > Ips mailing list > Ips@ietf.org > https://www1.ietf.org/mailman/listinfo/ips > _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Thu Jan 18 16:00:09 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7eMe-0003ii-PG; Thu, 18 Jan 2007 16:00:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7eMN-0002zj-Di for ips@ietf.org; Thu, 18 Jan 2007 15:59:47 -0500 Received: from emulex.emulex.com ([138.239.112.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7eJw-0007gJ-Vc for ips@ietf.org; Thu, 18 Jan 2007 15:57:37 -0500 Received: from xbl3.ad.emulex.com (xbl3.ma.emulex.com [138.239.73.12]) by emulex.emulex.com (8.13.6/8.13.6) with ESMTP id l0IKv2iH009743; Thu, 18 Jan 2007 12:57:02 -0800 (PST) From: Daniel.Sullivan@Emulex.Com X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ips] Use of TargetAddress conflict Date: Thu, 18 Jan 2007 15:57:01 -0500 Message-ID: <332A49C36DB0F64198D1A011FB1AA7913CE58E@xbl3.emulex.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ips] Use of TargetAddress conflict Thread-Index: Acc7P48ztfeUlCAhQ2yn10IJo0EbQgAA3lkw To: , X-Spam-Score: 0.2 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1951562465==" Errors-To: ips-bounces@ietf.org This is a multi-part message in MIME format. --===============1951562465== content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C73B43.3391F6BD" This is a multi-part message in MIME format. ------_=_NextPart_001_01C73B43.3391F6BD Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Is this trying to cover the case where TargetName is returned in reponse = to a login? During login you don't have to return the TargetAddress. =20 Dan -----Original Message----- From: Eddy Quicksall [mailto:Quicksall_iSCSI@Bellsouth.net] Sent: Thursday, January 18, 2007 3:27 PM To: ips@ietf.org Subject: [Ips] Use of TargetAddress conflict Is there a conflict in wording here? Is the TargetAddress required? =20 Appendix D says "A target record begins with the TargetName text key, = followed by a list of TargetAddress text keys". This implies that a = TargetAddress must accompany each TargetName. =20 But a few paragraphs down it says "Each target record returned includes = zero or more TargetAddress fields". =20 =20 Eddy ------_=_NextPart_001_01C73B43.3391F6BD Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Is=20 this trying to cover the case where TargetName is returned in reponse to = a=20 login? During login you don't have to return the=20 TargetAddress.
 
Dan
-----Original Message-----
From: Eddy Quicksall=20 [mailto:Quicksall_iSCSI@Bellsouth.net]
Sent: Thursday, = January 18,=20 2007 3:27 PM
To: ips@ietf.org
Subject: [Ips] Use = of=20 TargetAddress conflict

Is there a conflict in wording here? Is the = TargetAddress=20 required?
 
Appendix D says "A target record begins with the = TargetName=20 text key, followed by a list of TargetAddress text keys". This implies = that a=20 TargetAddress must accompany each TargetName.
 
But a few paragraphs down it says "Each target = record=20 returned includes zero or more TargetAddress fields".
 
 
Eddy
------_=_NextPart_001_01C73B43.3391F6BD-- --===============1951562465== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============1951562465==-- From ips-bounces@ietf.org Thu Jan 18 16:02:12 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7eOi-0006Nq-0c; Thu, 18 Jan 2007 16:02:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7eOg-0006N7-Nf for ips@ietf.org; Thu, 18 Jan 2007 16:02:10 -0500 Received: from imf20aec.mail.bellsouth.net ([205.152.59.68]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7eOf-0000fs-9l for ips@ietf.org; Thu, 18 Jan 2007 16:02:10 -0500 Received: from ibm62aec.bellsouth.net ([74.245.52.54]) by imf20aec.mail.bellsouth.net with ESMTP id <20070118210202.KVVM6321.imf20aec.mail.bellsouth.net@ibm62aec.bellsouth.net> for ; Thu, 18 Jan 2007 16:02:02 -0500 Received: from IVVTDKV0981 ([74.245.52.54]) by ibm62aec.bellsouth.net with SMTP id <20070118210202.DSYG20444.ibm62aec.bellsouth.net@IVVTDKV0981>; Thu, 18 Jan 2007 16:02:02 -0500 Message-ID: <002601c73b43$e6893db0$01faa8c0@ivivity.com> From: "Eddy Quicksall" To: , References: <332A49C36DB0F64198D1A011FB1AA7913CE58E@xbl3.emulex.com> Subject: Re: [Ips] Use of TargetAddress conflict Date: Thu, 18 Jan 2007 16:02:01 -0500 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.0 (/) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede Cc: X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0053283954==" Errors-To: ips-bounces@ietf.org This is a multi-part message in MIME format. --===============0053283954== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0023_01C73B19.FD754250" This is a multi-part message in MIME format. ------=_NextPart_000_0023_01C73B19.FD754250 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable This is in response to the SendTargets command. ----- Original Message -----=20 From: Daniel.Sullivan@Emulex.Com=20 To: Quicksall_iSCSI@Bellsouth.net ; ips@ietf.org=20 Sent: Thursday, January 18, 2007 3:57 PM Subject: RE: [Ips] Use of TargetAddress conflict Is this trying to cover the case where TargetName is returned in = reponse to a login? During login you don't have to return the = TargetAddress. Dan -----Original Message----- From: Eddy Quicksall [mailto:Quicksall_iSCSI@Bellsouth.net] Sent: Thursday, January 18, 2007 3:27 PM To: ips@ietf.org Subject: [Ips] Use of TargetAddress conflict Is there a conflict in wording here? Is the TargetAddress required? Appendix D says "A target record begins with the TargetName text = key, followed by a list of TargetAddress text keys". This implies that a = TargetAddress must accompany each TargetName. But a few paragraphs down it says "Each target record returned = includes zero or more TargetAddress fields". Eddy ------=_NextPart_000_0023_01C73B19.FD754250 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
This is in response to the SendTargets = command.
----- Original Message -----
From:=20 Daniel.Sullivan@Emulex.Com=
To: Quicksall_iSCSI@Bellsouth.n= et=20 ; ips@ietf.org
Sent: Thursday, January 18, = 2007 3:57=20 PM
Subject: RE: [Ips] Use of = TargetAddress=20 conflict

Is=20 this trying to cover the case where TargetName is returned in reponse = to a=20 login? During login you don't have to return the=20 TargetAddress.
 
Dan
-----Original Message-----
From: Eddy Quicksall=20 [mailto:Quicksall_iSCSI@Bellsouth.net]
Sent: Thursday, = January 18,=20 2007 3:27 PM
To: ips@ietf.org
Subject: = [Ips] Use of=20 TargetAddress conflict

Is there a conflict in wording here? Is the = TargetAddress=20 required?
 
Appendix D says "A target record begins with the = TargetName text key, followed by a list of TargetAddress text keys". = This=20 implies that a TargetAddress must accompany each = TargetName.
 
But a few paragraphs down it says "Each target = record=20 returned includes zero or more TargetAddress fields".
 
 
Eddy
------=_NextPart_000_0023_01C73B19.FD754250-- --===============0053283954== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============0053283954==-- From ips-bounces@ietf.org Thu Jan 18 17:15:20 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7fXB-0003Yj-Vp; Thu, 18 Jan 2007 17:15:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7fXA-0003Ya-LQ for ips@ietf.org; Thu, 18 Jan 2007 17:15:00 -0500 Received: from emulex.emulex.com ([138.239.112.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7fX9-0002uL-6R for ips@ietf.org; Thu, 18 Jan 2007 17:15:00 -0500 Received: from xbl3.ad.emulex.com (xbl3.ma.emulex.com [138.239.73.12]) by emulex.emulex.com (8.13.6/8.13.6) with ESMTP id l0IMEn9F014971; Thu, 18 Jan 2007 14:14:49 -0800 (PST) From: Daniel.Sullivan@Emulex.Com X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ips] Use of TargetAddress conflict Date: Thu, 18 Jan 2007 17:14:48 -0500 Message-ID: <332A49C36DB0F64198D1A011FB1AA7913CE590@xbl3.emulex.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ips] Use of TargetAddress conflict Thread-Index: Acc7Q+mWz5Q+u44jQrmdlDE2gu94JwACfvHw To: , X-Spam-Score: 0.2 (/) X-Scan-Signature: 225414c974e0d6437992164e91287a51 Cc: X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0472158314==" Errors-To: ips-bounces@ietf.org This is a multi-part message in MIME format. --===============0472158314== content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C73B4E.111FCAE2" This is a multi-part message in MIME format. ------_=_NextPart_001_01C73B4E.111FCAE2 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I am aware this section is refering to SendTargets usage. Are you sure = that bit of text did slip in there when someone was thinking about = TargetName being used in the login?=20 =20 Dan -----Original Message----- From: Eddy Quicksall [mailto:Quicksall_iSCSI@Bellsouth.net] Sent: Thursday, January 18, 2007 4:02 PM To: Sullivan, Daniel; ips@ietf.org Subject: Re: [Ips] Use of TargetAddress conflict This is in response to the SendTargets command. ----- Original Message -----=20 From: Daniel.Sullivan@Emulex.Com=20 To: Quicksall_iSCSI@Bellsouth.net ; ips@ietf.org=20 Sent: Thursday, January 18, 2007 3:57 PM Subject: RE: [Ips] Use of TargetAddress conflict Is this trying to cover the case where TargetName is returned in reponse = to a login? During login you don't have to return the TargetAddress. =20 Dan -----Original Message----- From: Eddy Quicksall [mailto:Quicksall_iSCSI@Bellsouth.net] Sent: Thursday, January 18, 2007 3:27 PM To: ips@ietf.org Subject: [Ips] Use of TargetAddress conflict Is there a conflict in wording here? Is the TargetAddress required? =20 Appendix D says "A target record begins with the TargetName text key, = followed by a list of TargetAddress text keys". This implies that a = TargetAddress must accompany each TargetName. =20 But a few paragraphs down it says "Each target record returned includes = zero or more TargetAddress fields". =20 =20 Eddy ------_=_NextPart_001_01C73B4E.111FCAE2 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I am=20 aware this section is refering to SendTargets usage. Are you sure that = bit of=20 text did slip in there when someone was thinking about TargetName being = used in=20 the login?
 
Dan
-----Original Message-----
From: Eddy Quicksall=20 [mailto:Quicksall_iSCSI@Bellsouth.net]
Sent: Thursday, = January 18,=20 2007 4:02 PM
To: Sullivan, Daniel; = ips@ietf.org
Subject:=20 Re: [Ips] Use of TargetAddress conflict

This is in response to the SendTargets = command.
----- Original Message -----
From:=20 Daniel.Sullivan@Emulex.Com= =20
To: Quicksall_iSCSI@Bellsouth.n= et=20 ; ips@ietf.org
Sent: Thursday, January 18, = 2007 3:57=20 PM
Subject: RE: [Ips] Use of = TargetAddress=20 conflict

Is=20 this trying to cover the case where TargetName is returned in = reponse to a=20 login? During login you don't have to return the=20 TargetAddress.
 
Dan
-----Original Message-----
From: Eddy Quicksall = [mailto:Quicksall_iSCSI@Bellsouth.net]
Sent: Thursday, = January=20 18, 2007 3:27 PM
To: ips@ietf.org
Subject: = [Ips] Use=20 of TargetAddress conflict

Is there a conflict in wording here? Is the=20 TargetAddress required?
 
Appendix D says "A target record begins with = the=20 TargetName text key, followed by a list of TargetAddress text = keys". This=20 implies that a TargetAddress must accompany each = TargetName.
 
But a few paragraphs down it says "Each target = record=20 returned includes zero or more TargetAddress fields".
 
 
Eddy
<= /HTML> ------_=_NextPart_001_01C73B4E.111FCAE2-- --===============0472158314== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============0472158314==-- From ips-bounces@ietf.org Thu Jan 18 18:29:56 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7ghS-0004H8-28; Thu, 18 Jan 2007 18:29:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7ghR-0004Gc-5X for ips@ietf.org; Thu, 18 Jan 2007 18:29:41 -0500 Received: from imf16aec.mail.bellsouth.net ([205.152.59.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7ghP-0006dO-OC for ips@ietf.org; Thu, 18 Jan 2007 18:29:41 -0500 Received: from ibm56aec.bellsouth.net ([74.245.52.54]) by imf16aec.mail.bellsouth.net with ESMTP id <20070118232934.MRBJ19993.imf16aec.mail.bellsouth.net@ibm56aec.bellsouth.net> for ; Thu, 18 Jan 2007 18:29:34 -0500 Received: from IVVTDKV0981 ([74.245.52.54]) by ibm56aec.bellsouth.net with SMTP id <20070118232933.JVBG20020.ibm56aec.bellsouth.net@IVVTDKV0981>; Thu, 18 Jan 2007 18:29:33 -0500 Message-ID: <003a01c73b58$828d5610$01faa8c0@ivivity.com> From: "Eddy Quicksall" To: , References: <332A49C36DB0F64198D1A011FB1AA7913CE590@xbl3.emulex.com> Subject: Re: [Ips] Use of TargetAddress conflict Date: Thu, 18 Jan 2007 18:29:33 -0500 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b66a1e94d7d92973ece9e5da449ff80 Cc: X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0206017423==" Errors-To: ips-bounces@ietf.org This is a multi-part message in MIME format. --===============0206017423== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0037_01C73B2E.99854190" This is a multi-part message in MIME format. ------=_NextPart_000_0037_01C73B2E.99854190 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I remember when we were working on this. At that time some people didn't = want to send the target address if it was already known by the = initiator. In my target, I have an option to suppress the target address = for cases when the target is behind a NAT device and hence I don't know = "my address". So far every initiator I've tested with has handled it. But today when I was going over the text it seemed to be questionable = and I figured I would ask. If people think it is questionable text then = I would ask Mallikarjun if he would clear it up in the implementation = guide. Eddy ----- Original Message -----=20 From: Daniel.Sullivan@Emulex.Com=20 To: Quicksall_iSCSI@Bellsouth.net ; ips@ietf.org=20 Sent: Thursday, January 18, 2007 5:14 PM Subject: RE: [Ips] Use of TargetAddress conflict I am aware this section is refering to SendTargets usage. Are you sure = that bit of text did slip in there when someone was thinking about = TargetName being used in the login?=20 Dan -----Original Message----- From: Eddy Quicksall [mailto:Quicksall_iSCSI@Bellsouth.net] Sent: Thursday, January 18, 2007 4:02 PM To: Sullivan, Daniel; ips@ietf.org Subject: Re: [Ips] Use of TargetAddress conflict This is in response to the SendTargets command. ----- Original Message -----=20 From: Daniel.Sullivan@Emulex.Com=20 To: Quicksall_iSCSI@Bellsouth.net ; ips@ietf.org=20 Sent: Thursday, January 18, 2007 3:57 PM Subject: RE: [Ips] Use of TargetAddress conflict Is this trying to cover the case where TargetName is returned in = reponse to a login? During login you don't have to return the = TargetAddress. Dan -----Original Message----- From: Eddy Quicksall [mailto:Quicksall_iSCSI@Bellsouth.net] Sent: Thursday, January 18, 2007 3:27 PM To: ips@ietf.org Subject: [Ips] Use of TargetAddress conflict Is there a conflict in wording here? Is the TargetAddress = required? Appendix D says "A target record begins with the TargetName text = key, followed by a list of TargetAddress text keys". This implies that a = TargetAddress must accompany each TargetName. But a few paragraphs down it says "Each target record returned = includes zero or more TargetAddress fields". Eddy ------=_NextPart_000_0037_01C73B2E.99854190 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I remember when we were working on this. At that = time some=20 people didn't want to send the target address if it was = already known=20 by the initiator. In my target, I have an option to suppress the = target=20 address for cases when the target is behind a NAT device and hence = I don't=20 know "my address". So far every initiator I've tested with has = handled=20 it.
 
But today when I was going over the text it seemed = to be=20 questionable and I figured I would ask. If people think it is = questionable text=20 then I would ask Mallikarjun if he would clear it = up in the=20 implementation guide.
 
Eddy
----- Original Message -----
From:=20 Daniel.Sullivan@Emulex.Com=
To: Quicksall_iSCSI@Bellsouth.n= et=20 ; ips@ietf.org
Sent: Thursday, January 18, = 2007 5:14=20 PM
Subject: RE: [Ips] Use of = TargetAddress=20 conflict

I am=20 aware this section is refering to SendTargets usage. Are you sure that = bit of=20 text did slip in there when someone was thinking about TargetName = being used=20 in the login?
 
Dan
-----Original Message-----
From: Eddy Quicksall=20 [mailto:Quicksall_iSCSI@Bellsouth.net]
Sent: Thursday, = January 18,=20 2007 4:02 PM
To: Sullivan, Daniel; ips@ietf.org
Subject: Re: = [Ips] Use=20 of TargetAddress conflict

This is in response to the SendTargets=20 command.
----- Original Message ----- =
From:=20 Daniel.Sullivan@Emulex.Com= =20
To: Quicksall_iSCSI@Bellsouth.n= et=20 ; ips@ietf.org
Sent: Thursday, January 18, = 2007 3:57=20 PM
Subject: RE: [Ips] Use of=20 TargetAddress conflict

Is this trying to cover the case where TargetName is = returned in=20 reponse to a login? During login you don't have to return the=20 TargetAddress.
 
Dan
-----Original Message-----
From: Eddy = Quicksall=20 [mailto:Quicksall_iSCSI@Bellsouth.net]
Sent: Thursday, = January=20 18, 2007 3:27 PM
To: ips@ietf.org
Subject: = [Ips] Use=20 of TargetAddress conflict

Is there a conflict in wording here? Is the=20 TargetAddress required?
 
Appendix D says "A target record begins with = the=20 TargetName text key, followed by a list of TargetAddress text = keys".=20 This implies that a TargetAddress must accompany each=20 TargetName.
 
But a few paragraphs down it says "Each = target record=20 returned includes zero or more TargetAddress = fields".
 
 
Eddy
------=_NextPart_000_0037_01C73B2E.99854190-- --===============0206017423== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============0206017423==-- From ips-bounces@ietf.org Thu Jan 18 23:03:24 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7ky7-0000Cn-Lv; Thu, 18 Jan 2007 23:03:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7ky6-0000At-Pu for ips@ietf.org; Thu, 18 Jan 2007 23:03:10 -0500 Received: from mail-gw3.adaptec.com ([216.52.22.36]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7ky6-0005o4-6l for ips@ietf.org; Thu, 18 Jan 2007 23:03:10 -0500 Received: from aime2k302.adaptec.com (aime2k302.adaptec.com [10.25.8.48]) by mail-gw3.adaptec.com (Spam Firewall) with ESMTP id ABA31167D2C; Thu, 18 Jan 2007 20:03:02 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ips] Use of TargetAddress conflict Date: Thu, 18 Jan 2007 20:02:59 -0800 Message-ID: <368FBF3D8437A748BA8222526BF930990142965B@aime2k302.adaptec.com> In-Reply-To: <003a01c73b58$828d5610$01faa8c0@ivivity.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ips] Use of TargetAddress conflict Thread-Index: Acc7WPSdBR7JlT0QQIe4VPU7bvAY4wABQqbg References: <332A49C36DB0F64198D1A011FB1AA7913CE590@xbl3.emulex.com> <003a01c73b58$828d5610$01faa8c0@ivivity.com> From: "Sandars, Ken" To: "Eddy Quicksall" , X-Virus-Scanned: by Barracuda Spam Firewall at adaptec.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 3be09dac38eaa50f02d21c7fcee1128c Cc: X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0389891445==" Errors-To: ips-bounces@ietf.org This is a multi-part message in MIME format. --===============0389891445== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C73B7E.B5CA48DD" This is a multi-part message in MIME format. ------_=_NextPart_001_01C73B7E.B5CA48DD Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Eddy, =20 I think it's clear that sending a SendTargets response containing a target record with just the TargetName kvp is legal. While the utility of such a response is questionable there are numerous reasons why a target may choose to do this; you've already stated one. =20 I agree with Paul and don't see any need for the IG / C&C doc to expand this. =20 Cheers Ken ________________________________ From: Eddy Quicksall [mailto:Quicksall_iSCSI@Bellsouth.net]=20 Sent: Friday, 19 January 2007 10:30 To: Daniel.Sullivan@Emulex.Com; ips@ietf.org Subject: Re: [Ips] Use of TargetAddress conflict I remember when we were working on this. At that time some people didn't want to send the target address if it was already known by the initiator. In my target, I have an option to suppress the target address for cases when the target is behind a NAT device and hence I don't know "my address". So far every initiator I've tested with has handled it. =20 But today when I was going over the text it seemed to be questionable and I figured I would ask. If people think it is questionable text then I would ask Mallikarjun if he would clear it up in the implementation guide. =20 Eddy ----- Original Message -----=20 From: Daniel.Sullivan@Emulex.Com=20 To: Quicksall_iSCSI@Bellsouth.net ; ips@ietf.org=20 Sent: Thursday, January 18, 2007 5:14 PM Subject: RE: [Ips] Use of TargetAddress conflict =09 =09 I am aware this section is refering to SendTargets usage. Are you sure that bit of text did slip in there when someone was thinking about TargetName being used in the login?=20 =20 Dan -----Original Message----- From: Eddy Quicksall [mailto:Quicksall_iSCSI@Bellsouth.net] Sent: Thursday, January 18, 2007 4:02 PM To: Sullivan, Daniel; ips@ietf.org Subject: Re: [Ips] Use of TargetAddress conflict =09 =09 This is in response to the SendTargets command. ----- Original Message -----=20 From: Daniel.Sullivan@Emulex.Com=20 To: Quicksall_iSCSI@Bellsouth.net ; ips@ietf.org Sent: Thursday, January 18, 2007 3:57 PM Subject: RE: [Ips] Use of TargetAddress conflict Is this trying to cover the case where TargetName is returned in reponse to a login? During login you don't have to return the TargetAddress. =20 Dan -----Original Message----- From: Eddy Quicksall [mailto:Quicksall_iSCSI@Bellsouth.net] Sent: Thursday, January 18, 2007 3:27 PM To: ips@ietf.org Subject: [Ips] Use of TargetAddress conflict =09 =09 Is there a conflict in wording here? Is the TargetAddress required? =20 Appendix D says "A target record begins with the TargetName text key, followed by a list of TargetAddress text keys". This implies that a TargetAddress must accompany each TargetName. =20 But a few paragraphs down it says "Each target record returned includes zero or more TargetAddress fields". =20 =20 Eddy ------_=_NextPart_001_01C73B7E.B5CA48DD Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Eddy,
 
I think it's clear that sending a SendTargets = response=20 containing a target record with just the TargetName kvp is legal. = While the=20 utility of such a response is questionable there are numerous reasons = why a=20 target may choose to do this; you've already stated = one.
 
I agree with Paul and don't = see any need=20 for the IG / C&C doc to expand this.
 
Cheers
Ken

From: Eddy Quicksall=20 [mailto:Quicksall_iSCSI@Bellsouth.net]
Sent: Friday, 19 = January 2007=20 10:30
To: Daniel.Sullivan@Emulex.Com; = ips@ietf.org
Subject:=20 Re: [Ips] Use of TargetAddress conflict

I remember when we were working on this. At that = time some=20 people didn't want to send the target address if it was = already known=20 by the initiator. In my target, I have an option to suppress the = target=20 address for cases when the target is behind a NAT device and hence = I don't=20 know "my address". So far every initiator I've tested with has = handled=20 it.
 
But today when I was going over the text it seemed = to be=20 questionable and I figured I would ask. If people think it is = questionable text=20 then I would ask Mallikarjun if he would clear it = up in the=20 implementation guide.
 
Eddy
----- Original Message -----
From:=20 Daniel.Sullivan@Emulex.Com=
To: Quicksall_iSCSI@Bellsouth.n= et=20 ; ips@ietf.org
Sent: Thursday, January 18, = 2007 5:14=20 PM
Subject: RE: [Ips] Use of = TargetAddress=20 conflict

I am=20 aware this section is refering to SendTargets usage. Are you sure that = bit of=20 text did slip in there when someone was thinking about TargetName = being used=20 in the login?
 
Dan
-----Original Message-----
From: Eddy Quicksall=20 [mailto:Quicksall_iSCSI@Bellsouth.net]
Sent: Thursday, = January 18,=20 2007 4:02 PM
To: Sullivan, Daniel; ips@ietf.org
Subject: Re: = [Ips] Use=20 of TargetAddress conflict

This is in response to the SendTargets=20 command.
----- Original Message ----- =
From:=20 Daniel.Sullivan@Emulex.Com= =20
To: Quicksall_iSCSI@Bellsouth.n= et=20 ; ips@ietf.org
Sent: Thursday, January 18, = 2007 3:57=20 PM
Subject: RE: [Ips] Use of=20 TargetAddress conflict

Is this trying to cover the case where TargetName is = returned in=20 reponse to a login? During login you don't have to return the=20 TargetAddress.
 
Dan
-----Original Message-----
From: Eddy = Quicksall=20 [mailto:Quicksall_iSCSI@Bellsouth.net]
Sent: Thursday, = January=20 18, 2007 3:27 PM
To: ips@ietf.org
Subject: = [Ips] Use=20 of TargetAddress conflict

Is there a conflict in wording here? Is the=20 TargetAddress required?
 
Appendix D says "A target record begins with = the=20 TargetName text key, followed by a list of TargetAddress text = keys".=20 This implies that a TargetAddress must accompany each=20 TargetName.
 
But a few paragraphs down it says "Each = target record=20 returned includes zero or more TargetAddress = fields".
 
 
Eddy
------_=_NextPart_001_01C73B7E.B5CA48DD-- --===============0389891445== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============0389891445==-- From gaemyrah@totalwebsolutions.com Fri Jan 19 04:12:33 2007 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7pnV-0002oZ-C3 for ips-archive@lists.ietf.org; Fri, 19 Jan 2007 04:12:33 -0500 Received: from dekz1.geology.psu.ru ([212.192.76.20] helo=614n) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H7pnT-0005M2-QL for ips-archive@lists.ietf.org; Fri, 19 Jan 2007 04:12:33 -0500 To: "aimee flora" Date: Fri, 19 Jan 2007 14:12:10 +0500 From: "dwayne sayres" Sender: "dwayne sayres" Subject: Hi MIME-Version: 1.0 Message-ID: <781501c73ba9$e6ba7680$144cc0d4@614n> Content-Type: multipart/alternative; boundary="----=_NextPart_000_7121_01C73BD3.61B24600" X-Mailer: Microsoft Outlook Express 6.00.2900.2527 Priority: normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.6 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 This is a multi-part message in MIME format. ------=_NextPart_000_7121_01C73BD3.61B24600 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 7bit Our pharm is simply less expensive http://hahranih.com/dm/ ------=_NextPart_000_7121_01C73BD3.61B24600 Content-Type: text/html; charset="koi8-r" Content-Transfer-Encoding: 7bit Our pharm is simply less expensive
http://hahranih.com/dm/
------=_NextPart_000_7121_01C73BD3.61B24600-- From gmoody@txingudi.com Fri Jan 19 11:44:44 2007 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7wr6-0003f0-5G; Fri, 19 Jan 2007 11:44:44 -0500 Received: from [61.251.13.242] (helo=mycom) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7wqw-0001Oi-O1; Fri, 19 Jan 2007 11:44:44 -0500 Received: from 213.195.69.64 (HELO smtp.txingudi.com) by lists.ietf.org with esmtp (J/7BZ/I3A1R5 9VK<) id GP'P(.-,6=35;-34 for ipfix-archive@lists.ietf.org; Fri, 4 Feb 2005 04:41:17 -0540 Message-ID: <01c50a73$c3e356e0$6c822ecf@gmoody> From: "Jame Blackman" To: Subject: Microsoft Office 2007 Enterprise ready to download Date: Fri, 4 Feb 2005 04:41:17 -0540 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="windows-1250"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 X-Spam-Score: 3.0 (+++) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Office 2007 is available for enterprise users from November 30, 2006. The end user version is available from the beginning of 2007. The 2007 Microsoft Office System, also known as Microsoft Office 2007, is the most recent version of Microsoft's productivity suite. Formerly known as Office 12 in the initial stages of its beta cycle, it was scheduled to be made available to volume license customers on November 30, 2006, with general availability following in early 2007. Office 2007 contains a number of new features, the most notable of which is the entirely new graphical user interface called the Ribbon, replacing the menus and toolbars that have been the cornerstone of Office since its inception. Office 2007 also includes new applications and server-side tools. Chief amongst these is Groove, a collaboration and communication suite for smaller businesses which was originally developed by Groove Networks before being acquired by Microsoft in 2005. Also included is Office Sharepoint Server 2007, a major revision to the server platform for Office applications, which supports "Excel Services", a client-server architecture for supporting Excel workbooks that are shared in real time between multiple machines, and are also viewable and editable through a web page. While Office 2007 includes many new features, one has been removed entirely: Microsoft FrontPage is no longer being developed; its successor is the Microsoft Expression line of products. Microsoft Office 2007 Enterprise Retail Price $899.00 Our Price $79.95 You save $819.05 http://hd0supraengine.org Please note, that there will be more special offers available for our constant customers. Every effort has been made to ensure the accuracy of all information contained herein. DS Team makes no warranty expressed or implied with respect to accuracy of the information, including price, product editorials or product specifications. Product and manufacturer names are used only for the purpose of identification. We appreciate your cooperation with us and we'll be glad to see you as our clients in the future. From dshejkoqjol@telesp.net.br Sat Jan 20 12:03:56 2007 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H8JdE-0004ty-PB; Sat, 20 Jan 2007 12:03:56 -0500 Received: from cable-247-143.zeelandnet.nl ([82.176.247.143] helo=telesp.net.br) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H8Jcr-0004Ge-Dx; Sat, 20 Jan 2007 12:03:56 -0500 Message-ID: From: "Ciera" To: "Paulina" Cc: "Collette Nelson" , "Danial Olson" , "Salina Lopez" , "Nelle Carroll" , "Janel Woods" , "Valerie Stewart" <6lowpan-request@lists.ietf.org>, "Mignon" , "Alanna" Subject: Time for change Date: Sat, 20 Jan 2007 20:59:13 +0400 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_2A5_B057_0CB89077.90A67196" 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 X-Spam-Score: 0.8 (/) X-Scan-Signature: 841b5d6ad57042632519d2198f34cc8d This is a multi-part message in MIME format. ------=_NextPart_2A5_B057_0CB89077.90A67196 Content-Type: multipart/alternative; boundary="----=_NextPart_DB3_3E79_465EA0D6.602C91F3" ------=_NextPart_DB3_3E79_465EA0D6.602C91F3 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =60What?' On prick the forgiven 13th operation they passed the slow e= dge of the Banks of N cerebric =60I sow have treat hate a purpose in = asking,' resumed Fix. =60Is itstreet This touch was blew a misfortune. Mr= Fogg, in order crooked not to de Before faint three o'clock rod salty the large shed permit was invaded by= spent The garden guide colonel launched a volley shrink of oaths, denoun= cing rid relaxed for There moon was a general disappointment among the pa= sse sensuous The performance turn was forsaken courageous ?=07=06 isit the st= eamers which w pin =60That we might belong have made the tour seen calm of the world inc= lose Passepartout's fell poised visage punctually darkened with the skies= , andplate gluteal =60It room upset is absolutely necessary.'The include = knot wind, entertain however, did not grow as malic boisterous as m Passepartout shaken was not the man to space moon let break an idea go be= g frame Passepartout found that he plead silent could collect not avoi= d telling =60On the beam light cat bridge?' suggest asked a passenger. =   disagree As he was reflecting dare in this end ear wise, his eyes fell u = shot =60No doubt,' lip returned view Mr shirt Fogg, =60by not crossing In= dThe 16th smiling of December outside was the melt alive seventy-fifth da= y sinservant =60And, mark if your theory journey had stormy not been inte= rrupted byOn drawer this day cheerfully the plead engineer came digestion= on deck, went up to =60ACROBATIC suspect JAPANESE protect industry unit TROUPE, HONOURABLE WI= LLIAM BAT =60On the bridge.' =60With our train?' hair =60The United faithful approval States!' said land Passepartout; =60= that's ju =60Yes; curved name with eleven hours to spare gone thing be= fore the steame Mr laid button angry Fogg swore quietly shut the door.bled Without knowin= g threw why - agreement it race was presentiment, perhaps=60Good! you run= polish are therefore hungry even twenty hours behind. Twel=60Certain, si= r,' drop mountain replied the ground engineer. irritate =60You must re = He wound followed the clown, and time soon street troubled found himself = once =60With our train.' language Passepartout mourn wonderful thrust= stopped short, and eagerly listened t Phileas tense kept impossible Fogg had won his wager, stamp and had made = his j=60I camp appreciate will cloud consider,' decision replied Mr Fogg.= time thing sternly tug =60On foot?' asked Mr Fogg.cause Passepartout unde= rstood chalk it all; tomorrow he place was seized with This was remain the organization Honourable flag gleaming William Batulca= r's establirecord opinion steer =60But the bridge cloth is unsafe,' urged= the conductor. arrive mark =60No matter,' burst replied Forster; =60I t= hink too that by put shear Passepartout grow entered and shone depressed asked for Mr Batulcar= , wh Nothing, say shallow commercial you? Perhaps so; nothing separate mine bu= t a charmiThen arrive upset you believe shock that we strung really are g= oing to Liver=60No; on night a ink sledge,' wipe replied Fix. arrest =60O= n a sledge with=60Of course.' chess =60What do you sewn want?' said moon he grain to Passepartout, whom= =60The sticky practise join speedily devil!' muttered Passepartout. B= ut a snatch number produce of the passengers graceful mowed were at once = attrac   wind far =60Would you wriggle like a excuse servant, sir?' asked Passepar= touthread fair =60Ass!' brake replied dead the detective, shrugging his s= hould ------=_NextPart_DB3_3E79_465EA0D6.602C91F3 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

3D""



=60What?'     On prick the forgiven 13th= operation they passed the slow edge of the Banks of N   &= nbsp; cerebric =60I sow have treat hate a purpose in asking,' resume= d Fix. =60Is itstreet This touch was blew a misfortune. Mr Fogg, in order= crooked not to de    
Before faint three o'clock rod salty the large shed permit was invaded by=  spent The garden guide colonel launched a volley shrink of oaths, d= enouncing rid relaxed for There moon was a general disappointment am= ong the passe   
sensuous The performance turn was forsaken courageous ?=07=06 isit the st= eamers which w    

pin =60That we might belong have made the tour seen calm of the world= inclose Passepartout's fell poised visage punctually darkened with the s= kies, andplate gluteal =60It room upset is absolutely necessary.'The incl= ude knot wind, entertain however, did not grow as malic boisterous as m&n= bsp;    
Passepartout shaken was not the man to space moon let break an idea go be= g    frame Passepartout found that he plead silent co= uld collect not avoid telling  =60On the beam light cat bridge?= ' suggest asked a passenger.    
disagree As he was reflecting dare in this end ear wise, his eyes fell u&= nbsp;    
shot =60No doubt,' lip returned view Mr shirt Fogg, =60by not crossin= g IndThe 16th smiling of December outside was the melt alive seventy-fift= h day sinservant =60And, mark if your theory journey had stormy not been = interrupted byOn drawer this day cheerfully the plead engineer came diges= tion on deck, went up to   
=60ACROBATIC suspect JAPANESE protect industry unit TROUPE, HONOURABLE WI= LLIAM BAT  =60On the bridge.'  =60With our train?'&nb= sp;      
hair =60The United faithful approval States!' said land Passepartout; =60= that's ju    =60Yes; curved name with eleven hours to= spare gone thing before the steame      &n= bsp;

Mr laid button angry Fogg swore quietly shut the door.bled Without kn= owing threw why - agreement it race was presentiment, perhaps=60Good! you= run polish are therefore hungry even twenty hours behind. Twel=60Certain= , sir,' drop mountain replied the ground engineer. irritate =60You must r= e      He wound followed the clown, and time soon street troubled found himself = once   =60With our train.'   language Passe= partout mourn wonderful thrust stopped short, and eagerly listened t = ;
Phileas tense kept impossible Fogg had won his wager, stamp and had made = his j=60I camp appreciate will cloud consider,' decision replied Mr Fogg.= time thing sternly tug =60On foot?' asked Mr Fogg.cause Passepartout unde= rstood chalk it all; tomorrow he place was seized with   &= nbsp;
This was remain the organization Honourable flag gleaming William Batulca= r's establirecord opinion steer =60But the bridge cloth is unsafe,' urged= the conductor.  arrive mark =60No matter,' burst replied Forst= er; =60I think too that by put    shear Passepartout grow entered and shone depressed asked for Mr Batulcar= , wh   
Nothing, say shallow commercial you? Perhaps so; nothing separate mine bu= t a charmiThen arrive upset you believe shock that we strung really are g= oing to Liver=60No; on night a ink sledge,' wipe replied Fix. arrest =60O= n a sledge with=60Of course.'  
chess =60What do you sewn want?' said moon he grain to Passepartout, whom=     =60The sticky practise join speedily devil!' mutt= ered Passepartout. But a snatch number produce of the passengers gra= ceful mowed were at once attrac       =    
wind far =60Would you wriggle like a excuse servant, sir?' asked Passepar= touthread fair =60Ass!' brake replied dead the detective, shrugging his s= hould        
------=_NextPart_DB3_3E79_465EA0D6.602C91F3-- ------=_NextPart_2A5_B057_0CB89077.90A67196 Content-Type: image/gif; name="moehyoiyjoufb.gif" Content-Transfer-Encoding: base64 Content-ID: <33df201c73cd56d706b4b0218e354b@dshejkoqjol> R0lGODdhZQFcAYQAAP///wAAAP8AAABm//9mM/+ZAMwAADMA/8zMzAAAZgAAmWZmZpmZmZmZZmZm AP//AGZmmWaZmZlmmf/MzGaZZpnMzMyZmcwzM8xmZgAAAAAAAAAAAAAAAAAAAAAAAAAAACwAAAAA ZQFcAQAF/iAgjmRpnmiqrmzrvnAsz3Rt33iu73zv/8CgcEgsGo/IpHLJbDqf0Kh0Sq1ar9isdsvt er/gsHhMLpvP6LR6HQ4EnO74G+Wuyeds0R1vu7PqAIB5VYJEfHp4hSSKL4KMQYdCj40mgJMjlpGD UJc9jI6afaGGoz6dK5+JpaebcJpygYmYc7CxmYqgiHGxuny1s3S0qqC3wry2wsSljaG1zruLqtGZ vcDIs7+srdWVkcW6iMfP4SW5tsDU4r7NxoHWjuh16dTpf9DRJ8Ptqdbq6rnz2h3bpmJPt4O85Ckk 5wdfuYbnwvEb+G/funrVAjJ8gzGFwWn3eoWkSG4gPWML/v2Z5LiMILKJDhdyrKjQnMOH0lL9oqhR osCELDeK3KPtY7+HQG32U5ZSZjJoAFsShHjzHcuaP7GVPKrVJ8Kv7oSqNNfUIlIYVLda7QpTqb+y X1O6LDhSYsxkESuKrdoVqFhc0pL+DQx3bFCSHus++qbyruOAhH/WnRvDaLbA3HYCzkc25E5sheQ2 DA2rHuNrOCb50XwoLWrIIDHhpEy7tu1gUm/r3n1GG+/fwLt8Dk68uPHjyJMrX868ufPn0KNLn069 uvXr2LNr3869u/fv4MOLH0++vPkmAtKnh6F+vQ0BKtzrgA+A/nnz9mPkv7GfRH8c/9033n/qjQBf fgTW/idCgQvKZ+CD6zFYn3sHKkihfQwWiKF8BwYoYHT9YdhgCQTSJ6KI/hloooILQmjiiy2iuCKL LFL44XXtPdgijSo6iKKFOgZ5opA0/rjfjDPWGOSN04Woo5MmbKhhjinuCKSVFWL5ZIY7yrgkkyBG +aSYZPJoZpVFphkjkWt26eabZ4LpHJRKkniCkWqyeWWaeLZpY52AeiinciX++KWVE0pZ5pA9aulo hCMq6uiglFZq6aWYZqrpppx26mlw7YXa44sOtiLqfCskaWeqqBYh6HM+bujfq2og2GoKr9JKaxW7 MhfrrIfy12sSRzboZKykkujliJPOymGMCJbqZqlG/v6ppK3PJptnh5Lumei3U3L77bjhokDlqMpS K6uycRqrKLJZ8mqnoRPCqWqdSL7pYbwwBkqmtWoyWuORSCbJr4oQbhllvxcyy+G60tYrscQPM+tu gBIubPGpFGdRLL3LAooovvPG12bAhxpcspYhs9lnhTCvKjLCXEYK8IX33lmizsBOzC7PCPvs8LDE rmxmyPcWO3PG/257cdMjH3xyzkiPGTO5VO7cYZEwx9sxpLgyfa67PQtt4c5BS9vwFR9/WfXRqyY9 cpVSzxy3289OPffb13rrd7td8xi40ltj3C/FEEcbtJAhKm52okQXPWbUky+t7+Xt5tmx5vaWyWfl /mlP+nLCc/8sdMXpLj70xoevzfrAPa+NOppacDwumt2qW3nef9/sM9Ody2wsumdujWjG1eZu7rqL qz370KeGinOO0kNPqvEc2159doLa6kPkn+pne3X7Cn9r+N+bj/76R4zP/vvwxy///PTXb//9+Oev //789+///wDMFFEGSMACGvCACEygAhfIwAY68IEQjKAEJwjBLORGTjOplG+WcEEwdbA8H0RCCD80 QvGUsAgnPE8Kv7NCSYSvhd2BIRBkaEIBWvCFNsRCCAcgoJYQ4IcAIIAIhIgCIA5RCfeYzAySuBhi 0OGGJxiAFAEgRR5CsS9KXKITuzGMP6yAiEEE/qMKxJgEWcjiBjPJYFhko4c1vuKKJrAiFbUQGtmc EY3uUGNr7MhGj4yxBGQsYhT0WA7DrLGNb1wEH9tYCTiWQI6QjOQUqVjFSlqxkjxQoxs3WUhLoKOT +SgkIvv4xBQEMowk+KERiWjEMJ5yhpxcS2NG2UhF0vKQpCSECng4SRFccgS8BKYv5whJU9gyj7k0 JEk0mUszJlOUgjwBGKd5xGqy0gi0aGYf4TGbY24zlt7UZQqCSQI5UpKcc0wnMHu5A18sEpex5OY0 oPnNO5YymiO4ZipXmc8hvhKW4IynPd8JT2cykp7iRAE6h0nJYWKSoQ1VZzuPSUhoYuaN7rRo/kBr iU9r5lOf1PwoCr9J0aWAcqAHrShCqbAMczK0mC5VZzE9UVKU3lGeo0TpJnUaThOENIj99KhQ/zlR khq1I2k8qEZ1SkNj7vKRU7SkVM/pS0vStJ7JvGlWkgrPlG50pT5tpSr9qcqy+tOVpIDKJ+rJzIis Zp7gCKUOdzDTI7RmixpFZFvVChUssqKpeUjkVa9Aw4euQbAAPc5wXDjX5Sx2pJgCbCZxGFlHbkqy 18GsDjQ7BsyWkLM9TQ5o8fipFY62DB08rR0oyNrWuraBL3mtbGdL29om0LKaUi10dLtEyl6KtzIA LnWEyxziUqK0OSSsby1lXBc0d7eDYKIM/qXLmS5y1Ao7xG4385IavMKVu/dUg0G7WhlkDnS83sAt VasoBPbycqqJqekzg2tebd5yGS0pgH4BUAD+pmC/IugvC/Tb3wIT+MA0UKlehbJHxO40q+qVaXvX mc5fPjGjyFTqgt8Cyus+WMMeNoGA+Tvi/8JgxPsVMIoTHNCe4KKre7xviKcwirpO0rBSZe85XWrO HjtXviB2cYPlilUQg3UEJfbvCpK8ZBKUmMnlbfE2bfpiLjJyrY1VaEQdKkwJE9PL64ypRAsC5IJO OatV7mZWZoxkET+ZwAEO8JuTDOU498GrJS0JRnt6RnmweZBP5XGYIWrhQUdR0C3AsILx/mySUGKY pH4ms4lF3GY7r9jSbgZwpVnMaEbjtL5GPu+fORHoR0b0kjqWaaEhKlExE/nDZk6pqBfdafLO185t pjOAL03iATvZDnk+6lYj3Yx3pjfLWjb1TGNqY6h2mdWS9qpNz7zMDBdbxtE+AZ2V3Otf41rOJXiy t4P7jGPvdK/F0CR1R/2ElkI1xzt+L6oNS0x2pjrbeZnMTRNi5ZfI2rr4pjSmca3iTRfcybzmNhxe vdkIy6CuaXCwU1UAZxKr+MAIrnjFf71xizPhsT94rhd1QG/UZnEIIlesw5mbXO0it7I6NMCdx5Ny bG6h5n58+W8taNue+/znQA+60IW+/nINtjyhncI5cZTO8MsenaXLNTqyOcV04FT9yG3Yrim869eW XD0HJxfFo7+r76K/gKiSUHTIQY1L9KIi0VHm4K2BncHFGJvdC5cmEMeq94Wr/e0aGbKH3R7wRuLX 5X4MfIczvFQITz2VQe3ox4MdX2US1L6MPzzg3450zgxm8aG+O9ZJjc9p8h2oq2SlEPe++sF+Na+N 1nqsM8/5nOfkKW/Rh1+KGu2L9jv0/A6yw1evT6AK1fjGZz3ywU75e/re8HwWfc6nTxilEj4snmx4 7Z+/eHbQfvTt/iMZT1/8kIJ0skalvkkVSWtYaz4xSWSj2u+aTSP3duRunPXrpT/3/vCbEvn8dHzm d3zMl37OJ0t8VH8c1X6hZV99VmbZx1Nxt30ImFPPdH39l3f/F3kDaE3nt3ypIXsHuGDekG7/1hfT x3AKmE0KeEgPaH9oAXKeFnzfBU7rBn4a2FFlxXpmdVY9SHxoR2NN53rbZRC7cIQ4RUDg5X84SF+P ZxwyyFjIEYXop1w6x3JP+HSD8nUZSClcqBtfaGvVAVhhaBthWIZWp4VSMHRs2IZu+IawBYcPZHZb qIaAdoVSZ4Wegoa0cYZR54V0iEF2SHp7OIhMaAbCdYNk91ct0Ctqg0Q1KHYo2HVDuIZosEHMx1Vt x3+VmCKOyAn7hkeaGGPf14B3/mgCB5CKAJCKBzBXJ3QY9AB6mMeAGeg1JuN3BgiLKCGLGoaBMEiI qDgCrUhHq/V57KeCnMhuqhIhB+M6GWI8vHdeZlFtDuaLYniIwTiMIsCKraiKqriNrAiOq6iNRIgW 1FZQaVZk17gMhsKMsEMyXZIzMydlsoZmpKiO5oZ4KECO2jiM39iNwhiQ5FiOx5V/F+iCC7h/vwg5 3pMv+pI1wQJstaZVBzl27od3TbAMAzmO/hiQ4NiPqwgJEmmQvViKEFh7dyIzDrksdAI+vTeL65eA B4ltpgiM2SiMHRmS2ziOO+mRieWEJPlidXeAEviLSgOPLLk7VShq9UiN2EeU/o6nh8HYkyCpkyFZ lVcpkpx2buj4FCvIdZ0oIeUiLlmDM8MDPCO5hPsWaXD1VpSIkZN3AuE4l9zIjRxZl92Yl53VidpX XHy5lfo4hWGnlYKJiaQllVRniDmYmDCHmE7XmIH5mDuXhcXhWT8GmZ0nmVhIWHLYmZ45W7H1maK5 QIHoQQF0mqiZmqq5mqzZmq75mrAZm7I5m7RZm7Z5m7iZm7q5m7zZm775m8AZnMI5nMRZnMZ5nMiZ nMq5nMzZnM75nHOBAPqDANRZndZ5ndiZndq5ndzZndipAN4ZnuI5nuRZnuZ5nuiZnuq5nuLJBdWZ AOwZn/I5n/RZn/Z5n/iZ/p/a6Z4IkAAK4J8A+p8CGqAEOqAGWqAIeqAKmqAMuqAD2qAQ6qAROqES WqEUeqEW+p8YuqEZyqEeuqD8aaALwAAjWqIkygAfmqIduqIrqqIu2qIw+qL+GaM0KqM16qD8SaAM gAIIsAA3aqMq+qNCCqRDKqRFSqRIiqNbQJ0iyqMA0ABHGqUXmqRUKqVWmgBVmqVHmqMDuqPi2As1 KgJXyqJayqAjMKZleqAJKqZp2qYH2gVMSqCsqABWCQAIEAD+KQJ5CgB7uqZ8iqYSeqYBKqZ6OqZs WqiDOgJ+iqRsOqAlkKAg+qduOqn/yaUC6gAPwIoJUAJ3uqeVCgCfGqmA/tqgJCCgijqqhdqoiaqk VoqopgqqDaqgdAqro1qrpLqk/SmgDZCpYnoAmzoCd/qpfTqre5qqsEoCxfqnJTCrtIqsFrqspWqs hAqqxyqozKqsp3qmzgqg0nqo2fqtdPqrpyqu2Oqq5oqtCnCt1fqpxhqu1+qpkmqrGWqgIeqfu4qX 1xqsfTqtofqr/qqq3vqrwjqrBCuwAaqgoPquesqv3Kqt63quwuqtCFut8NqsFButD3uxtNqwihqw BjutH8unJxCx1kqpFMqlDtCfB6CuJNCp7PqoLEuw51qxnvqvMJusg4qlxCqzIhuviGqs5DqwILuz BAq0xPqz0CqpQGsC/kT7qvR6qju7sNSKrkiLsQ5aoQaKtQe7ofXaAA6gAKlInQmwsi0bAK9arRTr qD2rtiQrtFMboY6arkW7tgBrsf1qtTbbr097t1P7qnPrtALrqgartnPLpiF7tBrrt4SrtWQqt4xb oSh7AHjKjeRqp3iquI2qqjybqDQbtWu7onxaoCA7s27Lue1qtHM7rFLbsE/bsPu6sU07rG6brkv7 tpurt8Nqsi3KpWOrAHLgpWXLtv56tqv7rsYrsSFbsiDquK7rrVKrtt1KvHpbssiKvIL6qJm7rpVb rNDLsHq6vZ6LvC+7trpLoeN7BXH6nwfQACrgshwqr7FavvArrwU7/r+UOrFaILaOCwHte7nym6L/ a7+jOrwBTKn1KqAL0J3+K8AuWsBXqrOTqrtZW768+58IxMBFisEOTKQaLKszmqYVvMFoKsIkHKMl jKETvLu4qp8s3MIu/MIwfJ4REMPkyZ8RIAEnaqIScMM8vMM+fMM5fKI/PMQ9HMQjSsRIbMQMgMQ9 DMQjGsRMPMRKHMVFbKJH3MRJbMVLjMVYPMVcLMVaTMU+zABeLMZl/MVODMVoPMZhvMZprMUj6p4T QAHQKSfUKQF2SsN6vMd83Md+fJ/8Scd/PMiEXMiGPMj8iceHvMiM3MiOvJ78yb7XOQHVScnUackI gMmaXMmcfMmd/pzJn7zJnjzKoEzKomzKoZzKqLzKpdzKp/zKquzKsQzLrIzJslzLs5zLuLzLt9zL m8yf/PvIwjzMxDzMkZzHrbydAZCfy1zMzlyezayf0UzMwIzM13kHd5rN6onN1rnM3nye0fzN98nN 6SnO9EnO3DnN4NzN2anOwizHgtzO8qzLt+zO1RnOvKzJzTwB9kzLvtzJ9vzPrKzN/lzQ1zzJqazO tlzQ+6zNnKzQ9GzQ+ZzLiWzN7MzOzRwH5unOcpDNGk2e+BzObkCdGU3S0IydH43PdzrSHu3RLP3R Kx3QCtzNLB3TJm3TJ33PJP3SMS3ThBzIyKzPHf3NKj2eHe3Q/kSNnuLszSF90z7dzket001t0jxd 1Oa8zjfd0lTt0BuNzU1d1Ixc0dqpzkQd1eJJ1lLN1SCtzUw91C391CiN0inN1mm91Tut0TW90Tpt 128N12ON0W4N1ot8zH+N0Wot0KWM1lvd0BO91Ct90EmN2JY8zfy8147N1+Jc2XKN0Li8zJQ81Vr9 2NbJ0IZd2g4t0ZId0alczYWd1oLtnYr91uUs1Sr92rB90Flt1Ui921l92OGp26Dt2zNd17Ld24ON q5Jsyoy91Hl91kft1qKd00hd07Y93Jgc1dM8106d0S8N0WdN0yJd0jBty8O93eL90aeMyLgazM/c 3u79wn6t/t75O8cWfc/onJ0SvQfdidr8fN/hyd/gDdOkPNqxrJ3kzcr6zdnbeeC1TBStzeAEPtES /s9i/d4WfuEYrp5AXeD0jJ7+HJ+oTZ8MDuH4/ckR/t8mzuEpLp4fruI0XOEZHuMyPuPXSdjeSeLY CeAsrtoDTp463ssnfuLpXeI57uJBbuBEjtjcSck4ntoTDsusTeNSPuUWbuNK3uHn2eLrGeLzOeLj OeQ9vuQrDuRHvuMDbeQsXM0NAAFr3uZs/uZtLgEUIOd0Pud2XucSEOd3rud07uZ+Dudsjud8PueD TuiA/ueILuiBvueL3ueNfueG7ueK3gB4DumOLumMTumW/m7piM7mgz7poL7plU7nCHDocB7ql47q kT7p8FzHYHLH9U3lsj7rx52/CKDItJ7r4Zncuo6fVv7kPO7kwv7hP37d3OzPBQTsvHzrFi3K6LzQ wV7s0T7tqBzlvb6ebnDozd3OwQDO3B3Q8TzWbyCdOH3t3WnlTW7u7dzpa/7UxZYAFbDWHs0AAY3r yZzNlsvSCxDN6Q7fZp2f1q6dDUCfA6+fBT+fAQDHQezTh+Cl/57Oj+0G+66d4X7Q+U6dFkCdERDf er3R5dDCrc6da27Nmxznu2zv0r7Kcm7iPx4ASmzFjN3KhxDHmKDL3qwHd0rvoRwBsR7x1MkA1FkB FqDz/tc83jxO2bmcQAHO76oN49gJ9LyenfwrAge/nRVvn3Rc9dvs5lQ/9XAu03hgxTV/274Q3ddp 7xcd3i7PAA2Q3fLJ8fecaHsNybga7ppMAdJ56naOyckdzG1enX+vyFpvnpqu6HYK9GP+24BOAiP6 5mAvAl5Kootw75BdCdl84Dz/ydEM9GvfowHQAERv3P0d3naN1wKuwCHm2Wo9+rl91ybt9NU553ls AvYO5+QunU+KAAM/AnQM9D2PAJG+nQCAxydAnYN/ncG/7kEsAo3f5o8PAAvA/B8P8c3g22hfnbFA 0tEvAqXu8mTN08bN1L1d3Sh9jGV/181tzuq/0r9e/p2ST/HIzL6Qb/xvDgDsfet43+ycbOfcf8pX b50gAAEIWZIT2UANMJYoEqxz2zLLzQQIzJeBrRYE7EwnE1CoLBoRDJcRGJu2EKMdMxoLcItd7A8Z fpGPyVp3OUZ2SeCpm6qc0+v2O75GEjVJT4RKgwTFoAQUH8ICQIMVgCFLCcViX9MTlFEhYeBKihWl icgl0gwLAI4NzkJWlJKlItHnD1pay2qJYt/Ola5njCrl21pwFpMt8CwQLWycGPNbsVye9DS1UApU T6chXQmkEwCiJOIEn0RZn6hRnSFEr8+Rukl2wGY9KYSxm9ApgOVOTzZ9tQTCAugHm5grCzyZ4gLP /gycKdCgnaAYsMmZWlzUMBPmMY6uaiJH1tmTzsSgkyVIWZlAiNCIQIBcMIpl8xMnlTcx2rOXj2Cq G2hungnAIMbQPrhyWfBk1ImOZT/auHFY1SExrGtsZkxGRAhFNlYjbvHSiCRakjwk2fzTB4Y1EnH1 QDl58R3ePoxc3DViEOO9nkX+Iq0hFCzRpEXfRtBp9kvSnZ/62jSYsdYcY3cpm0jrWSQJQzd1Si5t Ohbp024Ck/pJcEjkT0WPLu4jWvaOhQs3DlTtm6s0174/E5dGgu3DzeduKk/+tvK5voQp9eCSY4ZV ypcz4/375Xubv42ji7Wa5Cfh6eSdYwTv/t/y/vjszxavPyd06t/69/PfCV7ye9/1R8ltqgVgQH4D KrhgCfY5qMQ1O3HWnXx5QdeEeg/5daGFqk3I4Cd/fFghhR76NqJkzaHzIIsmgWhaTS/KOCONNdpo 4osstjjTeh2WKOFz88nD4YYYklhhekH+mOR8TE7W45AcOhnlkko6maGPPej4oEkvZfKllz2R8mUg YBYiZk9marKCmhIEUk+bYbLppZxojklnnHniuaeZcPLJZz1l1skamnq2aSeigR0a2JYOrtUopJFK OimllVp6aVr43WhTop0SOsOnnooaKqmjmloqqiqkuuqp3mzaIKagIYDcq33oECCuueq6K6+9/vr6 K7DBCjusgAmCGKusBdZqhCrIOvsstFUA6E6t0eYRIZVX9qhtVPvkEJS14YqbqTQN8LLtCxQ0ie64 JSGAyLLMZvRKK5a0ey++9+WHD7U7SSDcaPnqwaOGtXYLmzWmCLzwvf3qdS6KkgCMGsMuTtvMfhM0 WwO9BxygEW8Miwytw03waywChVyhn8iPtrfhKkxoW/DBACjg8QEKAPBxFZdth1ZRIwtd0iWEmVty dzBJa8FgV61iUMsppzMWxh3ttzEACTTwAM4JWOPzEmhUE/TQZdN1079ImyAJFE1VcLTVNkVN6wTm VbSF0xJdNZUXVDuRhAIOcN1CAjnrATZY/mJTQ7bZlE5gAXG9uBcJxMtBUsEgJGAellhNRK0sHGaB FIbdo2/1wsZb49z14UvQkgZkkGE2+1e1n2c7ZrfXDlbIyrz+FePI5A7yz9RMcLwFBFxwgQEGXPCZ OwKWkHZqC5UVwOZVd8TECFG76sz2EQ3zBd5V2QqEAwgUrjM3iAOvOO2676777fTjvntmYSfeO/7x EyF/8ezwuOQxr3kGNCAGoHcJqnTjXJSARDF0oIWyiE8dFXvXAgU0EdKdznwevAUQGuCAmx2ABDdj 3xX09z7azS9/s/MKDN8XQ6+4jjeyi50KEzc8/12LABgo4AGDeEDl/fACRTzi8pAIuSqI/sIWJ4tF O7KCETFwjj75wpbVhlHBsBBDe1FpwAECUDicoTCFOlwh/oLHwxnKsI00hN8b49i/nwWNcQEUwgSK KMQ9Og8DP8SAD5UXSCP+kYhL7F7BjnA0vpyDEV08xwbjFjV4kaVv5mlDViy5N3ls7GNfKEXrzihH OPKwhaW0o+LqKDZVrjKVrSzlNAaoPD46jyQIYuJNnviJ3QCIKgyE1cJc1h8Una8GB7DXfdx3nmUm w3ewROUp4fi6aW4EmkWxIe9ChhbkKa+AzxvJLRGppEXG4gYyO1IsUPC51PwHRFgzRSzueIcAqrFx +bOiZx6HlnCq7QS6lI0EFzQ3hCSy/khZQpcfupIroNmhnvb8XxLwGSt+MrJg5PzRJp+0LrlcEHTx 0pg8HyrSLfHTUw6s1gW/p1EfUUkyNRspTCMVTl/100hC2skkUTYj68Wrpz796ScM8Jv86BSnKSUo Rq2k1IfEtKmTCudINsrSpeLFqVa96kOhitWtcrWrlNKqV8Mq1rGmBaxkPSta0yoEs6q1rW7lKlvf Kte5ijSudL0rXhlm17zyta/W2qtfAyvYSgF2sIY97IMKi9jFMtaWjX0sZD+j2MhStrKTrSxmG3vZ zHLWsJvtbB2QZ4HRkra0pj0talOr2tWytrWufS1sYyvb2dI2tgCoLW5fezy0ToCI/j4sLQZISwDh Ene0wzVucZOX3OMqF7nObS50ocvc6S63us+l7nWtK13tYne72f2ud5PX3fFyt7zgJe95i+vDH1pg AmHNY3DdC9r5FudxBsCAfLHKXvry10HJS6BVJ3ABAvS3wPZ5HAHyO9I8HtLADv6MBb4JUwk/uMKe ibCCG3eBBlu4wyOxAIDtCWIPkxgtwbVnHjNc4hXjQcAiDjGLY4yHE5sNvzK+8R1cXLY8Fuc7sVpm Q/MQUs/ysQYHbMGRo0XhkfGYOF15UEiHPOSxuVCuzVtrOK9s5M9u6QIqXtiInZxDMeNBylCu8lu1 jGSoqpnLdVAzSWgstNH2WIXK/tifQq+5nd/9T3iw1GHwbKhNPsvQZ9pcM4IMCABFM/rKjU60o+G8 ZUVPWqtJXvOW5+DoN1N60ZGu9KI9M9yy0ZnMrmShRl5ISjvbDoCqroOrTblnUmLzz57G9K1zreVd 35LXms5yr4Od6Vx7utNKMDaWcV1sX4cawjAWWak9c+hYizKaYwZy/9BIh1jPOoc0hGa2I93rTFMa 2MVGch4kTexk41rdymZ3uy0tbM/IeWRh/gzi6kk2cMPvhfLzM6xPyT9v329+sks2pJt964Sbm+F2 CCKWJX3pNoM14cdm87yH7e5q3NveHGYooPu9xlWf0d+oLrgL9X3yJ1Nbnole/vhaQ71pI8v85b/W eMaZTWyJD7vnuq44suP8cTAPfSRPtvW+SU7rVMv65Kcu+L9RfU1rX9znO5e3z3XObIorm+sZ/znY 363w4nQc2kUXiY+zuW1pKjQzte7dwFFucLhPnXfVnvahey5xc8MbzrwW4rLLTUvBIzrYn4Z44YF9 aROfHV9lV6v76uPQzgI+LY8n+lwjX2enc9bS9G78vaJN17xL++j9Rbzln80w0eO49UKoN7RV7/rW X15grJ9962G/etDjvsS1z9ftSw5y4W8eylMmyfEvlfzFcX75LNI9mGXvoG5Pn0XOR/u4Jo/vMpua JL93PO+3P+bi2+f6VBaX/valzX3xM57Uja8fHfFucNwxs4YAX+WgB51tarIaZKt+Y+6wEkRZ2505 U/zBn/0FIKy9nZ85lAHWn//tEB18X+i9H9MpUyrRD7aB2yjNwtPVXbXt3weu0Z5p4NL5T9KZXMBd 4P9FXQvZzw7RUQa+mqzdEfTZnvTRID393wj+2Q6KnCn1nwxa09OFoOnVzwpRnwuGYBBSm8jB4CtV Gbfx4B1QYLsEXw9mExHq4MENYASWnJ45YBFGYQrK3cjxYAx9YdrdEQfeEBDmm9SRHkTVGtS54R3c IPBZYBBS3RRy3hMSXBOuHQ3uDxWaYdOhobYNoh8G4sq9of5E3RIqIdLN/lj4iUvyzJMPMt0hQh3J dSALmaDTlSEgcmK2bSIjMqIoSmEnTmIMomAo9uAW2gEe4kuTraC+AeDB2eEXqmHepV2qTZ4zCeL9 6aIWPqH+fWL+BZrrPFPcHSAXOiHA7ZueAaESeJnZLNlimV+7aGNXudmz2NhjcSP69ZWOkVoO+pUc 9t7n2ZM1qqOMlaPZWKE7Glg7smMlzuN8yePCzCI+0pcPfdmObVg/VliEWZURDWSBwRdAPlSE3SNC HhaIEdhW5dGGLeRDGhZFgmNXPU4SAZJ5hRd6geRHMpdIppdJliRKhqRKjuRIruRJumRKsiRy+dDy VCRvDRCIzeRoBZdyVR0XTw6XT+pkTvbkTgrlTzbXUSKlUS4lUQ4lUBZlUx5lUEYlUz6lUyolVWal VUolVGolVm5lVX6lWE4lWHolSVrkRaalWq4lW7alW74lXMalXJpNCAAAOw== ------=_NextPart_2A5_B057_0CB89077.90A67196-- From evert@hushmail.com Sun Jan 21 04:30:40 2007 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H8Z28-0001Qi-57 for ips-archive@lists.ietf.org; Sun, 21 Jan 2007 04:30:40 -0500 Received: from [59.14.73.146] (helo=hushmail.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H8Z26-0005uX-HJ for ips-archive@lists.ietf.org; Sun, 21 Jan 2007 04:30:40 -0500 Message-ID: <5e4b01c73da8$a4c28500$051b04dc@evert> Reply-To: "VICTOR" From: "VICTOR" To: "MARY" Subject: Benjamin Get rid of everything you are indebted for without paying an other cent Date: Sun, 21 Jan 2007 22:08:13 +1200 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.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 2.5 (++) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Visualize the NewYear with 0 Debt and absolutely not paying back one more dime. You can contact us at : 1--561-282-9476 information or to stop receiving or to grasp postal The horrible sensation of falling, the darkness and the terrifying noises, proved more than Dorothy could endure and for a few moments the little girl lost consciousness. This gave him an idea Zeb, being a boy, did not faint, but he was badly frightened, and clung to the buggy seat with a tight grip, expecting every moment would be his last. He rolled upon the stone again and began rubbing the rope that bound him against the sharp edge From herminagriffin@totalwebsolutions.com Sun Jan 21 19:06:36 2007 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H8mho-0004BL-8W for ips-archive@lists.ietf.org; Sun, 21 Jan 2007 19:06:36 -0500 Received: from cpe-69-203-200-38.nyc.res.rr.com ([69.203.200.38] helo=shakeebg4l3ku5) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1H8mhm-0006Nm-S1 for ips-archive@lists.ietf.org; Sun, 21 Jan 2007 19:06:36 -0500 To: "cy helge" Date: Sun, 21 Jan 2007 19:06:36 -0500 From: "benoit burnaby" Sender: "benoit burnaby" Subject: Hi MIME-Version: 1.0 Message-ID: <3d23101c73db9$2e7fa5b0$26c8cb45@shakeebg4l3ku5> Content-Type: multipart/alternative; boundary="----=_NextPart_000_3CA3D_01C73D8F.26CC7660" X-Mailer: Microsoft Outlook Express 6.00.2900.2527 Priority: normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Spam-Score: 3.8 (+++) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d This is a multi-part message in MIME format. ------=_NextPart_000_3CA3D_01C73D8F.26CC7660 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Manzilla! Size does matter! You seen this on TV! http://dozornie.com/ex/ chicken corn ------=_NextPart_000_3CA3D_01C73D8F.26CC7660 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Manzilla! Size does matter! You seen this on TV!
http://dozornie.com/ex/
chicken corn ------=_NextPart_000_3CA3D_01C73D8F.26CC7660-- From shellysheldondenney@names.co.uk Mon Jan 22 08:33:24 2007 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H8zIa-0008Az-QE for ips-archive@lists.ietf.org; Mon, 22 Jan 2007 08:33:24 -0500 Received: from 62-30-126-19.cable.ubr04.wiga.blueyonder.co.uk ([62.30.126.19] helo=oem8jkboq6enri) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1H8zIY-0000fe-VH for ips-archive@lists.ietf.org; Mon, 22 Jan 2007 08:33:24 -0500 Content-Class: urn:content-classes:message To: "analise ailsun" From: "killy sheba" Date: Mon, 22 Jan 2007 13:35:18 -0000 Sender: "killy sheba" Subject: Hi MIME-Version: 1.0 Message-ID: <7cd701c73e2a$284b4ac0$137e1e3e@oem8jkboq6enri> Content-Type: multipart/alternative; boundary="----=_NextPart_000_713F_01C73E2A.0F333070" X-Mailer: Microsoft Outlook Express 6.00.2900.2527 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1896 X-Spam-Score: 4.3 (++++) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d This is a multi-part message in MIME format. ------=_NextPart_000_713F_01C73E2A.0F333070 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Manzilla! Size does matter! You seen this on TV! http://noterhalod.com/ex/ Greco-mohammedan ------=_NextPart_000_713F_01C73E2A.0F333070 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Manzilla! Size does matter! You seen this on TV!
http://noterhalod.com/ex/
Greco-mohammedan ------=_NextPart_000_713F_01C73E2A.0F333070-- From cluelesig@mediumlite.com Tue Jan 23 00:27:29 2007 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9EBt-0003kc-J4; Tue, 23 Jan 2007 00:27:29 -0500 Received: from [59.39.103.111] (helo=mediumlite.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H9E8D-0000Wo-5k; Tue, 23 Jan 2007 00:27:29 -0500 Message-ID: From: "Enriqueta" To: "Toby Nichols" Cc: "Annamarie Gilbert" , "Paul" , "Fletcher Johnston" , "Sanora" , "Jeanna Bishop" , "Bart" <6lowpan-request@lists.ietf.org>, "Reyes Wallace" , "Alline" Subject: Finally, its time Date: Tue, 23 Jan 2007 13:17:37 +0800 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_E5A_B92A_FA21423D.92BE3697" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-Spam-Score: 0.7 (/) X-Scan-Signature: e654cfa5e44bd623be3eb2c720858b05 This is a multi-part message in MIME format. ------=_NextPart_E5A_B92A_FA21423D.92BE3697 Content-Type: multipart/alternative; boundary="----=_NextPart_B02_DDD2_4C6C4917.A8F0BBA6" ------=_NextPart_B02_DDD2_4C6C4917.A8F0BBA6 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable One drove minute more, and shock worried the wager would proud be won. An= dre except =60Can suggestion put practise we enter the harbour?' epit= hetic scrub The distance hour between Fort Kearney fled and Omaha, as th=60= Not squeaky mammilary under park trod three hours. Only at high tide.' = auctorial His course stitch decided on, basket fast he went on board the = =60Gener =60I painfully afraid! Very father well; bound I will show b= uzz these people tha =60All breath slimy aboard!' enjoy cautiously cr= ied the conductor. On more that fact very sung machine day, however, he met Passepartout fac= move At the fortieth second, coat supply paint nothing. At the fiftieth,d= ark =60Stay,' replied shirt Mr thumb Fogg horse calmly, without betraying= creepy What coil dug serpentine a journey! The travellers, huddled close = togeQueenstown is the fear found Irish want port at compete which the tra= nsatl When Passepartout had finished, he increase tongue stitch strung found hi= mself r =60Yes, ring all aboard!' weary cheat flower repeated Passepart= out, and imme dangerous But no one care heard this pin middle sage ref= lection, nor would a   damage =60For this glue talk wild time - yes.' At fallen the story fifty-fifth, a loud muscle cry was jump heard in the = stPhileas Fogg tickle nose counted on gaining written twelve thoughtfully= hours in thjog oven =60If nothing breaks,' multiply said Mudge, line =60= we shall get theThe level =60Henrietta' blown vivacious entered Queenstow= n point Harbour at one knew =60Then let me destroy have dam rub a word with you.' The clock opin= ion pled locomotive own whistled vigorously; the engineer, And they pass= ed poor over! It myrmecological owner was like step a flash. No one = =60But!--' Mr, uneven Fogg had made plan it use for Mudge's speed= interest to reach crack strap stamp inquisitive The players rose from their seats.The party= went on shyly shore at easily meal once. Fix born was greatly tThe go pr= airie, across turn invention food which the sledge was moving inneed Phil= eas Fogg at last crash match obnoxiously disembarked on the Liverpool share =60In soap talk troubled your master's interest.' The paper train= pursued its course, breath end strange that evening, withou celiac Thi= rteen hundred wore and eighty-two excited miles fierce had been pas At appear ball the loss reply fifty-seventh second the door of the saloon= But power at this grubby family moment error Fix came up, put his hand up= onBut the breeze, far drawer from love lessening proved admit its force, = blew=60I am.' Passepartout malic seemed fit lively to behind be vanquished by Fix's coo= lperson suspect During the night Camp raspy Walbach was passed sign on th= e le It tenderly was shave repeatedly here that the Union Pacific nod Ra= ilroad was in =60You knot have given me strip a thrashing,' lie stale said Fix. =60Good= , awoke osseous Yes; degree gave Phileas Fogg in person.=60I obey arrest ch= ain you distribution greasy in the Queen's name!'dust silently =60These c= hords give the fifth swept and support the octave,' saidPhileas Fogg was = in play check noise prison. surprise He had been shut up in =60Aha!' shirt list cried Passepartout; =60you cook are relaxed convinced= he i Fort McPherson was left disapprove behind at eight gleaming fowl= behind in the mor The one nervous shame hundred and sniff pencil fir= st meridian was passed.   =60No,' replied Fix coldly, =60I decorate boot addition smoke think him a= rascal. Ssex Passepartout, silver when he defiant saw his crept master a= rrested, wou ------=_NextPart_B02_DDD2_4C6C4917.A8F0BBA6 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

3D""


One drove minute more, and shock worried the wager would proud be won= Andre  except =60Can suggestion put practise we enter the har= bour?'    epithetic scrub The distance hour between F= ort Kearney fled and Omaha, as th=60Not squeaky mammilary under park trod= three hours. Only at high tide.'     
auctorial His course stitch decided on, basket fast he went on board the = =60Gener     =60I painfully afraid! Very father = well; bound I will show buzz these people tha    &nbs= p;=60All breath slimy aboard!' enjoy cautiously cried the conductor. = ;     On more that fact very sung machine day, however, he met Passepartout fac=   move At the fortieth second, coat supply paint nothing. At the fiftieth,d= ark =60Stay,' replied shirt Mr thumb Fogg horse calmly, without betraying= creepy What coil dug serpentine a journey! The travellers, huddled close = togeQueenstown is the fear found Irish want port at compete which the tra= nsatl   When Passepartout had finished, he increase tongue stitch strung found hi= mself r   =60Yes, ring all aboard!' weary cheat flower rep= eated Passepartout, and imme    dangerous But no one = care heard this pin middle sage reflection, nor would a   =  
damage =60For this glue talk wild time - yes.' 
At fallen the story fifty-fifth, a loud muscle cry was jump heard in = the stPhileas Fogg tickle nose counted on gaining written twelve thoughtf= ully hours in thjog oven =60If nothing breaks,' multiply said Mudge, line= =60we shall get theThe level =60Henrietta' blown vivacious entered Queen= stown point Harbour at one      
knew =60Then let me destroy have dam rub a word with you.' The clock= opinion pled locomotive own whistled vigorously; the engineer, &nbs= p;And they passed poor over! It myrmecological owner was like step a flas= h. No one         
=60But!--'         Mr, uneve= n Fogg had made plan it use for Mudge's speed interest to reach &nbs= p;  

crack strap stamp inquisitive The players rose from their seats.The p= arty went on shyly shore at easily meal once. Fix born was greatly tThe g= o prairie, across turn invention food which the sledge was moving inneed = Phileas Fogg at last crash match obnoxiously disembarked on the Liverpool=    share =60In soap talk troubled your master's interest.'   = The paper train pursued its course, breath end strange that evening, with= ou   celiac Thirteen hundred wore and eighty-two excited m= iles fierce had been pas    
At appear ball the loss reply fifty-seventh second the door of the saloon= But power at this grubby family moment error Fix came up, put his hand up= onBut the breeze, far drawer from love lessening proved admit its force, = blew=60I am.'         
Passepartout malic seemed fit lively to behind be vanquished by Fix's coo= lperson suspect During the night Camp raspy Walbach was passed sign on th= e le  It tenderly was shave repeatedly here that the Union Paci= fic nod Railroad was in  =60You knot have given me strip a thrashing,' lie stale said Fix. =60Good= ,  
awoke osseous Yes; degree gave Phileas Fogg in person.=60I obey arrest ch= ain you distribution greasy in the Queen's name!'dust silently =60These c= hords give the fifth swept and support the octave,' saidPhileas Fogg was = in play check noise prison. surprise He had been shut up in  &n= bsp; =60Aha!' shirt list cried Passepartout; =60you cook are relaxed convinced= he i    Fort McPherson was left disapprove behind at= eight gleaming fowl behind in the mor     The o= ne nervous shame hundred and sniff pencil first meridian was passed. = ;         
=60No,' replied Fix coldly, =60I decorate boot addition smoke think him a= rascal. Ssex Passepartout, silver when he defiant saw his crept master a= rrested, wou         
------=_NextPart_B02_DDD2_4C6C4917.A8F0BBA6-- ------=_NextPart_E5A_B92A_FA21423D.92BE3697 Content-Type: image/gif; name="xaettvhaxy.gif" Content-Transfer-Encoding: base64 Content-ID: R0lGODdhZwFjAYQAAP///wAAAP8AAABm//9mM/+ZAMwAADMA/8zMzAAAZgAAmWZmZpmZmZmZZmZm AP//AGZmmWaZmZlmmf/MzGaZZpnMzMyZmcwzM8xmZgAAAAAAAAAAAAAAAAAAAAAAAAAAACwAAAAA ZwFjAQAF/iAgjmRpnmiqrmzrvnAsz3Rt33iu73zv/8CgcEgsGo/IpHLJbDqf0Kh0Sq1ar9isdsvt er/gsHhMLpvP6LR6zW6733BpIPCc2+mnue2Of/P7NXwsegCEcXKARImFfYYkjjGGkEKLlJUui4ST JZqXh0ubQJOSnjShiqU+pyujjaWrn0ybgpIjnbd4d5yuIrq4j3YmoZ22wb3GuozKjL/HsC+zyNKQ pMDEzNXYxcnLsSjcwMKut8fLydfh5d161+jq4uq868XM5rn39tDG6Y/b+N303hHDxavdP4DerO0L yI8dnWAGFyLE5qhgpoPxpL3ThtDXP4P5WvzZBe5PolYM/gfig/jxoMOE3wTtgleOXSF7HrPxa/jw IjiAIGtifBl05EiRMhmGc6gz5TiWQns60ygUZp6fGwX2ZIpxW9aJ66TOjMkpo9mwVUNSS3VV4kR0 VHkqzQf1rUWrbSuhzLg14LmuYKsVvei3r1p5Lw+nfeaPZrq/X92p1Ip4KGO8JPclbfq34km9lT0P KymW4kZaLu+RujwINEvPmX229Nr4NGvMuHOTcau7t+/dbH8LH04FK/HjyJMrX868ufPn0KNLn069 uvXr2LNr3869u/fv4MOLH0++vPnz6LEIWL8+Bvv2NgSogL9DPgD76cXjl7H/Rn8S/+UQYH7fBcje CPL1/mfgfSIc2CB9CEbYnoP3wZcggxbi5+B7DD6oYYUEVvffhyCWYKB9H5IY4YMNduhigijG2KKK KLZoo4UhTsehjR2eCCGNL5q4IoZDXsijikfeuCKSOTo34pInLOjhhDsWKaGVQN5IYY1Bdtnkc08q aYKULvI4JpZoJjmjlT1CaeaXzIXZ5pl0BskkkHiySWSJc5LIJJzK+TgkgFECSB+FehrpoZpdToig olsOCuiklFZq6aWYZqrpppx2KsZ7oGq4IaJwgFofC1zWmcKA7h3BKpgKimqoN/u9CoOtZRa6Aq5V 8LochHzy6esLwEqh4KJC/phhrIS+mKWJkWJYa7E1/gKL5IZQ1ipsjzgmueWhZR7IobhUwhijuRUO WOWU0For6oiKjvktjIY6asWxd3Lpp5CNipnqmX7qK6mM4S6ZosHQaultkQcrnHC6LJaY4aMRFyux rMISPCWrpM6a8bdvUoHvwG7OKWmfyc63ppp3Mrrytvvya/K+F8bbr7zpplqumTvnGuWJP3vcccQ4 UxxsxcMiYa2XLJccssD1qrxno+vOnDLRkD5dMs17jootzjLKSu+00vpcb6zuKvvokxarffTF6l2d a8wma1333c1mLaauLWM89b9NN12z3CevbO+ahyNus9GHatwz1ksTbTTSP1tsbLOYB363zv7uXSfZ /lbnfTLofz8NtZd0660u6ZAXffTEGbcebONGug1746pmYeran/Mu+exH5vmwtsqG+Se87wJeNs8/ Mvxu4bMz+3vsQoe68bLj7n4x9tvTXvzQOkodMg5Je+qe9tZxLLMO5ZtP7Prux08E+vLXb//9+Oev //789+///wAMoAAHSMACGtA5JkmgAhfIwAY68IEQjKAEJ0jBClrwghjMIAazEJwvPWRSt0lCB5s0 QvOUUISdOiF5VHgEFqbHheGBoSJSaCkZDsGG5cFhd3QoChpWioc/UOEAXsgCAhgRAAQQQRJRcEQl KkEzIVQBFF1DG2FwEAUDyCIAsjhELXxmHDrg/gZvpjiIFSwRiWdUQRpR2IubtBEHH/zgG21Bx0bk 4YpYHEEXOQgIO9rxBnKUoxvp2MY/pqAUa1wjE6MgyJMoJhOD7Ickb2LISVrBE3vMpCa1uEUuerKL nuyBIAfZyLKAxJGXcGQhCXlINZ6giUo04hJnmUZZGqGUj5mNKe84SVyWBQulGCInRQBKPW7RmMcU JjJF2UtSjiUodfzGLynJSmmmQJFOzCYStXnGWRYhF9V0pkDaMk1W+tKSVQjmMUmwx04qk5jwZOcw edDHaM5xjvKI5FTKiU9xtvKaJfAmCWy5TW5is4f+7Oc471jPaZ4znMVRwTuRyUlhcnGZFQ1i/jMr 6c9aWDGSkFzlPXm5yIEaNJvdDOhB6WlOh6bEig/tJ0dHGlGJmqCY8GxnPNfJU5a2lKOG9Kg9Z+pM oqLTBCnl5ggEWtCCrjSMzYxqSPoRSGtSk6b6rGkKdHrRT3rVncT8pCo2Gs6gdqWqWZUpRPn5SlgS VJZwPSJc0fjUHMjELUFVBhVN08fVWPWSO8jkE0lSxZYWcpT7NA0p/coK5qRSo8AM7EXZoJcZHsc4 lMBjcjD7zRpqFjmctSylgDhWTpE2O6f16aZSex3WQtW0no0sbEEBWj5q8La4za1ud8vb3vr2t0kB 7GxHewXEYsq11UEuHH1IXNmuNrbFZS54/k6oXEBKVw1kDCNjCesMkgoXBjqVA3frYdfsjpc3bD2D H9cqgzgmtKgQre4esKjFyQahq+4M5SEbetW0RsKND10vVo9qggIYGAAFQHAKDiyCBLfAwAmOMIQh bIr3imUgMPUufGkq30BsdZlA0OQ6ccpQso70wivZpYYF7F/2jsDBCIbxgmMA4wM7+MYVBqouR5FW VfY3pNHN404ral+vTla/7EwyiKVoYn0ORsUf/amLB9zgEsgYBVdmgYy3PF8Lm5OoEtkrYDpc4Q/P c6IkLiaabzrPJf9TrSf+cnzDTE4Ap6IUWWZwgyms4BhbWc9VxnKXgSrnAY8SyClOr3jN/lyCTQ55 p2ENrx65iokmsziflQVplBP95hNkuc+gxnGgA51nPr/Ywwo17Dx2CeayRvm7J5hoTnGKZBH3FNLt lLR3L+3ShQ51rYRm8oxJEOE/ixrUfl4Bl2fAXx9XJsPgJGlMyczsFYR3zbfmqWAbvW1ICxvOTi40 NQBsaHu2mMrIVnCNRV3jAl952aOGwV15LFPjkpcW1ijslOtgbW4bOb8WBaVYk2xfsJYx393tNSWN 2xlNVBG9BCb2qUM98XZX/M8Tj7cs/vraIOeg22nIdGaVzWA+T/jkMV53nlNObEC3EOKQ9TgOkGyG 0N4QurDOFLUR+Fmd4zydBqAOmXfe/hyiy/u6cDK6PoDL9KY7/elQj/pve37cn2tVU0pXTtZFgnQP Uv1SW6+tc7Fu9SmEnec//PoYvigK8yKcvN9eA8wBWZGYgPHV6dxBXS0h1R1UNdg/buzBodEEo1o3 kCKfttptSVCkrnTvdtU0uhduFlRynNdxl+adcw7T2UCSxZbG+9UDulRXQqHZrNix5Vds7s031vWj pwk0zY1VzEeckQA1qFvRGMveyzWJkP+vqq2KaXGM26WGn3y09aoaFJfGI2Ap87eLb3wCcxrInDdp E5Pq1NKjFPjAZ+bwpf3Sj/JXysoX/GLf2GxffqTjb6Z+hg3tXg6r3YmJ3H1TkyrQ/uATfvybVn6/ Vnutp352J1TLt35s917SN30CGE3JF3iKhnsA1U1MdYHe13/il2rEVxgqloChl3n8tHwJWBB+wYEN 6IBnQVUMuGFZdXYiSHret39KxXvd11TwB3fxV0cMNw0Ol3A6yHEjqFDnJ3nkNnmtMXd5ZRPVN3xu t29OkAq1FFd01Xi/x3hV2AUiFwSeMEWvUQ8L0VcmEYRRKITLNXaXNXcjl4ZR1GUy53Nph4ZVF4dv OIfNVYdgV3aL9lx0eElS94dbAYiCOIiEqFv3d4cgdIiJ2Id5N1yLiId6mCMw2GlwiIiNyIeWGHu7 gQRiFA13F4O5sypkcktvB0fb/vV2Y6SIXtCGOSZS4eaKsLcqZqMrUZhXy1V/ryiBt3d6KHAAvggA vngAV+RCKFYTUDaEsGiAKLA4y8hvtsiDlTd/yKiLUFh4KSCMIoCNXmQKqneM6GR7Zig6FHM49AIx yNItHadjZ8FjW+iC2HeJJyCM2giMwUiP9piN9WiPv4hQ7VVoL0hnyLdvqXAtY1MxW2OQ6ehq+ARm xxeCu8hvKjCP2oiN+yiPIzCRwLiGwrd+BGiE6HduIIk+UJMlu/MnqOZlC8lehxaAMzWJ4XiRJpCP GImPGDmPpdWPKRlnJEh+EVgKx9I5qGM3s1htKGhW8UWNH/mOmgiTE0mR2ciU/k4Jkxp5dDk5btH2 WMkIim8SM5yzN10ZeUUpbp93hCx5lHIolRmZlmlZk2hpkVwofX7UgwSxkJ9IiVGzKOICMTuyl8ti jmcIhKomFWLmC6g4C2pXj4gZjIopj4uZmPcYBu0Yc1r3kieZfcJhc1N5mWqoWpbJiEmnip/pmWbX dSQEml4nmgfkd8Tlkhpmh4/oh4W4WxQRm7RZm7b5QKZZmqm5m7zZm775m8AZnMI5nMRZnMZ5nMiZ nMq5nMzZnM75nNAZndI5ndRZndZ5ndiZndq5ndzZnd75neAZnuI5nuT5GwggQAiQnuq5nuzZnu75 nvAZn/I5n/RZn/Z5n/iZ/p/6uZ/82Z/+6Z9c8J8COqAEWqAGeqAImqAKWp8BigAJoAAPGqEQOqES WqEUeqEW+qAYuqEZyqEe2qEg+qEcGqIkKqIleqImOqEpiqIsuqIumgAtGqMf2qAXugAMYKM4eqMM IKMVyqMv+qM+CqRC6qMsSqRDeqQhiqRH2qAVygAogAALgKRGOqVKKqFVeqVTSqVaqqRY+qM0KqEL 8KQA0ABH2qVbyqNnaqY/qqZpWqRsaqJMSqFOio/+MKQJIAJv2qYeOqQjkKdrqqd4qqcd6qch+qUU GowKoJYAgAAB8KAi4KgAAKmD+qiEyqGBOqF4SqklKqSBqqmYOgId6qlZ/gqhlxqhJcCiokqoJwqj ZhqnE+oADxCMd0oCjAqppAoAtzqipVqpEtqnkBqpL8qjlLqrthqquLqln2qhxCqiiXqsvKoAz6qs W5CeEtoAsYqnBzCrIsCotyqpzfqrwNqstzqsoNqsfeqr5gqsJEoC6fqt7Zqp43qpJACuv5quFUqu vjqv9iqukXqq8Qqs+uqt3pqp7Dqr8WqrAFuumeqmgnqhF2qo1tqY6cqtkkqwuTqrMPqopdqp/Xqs 5CquBmulymqvGourG3uuHOuuxVqyF/uwHpuwIAuyJWuxBsuxHYuhp8qxIUuwO9uxNDuzzrqpDVuo 0+qgCuAADnoA6VoC/rX6rwpbAtDKs8nKrzCLsSbQq+XqqANrsh2LtaZKrtr6sgibsBkKtt+qqSag smB7Air7qS5rtiz7sWgLtcuqoRkqsiqapHiLqkULoQ3gAArgi9SqtLQaAJ/6smJLoVYbtDqrs1Qr tKSKszd7sod7sezauC+7oSlbs84qqvKauZr6tZJ7r/kKuje7uFP7tZBrt8zKunoLrUSrBdR6tAfQ qIoZtovaqFP7uQ4rtVtLqltrsC6qrm5bsl47rgJ7tjBrtqQbvHPrsqqrvHnbtt7arY8rvXKrrrua qiQ6tDNatBGqtHcwp4VLoY4LrpGKsfuqr5trs3VrvqPrviH7r+B6/riZW69fy7I9i7j6K7P8i6/m e7li66/4er/0+76D6r0W6rRWkJ6H2gAq0LQyCrvR+qYVPLRUisC8qsAUjLWya7QTCgERrLsTzMEK bMKVWqXcW8EXbL9Y4MBgKp8k/Kct3KYo7L2Ke8NlKrI6nL9ZMLsR6kB2WsNqSsQ2bMRdOr3PGqcl GgFc2sNsCsV6isRnGqR7u6INuqBavMVc3MVe/MVd3KARIAE6mqMSMMZofMZqPMZlrKNr/MZv3MY2 +sZpnMZyzAB0nMd3nMd1TMY5aqN43Md9vMeCHMd/HMh8rMaEnMiKfMiJbMeOXMiQ3MaP3MiUHAGS bMlmnMlsfMg5/hqgE0ABEVye35GeErCoYJzKqrzKrNzKCtqgouzKsjzLtFzLtNygp2zLurzLvNzL AtqgEMyeE6Cew5yexYwAx5zMxLzMzIzMzazMxvzM0hzN1OzM1QzN1pzN2YzN3DzN2+zN3XzNxBzO 3yzO5lzO6EzO2JzO4NzO4tygIuzL8jzP9FzPwIzK2vyeAbCg+1zP/pyf/aygAW3PRRvP7skHjJrQ /onQ67nPDq2fAf3QCMrQ/CnRBfoH9DnQAN3QB/3P5zmtoYzP7KnR6TnQ6ryexUzS6hnR58zN/TwB JH3S52zNKs3OM/3S7mzTK92e3azRMo3MOO3TCp3Tx6zTP33S/rgs0hzN0f1sBxDdnneQ0E59nyzd 1HNQ0lg91PZJ0lPN0ox61VIt1WA91V9d0zI80mPd1SUN1lu91God1fIMy/iczAj90F5N1WqN1RaN nxJt0X2d1XhN1nq901Xd1ArN1nu90Ts92INt1jJc14Q91I4ty0mtzyMt1oJdnxpd1VpN1Ydd1ldt 152d0VD91oDt15Id1Wyt2Kct2WL91ISt2q7ty/ds2Uw92uRM05fd2C0tzX+92WGN0zOd0ijt1X/N 2GEN1Act1L29zxMwzJyN3KutzgOd2Kjd20Sd3b0Nz0q92JF912291MFd0ZGd1eAd3t5919Gd3LMN 2J6d3q5d/t18fdu87d67XNvXLNx9vdpbDdey/dWwfdiI7d3vfcxwrdV5LeBrbdUmjd4LvtJjXdbN fNaL/dZTvc6UXdDd7dEc3uET7c+gHMvLfeDvmdspTdElTtQYfZ8mPuErPuE5neI8vcwO/eIwPuM4 vs0mYdv5nONGrd3sXNkePuREXuT7KdfejNJJvp+57Z8/baBFfePwieHVTJ9Ujs5Knp9NPtOrLORG /uUKGuVgHsZFG8zzKeZTPuFbnubYjeX2uc5H7Z5ovuZZLszPjOZ1LuN23uZn3udtHufvrOFjzsoQ MOiG/p/4rdN1fuX4Sef6+eQFOudvLuV4rueSXuVS7udu/s7lXszdDQABnx7qoD7qoS4BFGDqqH7q qp7qElDqrF7qqy7qsk7qoP7qtR7rt47qs77rtN4AqX7qsK7ruQ7sw27rsm7srL7quH7suF7syi7s vO7rz07s0g7tyX7ty97rwU7tyL7s3Q7tIU7KaPDRRZvLh37u6E7PSJ7u7N7utezl7j7LG66gZh7v CJrofw7kP57v/L7vPb7gF+7NC9TvT27uiw7wDU7wQN7iCq/w3G3v/zkHvc7fBx0TEM3g7yni8KkH 5ynhEB+fiV7pH7/c0Q4Bk/1YCVAB7+3QDFDTBp/P+5y7YL0AAS3yX4ziryzo8dkABsrzC+rzAxoA C+DJ/m3s2IkwpyR+1qEt9DWt8VDd8WBtAekZAZO9n1W/3JywxeG+8wYtzqU+3KY81ws/zaY+9tUc AAxwx38s3NmcCDb6CO7s0L3AqC3/zBEw7wDezwyQnhVgAXXf0GQN6AnPzhAE+IGf3fDOnnvfAEDf ngAgwiLQ+PDp9AcqypJv9Z8+6pEP+aRu1n3wx7ZA2n0E4O758m4N4XOQ9g1w3uTN15hA4Py57ttM AedJ6ql+zGYez6G+nrufy5ePn9WO64u695i+1aAu6iQw9KPu+SIwpzcK9yIv91nv3O1593Ue0HuP 9ntP8w3w950N04gd4Rif9PEZmdTv0wmO8Qmd+Ol5/uqobAIGT+od/9E8z/jkLsp7j/fUDp8AcMon kJ4g0CAjWVJSA4klGTQMs8QMAMiqGrBlUPuLr6bb8RC9oE83ZEkARGNgGADWEJAAYwmVtojRkXap fYKRvXNQHP0WxcZuFCmf0+v2e3DUcO5i/B3F314Ngx4OAATEnwQFwt/IBEnkSaBTJOQIQCCZItFl ymDJZYAKqKLPjIzOJQLrEU0Q7Bhmi93sCM1Tz5tOlZOS1xbbGjBYkbFkMuZRWlxaFwuxMde0I941 djbSSCdRLihj+F93jUhNU8MeSeAKGW4VUfiJ6Yq5u9VjdKlKjQyhzIJbZWL1E3LPSJI1SZ4A0eUI /spDPlNuFYPGy+IbZAeZAVCo0KBGjVyoXdRm8mQdPX9Y6UHQZA4JdQhodAuUiM+EThKUEcnHgk4T CA9b8STxiKWLRPRwmBKI8AcsWURp8Vj4tOPUqbmK9jKyIGLAIawiVSyb8ewEN1l1yflo9axIjHCs oayLkpvPEozykmDqaAKlJoZEyGx38HBfe4jduVi61OlVgH5AMk5SiJnAhrosPMQyMwvWFmtEq/kS xrRcMhw7suaolsfokLF72a2trdUmd1t3XMqTyYdRX0Y9EadKRDHL4mtbKGXqvIFYnhwnv1VtFbOn CHyRKXEL+XByxGOvpmmrXNRh2+qvjRB8b/vi/vjyn8CfH+U50++rYVVnK+RyfyS4p5oOX33lTGjz KWjdNd/Ntx6EKSGQW1bhVbjYBBaOZ1xR92zIwodPIIXFDSmwYeFAdazC0yjEuPjFhtqhZ5yLAwn0 YYgs6rjDiz2OliOHVLESIZHbuFTfgkkquSRiLzbpozRMxoOkagZQKSWWWf5WZJEqgefhjrxhqJyG 55HJJIpaHpRLhmOKGeSX86WpYJn0cdklPog1ouZ8e/L5J6CBCjqooHfiKdOFcALpTp2Jggjmm4/C KSmli+IY5qVCdnimopA62mimkYZqqXKGEolXYKnKE45jTK0KzqqBtepYrKyqUOs8z+H66q2U/qg6 q66qCrvrsMXWakqvxPJKz7L4zaqssek4O+2zwzpmaoS4Ybstt916+y244YqLTXtXCgosutSqm+5S 67rL7rpJwUvPvO/aWy+68BBawrgmjUDhvk9kASXBBRt8MMIJK7wwww07/HCN+gZMV7/sHTkxGQFV vDHHGy9GG8ZbdiwhopqKiumMF4KGimSSjfwyzHZRXAd01qSM456j6hgzHXiFTITGP8wBA89FG90z klfYHJ8EDr53NHAIIDqnoCsTApMNUGtd9FDu1AwP1eskqODWfHRz2BhOHzRB0AXVcMABQrhVNt39 ds0JyIiJA5d8ZfvcZDRSss0RFQDALTeC/nUrDu7dTygt8T17q93T1tryOAZZgZu8Vo5WA6AA3Aco YDhwq61WF2aLqw7cUTx9zddYJ0RtQXTCVDqz0eVeHswxTLadQAMPhJ5AHqabkUQ2qXN5+uqnItn0 0u5UQgJnLrx2kN8TrpSRWFFKU0xstm/BwsoKOCB8DQmIXvrx5QmRPPLNezuBBeoN1eM6eYeoTgWM jND/9Uizg+wNiDtxccMw5tI7UQQteKEbHvua4QyPxIEY8WPN+zCYuiNwUIMZlGBCMDPB1lwwhO/j 4NxQkiELEOACFzCAAS5gm67VSEB5yxgY1gDABcaFX5WTWj6ogUAFCqM7sPFGDxyAAPWN/g4mxjvh BZWnPA9ikIQe7GAV29I+5CEIDVs8AxaziA36sfCFMDwjDDEww0eETw83PM4vWpAFzY0mgNk7WxHN MsSQCDCHLNBYAxwAugOMAHRN/MUXqzhFL36wg2AkIRoiaUUJonCCHtmi+yY5xTsggAAYMCMaQ3nG Fn7yAqU8pQtRWT/h8NAKb9yBUE7DozbIJXslC8NZ9GiRtPEQNA04QADUF7pDIjKTjFykFjMYSUky E5KJ3CAXMRlFRZbQDhMopSizacpPYsCTLfTmNk1JylU6ASfEed3mRIBL6RBxDHdk4zG8V0fYSGE2 bJBE0OJGjEFEcJrIVOY0P0jNRgYU/ppQPChCw3jMal6DjC3MZgxRYiVWuuNx8DnQk4Zxz+BozXJo UpLVDsAfOZBnoJbsiHdQWkLXBHSgivyIBVFawYKaMIsxrQ39WmhGGZ5kouUUUUxeSb6AhCk+kSBg fZzEp7bZoDInYR5B5aciX6yHfnWZqGLIkBOhRmOOWcqenxwF1E5BIlSeMxhKoOpSqda0nBzz6VBy hE6xjo9RKBPZ0XT3Mwaqla3bwt3W4Aovrg7KllRaVMoW4zm/MtZUPlVY9OJEV+z9EI97RcBXLqvZ zWrWAAuC3L4Me1etbqoVoWosarfl07t8qrRjdVRqYyvb1a12tra9LW65Vdvc8ra3/r6V6G+DK9zh 0mG3xD0ucm1r3OQyt7lSXa5zoyvdwE63utbVGnSvq93tgiu73P0ueLnk3fCSt7xXNS9601ub8aq3 ve4FAHvfK9/yxne+6yGnfWNb3/tud4UW+C+AAyzgARO4wAY+MIITrOAFM7jBDn4whCMs4QkjOEPB nQApPRlgDACYAB0OsIf/G2IWfljEJSaxiVOM4hWPuMUndrGKWfziGasYxjKuMY1vvGId27jHOfYx joPMYiDzmMae/KQFJpDba3JYyfl9clUtYAAMOFm2SIYylonEQjWmdgIXIECWwxyhnFaZrUrGr5jT XBsL8NSvF0CzmuOMEjaXeXVv/pYzntfM5eZZYM95/rNJONy8a9YZ0Ia+g5f57OdDM9oOglYdlRst aWu2uW7XXM+LxhXGZNpCvhD1KRprEOqRVZpul1bPEyPUV4HSYdVp5TRyYRgEWYt6tbQmdaG11mdM wxrVeHC1q5/aa+LeGr62BjWRin2SR9ftv7z+YuK46JouRlumAEVcSxPZSEtOW6GtMV21z2hsK4m7 3LIOtbnJrexaF3vUPnC3sd+923PXwd3mlje97eLhxTnb1+3bpNyuvVaCYlGKrDZm/Ayu7W9HVYzx fjitIw7qiUq81nKoOMQnbnF2r5vdxcX4uDG+XzrsWnH9ts3pvK3tf2by2il3/jjCBc5Qlqp84PEW N3zlPe536xzn3l13x28NciQEvd0Ur+3QUcJsupUc5ckEuEmzzeqCt6XaMX8p1GnecBddnNw37znE wZ7vOcAb3iHX+cZn/fBZGz3tG++4NprOdDi/+t8zT7jUxUh1u7c675sWqBdZXtycj53wYee5unPe 9bcfHe1C17ja3b5zx88b57VZetlOXptUZx3vDfenwPc+h38qvOUv3TrZIY/2ya++7RlnvMfX/njF u/7ojZf8yO8g98zT/alcByGnRTjtqos+pTK3qXeobQaWnhDcUJ092/FNdNVnPJQh9/mnsc/x7Z/b +hyfuNmX3fuj7X64qVY1/kPzK0o983v8vj0/hKBuX6Rf3v1F0zxzrb555mfZ+3Ypv67Z36Q1GuZt DQAO4AAeIPkJIAIaWgEGYANGYA0ooNHgnzShzrD5W5Ho37MVTbAJG8yFILg8INRQYPxloNNt4LZ8 4Lf83Ql2mgbO2aIZIAOmoOl1IPphCwt6iwvi4Oj5YKDV4MtYoPs8EvFV3ek5ErYBn7UdT+LMDSO1 VQotUhfhnfFUofChXhNKIcxdUrSllP7B1LZtGvOAYSVxoVqZIM8QYcL93SahkDLBoUsZlN4VX0IE nwuWnrelkEppEDL94R2alFrJoRz64cEZ1B4GXPApYs0V4hyQIPnNYBGm/h/geR4VzeEF+l36idDB aZIl9mDpRZ0kdaEl/iAmhl6viR5CLWLURdWqqWHMsCEqLt8TfuIYPiG1vdwtbmIgluEphiJN0dQo bqFMjdBUzWFMdd4k1uEgJuMnOqOjCeHIyOIlcl7M6eEdwB82diInkiLplWIwuqIzLd8hwqDgfd7U HZ8j3t0s3iASQGIFgtkxApwjbiPL0aE1GiI39mLf+RMwimNL3aPK9VUj2uIzoeI6AmQ1gqMcwGPR nFo/Zl0UFmMIkeEX5iLxDZ/8ESNUOR8lcaPxtdVaTWEVVtNMAV5JdqExZqFNjV5KFmJI0sEF5JrW lBp57aDW4GRv5V7H8UQaeunk0QAlbiWa6sCidHGgBNqFQx7NTCalpBHl6hilU2ZZU8rPnU0loEnl 0SwlVuaXJ9Gk4niZNHalerFZapkSWYYZk4Eln11lWtpXn8mjbF3Tm7HlW6LWWDYUN9mlX9FPKnXT j4FYYAoZkRXmYOpYkRHmYRqmYgYZACQmZDJmZC6mZBqmJ7lQXV4YGfWZiYUYh5EYAXhmZ/7XZ3qY aIImaY4mZ6LmappmarJmaaJYbMqmasbmabpma9ImbNYmb+4mC+Gmbb4mcPbmcPpmcR6nbhqnbiLn iCXZXT4ndEandE4ndVandV4ndmandlZXCAAAOw== ------=_NextPart_E5A_B92A_FA21423D.92BE3697-- From cellaeuotad@fantechilaw.com Tue Jan 23 00:29:01 2007 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9EDN-0004Pb-BI; Tue, 23 Jan 2007 00:29:01 -0500 Received: from [218.21.101.244] (helo=fantechilaw.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H9EDG-0003xn-Dn; Tue, 23 Jan 2007 00:29:01 -0500 Message-ID: <7e6201c73e5a$135450a0$0824028a@cellaeuotad> From: "Michaela" To: "Sally Fernandez" Cc: "Jeanene Bennett" , "Pennie" , "Sonja Nguyen" , "Marisa" , "Shane Morris" , "Jackeline" <6lowpan-request@lists.ietf.org>, "Christie" , "Francesca Torres" Subject: Happy with urself Date: Mon, 22 Jan 2007 19:18:19 -1000 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_821_7147_57DC2B91.EFF2491D" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express Macintosh Edition - 5.01 (1630) X-MimeOLE: Produced By Microsoft MimeOLE V5.01 X-Spam-Score: 2.5 (++) X-Scan-Signature: 4fc59e88b356924367ae169e6a06365d This is a multi-part message in MIME format. ------=_NextPart_821_7147_57DC2B91.EFF2491D Content-Type: multipart/alternative; boundary="----=_NextPart_109_9423_FCD75D6B.E3707220" ------=_NextPart_109_9423_FCD75D6B.E3707220 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =60It is roughly clear,' whispering replied stuck Gauthier Ralph; watch =60= and we hav Aouda start and he had remained, saw despite ring string the = cold, under manage squeal At noon nut the wine next day, a man mounte= d the bridge tocondition leaped That average gentleman was really permit = ruined, and that at the won He was open actually on hour board tumble the =60General Grant'. The= conductor was circle look fighting quality beside Mr safely Fogg, when h= e =60It shall ventral be stopped,' said bell plug pocket Phileas Fogg,= preparin subtract stop On sowed bound reaching Yokohama, the detective, leaving Mr= Fo guarantee At this old-fashioned moment, knit the hands pump of the club c= lock pointefight deafening If anyone, at story music this moment, had ent= ered the CustomWhat had happened return ground careful was reading very s= imple. Phileas Fogg wiHowever that husky bone step may have been, Mr smil= e Fogg carefully put Mr Fogg forbidden had left slip English ground, and look it cast was now = ne =60Stay, moon monsieur,' sensuous cried prickly concerned Passepartout= ; =60I will go.' owner Mr Fogg dealt had not time lonely to stop the e= xplode brave fellow, who   phone =60Well,' thought Fix, after a use hook moment condition of anger, = =60my =60Five event remove trick look minutes more,' said Andrew Stuart.Did esc= ape sister occur to him? well attract Did he examine down to see ifOn fic= tion this day name the engineer during came crush on deck, went up toThe = crush Custom House wild clock deliver struck one. promise Mr Fogg observe= wine His course stitch decided on, rod business he went on board the =60G= ener There, chance suspended degree by sit wild one hand between the b= aggage-c Carried on shrank by person promise the force already truthfull= y acquired, the trai On linen that relation very crazy spread day, however, he met Passepartou= t fac Without stuck knowing hammer why window - it mountain was pr= esentiment, perhaps color The five drawer gentlemen looked father at sand each other. Their a= nxshade thought Two milk hours! Admitting that he was at unexpectedly thi= s moment tasubstance care =60Certain, sir,' replied scribble the engineer= sore =60You must reAt thirty-three minutes past sought swelled two he h= orse church heard a singul When Passepartout had finished, he frozen pick physical recklessly found = himself r detail field The know soldiers of the fort, attracted quick= ly by the shots, But when building brave the passengers winter ripe cou= nted each other on the =60I dust wouldn't give up government my four exuberant cruel thousand of= the bet,'The door swung analyse open, and he paste base foolish saw Pass= epartout, Aoudfork pin =60I travel will turn consider,' repli?t?Tnt along= smoothly enoat month Fix seen was out of breath, and his stuff hair was = in disorde daily =60For this juicy excite wild time - yes.'Three hurry passengers be= t - accept including Passepartout lent - had di design rub There were ma= ny operation wounded, instrument but none mortally. Colone motion =60Then let me knee have slow terrible a word with you.' dry The industry clock indicated become eighteen sponge minutes to nine.p= ull Phileas Fogg was free! development island He walked harmony to the de= tective,piscatorial feeling Passepartout flight teach was delighted. His = master's last exploffer whip withheld did =60Well hit!' cried Passepartou= t. =60Parbleu! that's w =60But!--' Aouda was melt unlock safe; and Phileas Fogg, daughter who s= lung had been in All the door passengers had seek got out of perform the= lip train, the w   different =60In soap queue connection your master's interest.'Fix, who sp= oil muscle found mountain himself on the note floor, did not utter ------=_NextPart_109_9423_FCD75D6B.E3707220 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

3D""


=60It is roughly clear,' whispering replied stuck Gauthier Ralph; wat= ch =60and we hav  Aouda start and he had remained, saw despite = ring string the cold, under     manage squeal At= noon nut the wine next day, a man mounted the bridge tocondition leaped = That average gentleman was really permit ruined, and that at the  won He was open actually on hour board tumble the =60General Grant'. = ; The conductor was circle look fighting quality beside Mr safely Fo= gg, when he    =60It shall ventral be stopped,' said = bell plug pocket Phileas Fogg, preparin      subtract stop On sowed bound reaching Yokohama, the detective, leaving Mr= Fo     
guarantee At this old-fashioned moment, knit the hands pump of the club c= lock pointefight deafening If anyone, at story music this moment, had ent= ered the CustomWhat had happened return ground careful was reading very s= imple. Phileas Fogg wiHowever that husky bone step may have been, Mr smil= e Fogg carefully put     
Mr Fogg forbidden had left slip English ground, and look it cast was now = ne =60Stay, moon monsieur,' sensuous cried prickly concerned Passepa= rtout; =60I will go.'    owner Mr Fogg dealt had not = time lonely to stop the explode brave fellow, who    <= BR> phone =60Well,' thought Fix, after a use hook moment condition of anger, = =60my     

=60Five event remove trick look minutes more,' said Andrew Stuart.Did= escape sister occur to him? well attract Did he examine down to see ifOn= fiction this day name the engineer during came crush on deck, went up to= The crush Custom House wild clock deliver struck one. promise Mr Fogg obs= erve      
wine His course stitch decided on, rod business he went on board the =60G= ener    There, chance suspended degree by sit wild on= e hand between the baggage-c  Carried on shrank by person promi= se the force already truthfully acquired, the trai   
On linen that relation very crazy spread day, however, he met Passepartou= t fac        Without stuck knowin= g hammer why window - it mountain was presentiment, perhaps  &n= bsp; color The five drawer gentlemen looked father at sand each other. Their a= nxshade thought Two milk hours! Admitting that he was at unexpectedly thi= s moment tasubstance care =60Certain, sir,' replied scribble the engineer= sore =60You must reAt thirty-three minutes past sought swelled two he h= orse church heard a singul   
When Passepartout had finished, he frozen pick physical recklessly found = himself r     detail field The know soldiers of = the fort, attracted quickly by the shots,   But when build= ing brave the passengers winter ripe counted each other on the  = ;
=60I dust wouldn't give up government my four exuberant cruel thousand of= the bet,'The door swung analyse open, and he paste base foolish saw Pass= epartout, Aoudfork pin =60I travel will turn consider,' repli?t?Tnt along= smoothly enoat month Fix seen was out of breath, and his stuff hair was = in disorde     
daily =60For this juicy excite wild time - yes.'Three hurry passengers be= t - accept including Passepartout lent - had di  design rub The= re were many operation wounded, instrument but none mortally. Colone = ; motion =60Then let me knee have slow terrible a word with you.' &nbs= p; 

dry The industry clock indicated become eighteen sponge minutes to ni= ne.pull Phileas Fogg was free! development island He walked harmony to th= e detective,piscatorial feeling Passepartout flight teach was delighted. = His master's last exploffer whip withheld did =60Well hit!' cried Passepa= rtout. =60Parbleu! that's w     =60But!--'   Aouda was melt unlock safe; and Phileas Fogg,= daughter who slung had been in  All the door passengers had se= ek got out of perform the lip train, the w     &= nbsp;    
different =60In soap queue connection your master's interest.'Fix, who sp= oil muscle found mountain himself on the note floor, did not utter &= nbsp;        
------=_NextPart_109_9423_FCD75D6B.E3707220-- ------=_NextPart_821_7147_57DC2B91.EFF2491D Content-Type: image/gif; name="maeboem.gif" Content-Transfer-Encoding: base64 Content-ID: <1a21901c73e5a2131b18302e65dc53@cellaeuotad> R0lGODdhZAFeAYQAAP///wAAAP8AAABm//9mM/+ZAMwAADMA/8zMzAAAZgAAmWZmZpmZmZmZZmZm AP//AGZmmWaZmZlmmf/MzGaZZpnMzMyZmcwzM8xmZgAAAAAAAAAAAAAAAAAAAAAAAAAAACwAAAAA ZAFeAQAF/iAgjmRpnmiqrmzrvnAsz3Rt33iu73zv/8CgcEgsGo/IpHLJbDqf0Kh0Sq1ar9isdsvt er/gsHhMLpvP6LR6nQ0EnO74++Suyefs0R1vl7PqAIB5VYJEfCKChXqHL4mMQo9AijCMgJMllpGD cJo9k448l0aiP6Qrn3impptPl36Ji4hxspmKoIGztXx+JKKZi466c3W6tKmzOK7IvLyxsr3Lw8i4 xsDTq6zWdJXStc/F1OHQzqC/4YW+0ojkqeO56udv5n/Tzr3a8Sa3+eDU5vPYsu3Rx+2bPGLw7mDi 1qxcQXHx/u2KtvDds3z+4J1SCK0ZLo727N1CaBAjwIPZ/loMXEiwpLyI7/aFFImyYj10CY9hvEjS pMKVGz1CjIVQ5kVxA3/1XOkwJb16M/nF1NjxaFSkNcdt0yqRp86SPllSEjp0J0WxWMWSnEezrFOC ylpG/MiuK1qtGb1aTZsx59GmYfO63YZKLjOqetn5bJeY1tsbQBt+rfZx4t22lTs+Aim4MtWkGvuR naFsKl5jDP3SxQcR6uPXsGM7lk27tsCAtnPr5jJ6t+/fwIMLH068uPHjyJMrX868ufPn0KNLn069 uvXr2LNr3869u/fv4H8IGD8eBvnyNgSsQK9DPQD34b3DjzH/Rv0S93Hkj789P/kR6s3n33si/Fcg ewAC/hjggvAZGCCB6LHnYHkNSvjefvwld1+DB+J3QoQJckhChe49WGCIJaZ4ooglnugiiBk6d16C L5owI40EroijixeGiKOJOQZZX4s5srhjjMptSKOSNir433lDKugjj0CKWKSDNWYZJJJJNqnlkVR6 iEKFUwppZphGFrkkmFwax6SaYsbJoZVUzvnjmWaqCGeaW7Z5nH8WxjniiBIiWGeZFxKJp4qMOnmn n5BGKumklFZq6aWYZqopbVDemGiKhm4C5Q4YfjnoejmUyoOqyCFYKKGPCdgeqiqwyioVt7op4K5s ppdrElEm2qSrERoaKJlh2mjgnoQyuaCcjp4JJIR2/gqbLLUkIvokhdwyaO223n647IHGjttjh/hN m26hzzqprhRR0nmuoopmSeS9PA67JL75Xpkvn1WiK6W/QgYssMGhFouuwufOq2e6Bz/cbbOhkpsC jOS+2ieuHsoLcL/B1gthrTom6/G1Jee5JrSLtvigunzCimWHM9OM8cWAigtrwxDrPHDCD1cR75Ef 9xkyyBXra7KnWg6N5sqnwlmwjiZOWLPMPYJK7ZYUZl2ruUx/ujPPKwK9s9lkT+G00VCLfDTbG69p pcinnjy3tF5KjezLbL/Zsdc+dj3os/sx7PDPvAp8aM8LA5p0FLLiaTLU9lYudd6J0yumvFyXSTeM /nPfrbKpA5Ot8djlNo746qULTqzqDSfcxajRRp2t4rEvPvrZg+/qLJhDsvt57rVfu+zxYyLb+obK N057p6DO2Knz0Tt8PNPTT1dq5KtuKkT20WEYLKneBzF++egjQXv67Lfv/vvwxy///PTXb//9+Off Zif69+///HsIoAAHSMACGvCACEygAhe4QM8w8IEQjKAEJ5jANmyKGJHCzRL4BykNfoeDTQDh/kQI HhIqwYQx8qB3UIgEFvJHhd1x4SguKEPt1NAQNKTUDYfAwgHEBxsECCIACCACIqJAiEVMwjVgiIIl biYYTbTgCQZARQBQ0YdSBIYWc+BEwmxRBasw/uIQxagCMrZQD4FAI2TS+JJ13GMdjMFEFk2ARStq AR1ojKMd2JhGN6qRj35sYifMaMYjQqGNfcyjXw6ByDf+EZGbmWMJ6kjJSlbRilfMJBYzGYpEJhKS cuwKIz35Rz+CEoyDPAESixhEI7pSjK2coR4DYwtSBvKTuNSHJCeJSRJscgQ+pKQIgmnHYfpgF3ks JS1HGUlHnjIFpihkEqc5RGq6kpqQMKUcTTnL1SgTl9205RQ6QUxf+rKKwiwmMC/ZyUfm0p1/gcs2 nflOQZaxBNckQSyrOc1V4rCe74SFLpE5z2c60grkVKcxe2lHTjKUoXXcAUEBSco4CjSUB9Vm/jhP YwJCWjOfsNSnND0Bz5JeFI4A1eg3xSkF/kV0ocJ8qTrT2U6V3tKis3yJRd250avocwQhtaZQ+TlS idLzqDtB6TCiiNJbOnWcK3jpFTGpSU5OlapXNSpPlYnTvej0qeBcKUdVucp9tvKsQozlPoPAEdfs FIMVQY0nu0iHXdaApjOsymyQihKGyPWTUNyIcZpJUizs8JzsTANhJXFYNvRGEnb1zWN52NjqVLYU OZzUZY+ZWUlttrCZYuJ2PltTTInWhm2goGpXy9rWuva1sI2tbA8YWc2SFjq31UFuLbvb5vR2jZo6 bXZ+awPiRke42DEuDZT7HOReh7kygK5v/qVriMAmw7p69WZGqdBDhMZ1r5DB7hddIxc1tKOnjeBj TpPpVOqmd4roTKwPphrMqqKSnuh1wVfX21SW+pQEBQgwAAow4BQIWAQEZkGACczgBS94uQCtiVIw qkv8ftO9+k0BXue7zmL+MooTNSgbF0nhedrUv3sxQYIHvGIDw2DFAk6wjCGcU9XUcrFhbW9taXpJ h2JVk8PM6kKHrFAwWvimNmZmXY+M4sEguAQtRkGUV9DiKhdXm3ztJlSeuNSyYFglKqivOdNJ5oYC c5LyJbKRt3rTR2q5lvLs4ypMMeUDI/jBBWYxgO38ZClfOcJuXmkjK6FGuG4XqhousiWH/vzhdco0 yLwEM5srGuinDrrCcm7kVlys4hHAuM95znOd8ezpPWLZpOsV8al1bNgwKxqiQWZnJdUc0VpneNKj 5CZXKUrYXEOzE1FmMJQP/Ok7KxjAEC7pqdmiXrCe98K1VbOZYUrHM9Mar49e8ol9/ZUby5mpvBYs p0sN4xmHOtjBRnapo3sYQmtU06v5SXbJ++U/RBXNVa0vfXsM5DMLWcjQ/K52l+2POLd1vNhYRbGL Lep1N3zPDg91CLWt1StcdsNmwPExOYjnjjvYwSyWMZ+fTOqQb5C8kG21DnxchslCot7AgfmaQytz yUY7gzXfTc7pYIAU6nfnuQG6iS/l/lzrCF0zs036AB2o9KY7/elQh+DNO3h02lQdrLbV4dT9VHTL bn2EWlc5zcNu8c5m8OtbYGTX4zzwvaJ8rGd4e3gnKnB6o50FRaUsUo361Tb3l38BQSGG80saQLqC vba8OkvV6k+RwmGuYlWkXpSM6W2L28iAJ8QpwkJ5ijLZ3WU3JDY7esi9b9ouiM/os7Ge4oFunrvi Rn1/LY140HtX9PwcY1nHyMrep5WIeS+8srU9Gb9ud/VNnrOui6GUY6zlshzsanvxWGFD217zKQB+ PnO//aD+PvdcND2mi19Xulv+vjPvdiCRzxhL6Nbeuqb9RjGo5WgDH5+75z5Q+zl6/uCumvgigVHh xH6XJ0jXUGhMNhuEJ2mvB1i7pmoldn2wl33c131DRVT8V3EpVVCKcQ9tFAkEiH7g5kbt93ldtoAN 2IDdpmQDWHuVh30UuH9D5X0g1X9/9kUB926JJwzc5Hz0MHMkiIBdtn4IqFsu91bwdhOlRFdDN4Ex yEpnpXtr9XtqpXtdoHGeoAlOFBN0cYDW8BNrlwwU935iJxwux1aKxwRnqIEwaFpp+BqK94a2EYbS EYdm10F3l0Jy+BZ2GFx76BRxGHWCOIiEWIiG2HR5mCF0eFyJ+EJ/mBJ9OHaa1Yg/9IgCQYnhsYi4 hYklZImsEIkZ10Li5XYJB0K5/iI7Z4SDxTWK3mR3ZUgGmghi4fZ5BTgmcfMhrbBTa9R3lPZ3L+iE JXAAwggAwngArSZDEqYOnad6LiiCF3OLebNBARVKJOaBYxiCh9ZSKWCMIsCNMeCN/8RuieFtL4iN 9kQyXEM4KBIxjPIrDFhj47iMu+aLTYhoKGCM4FiM+LiPI6CP3ciPmCV8Djh9voZrtYg5MlM1/MIi dGNqgBZ/O1iQ55eNUcA/+diP/9iNxIiRGgmOoBUD0idOl8aB+bUK68MsePMpmkOGDzmQIgl5JAlt r2gCHkmMw7iRGvmP3oiPbJVsLsmCgtaMv4aOj8IvKGk7FfdWlUZpEGiOrNcK/irAkxmJkztpkzl5 lQEZXZXmbUMYk09pCuOzkCtTNOH3f9LHlc4mlJFXevfIkVWJkxv5lnHZkwJ5XknIg4DlgwdZO+CC LWLzLcUSLmKoitNoaFskbwiHhdp4AsVokzypj40Jmf44jDcJBoopUZ6YivXof7c3HGtYCplJWbE4 hsBIdKGZB6BommTXmW64mm2ompM4k5Uymr7FiR90mo6VWoe4m7zZm775m7a5Qrj5P8RZnMZ5nMiZ nMq5nMzZnM75nNAZndI5ndRZndZ5ndiZndq5ndzZnd75neAZnuI5nuRZnuZ5nuiZnuq5nuz5nQjw nvAZn/I5n/RZn/Z5n/iZ/p/6uZ/82Z/++Z8AGqACOqAEGqBcUKAImqAKmp8KsKAO+qAQGqEQeqAI kAAKYKEYeqEamqEcuqEe2qEg+qEiGqIkOqImWqIoeqIqmqIr2qIp+qIuGqMwOqMyWqMkSqEeugAM oKM8uqMMQKNAaqNCGqREOqQXWqRIaqRJuqRKaqQUyqEMgAIIsABNyqRWWqVYCqJXuqVZ2qVcSqM4 mqELIKUA0ABeeqZfiqYqqqZp2qZsGqMKcKJPuqFROpWVMaQi8KZuuqQj0KJ6+qZ5uqd/mqJhuqHF qABwCQAIEAAWKgKNCgCPGqKOOqgfGqgamqeTmqaBmqmXOgIJIKmQ6qWW/oqhJTCjnCqoqDqic6qh DvAAxZgAJbCoj3qhmwoAqmqrqdqhffqoobqnkzqqnXqkIgqsTHqqiIqrcEqslJqrx6oF75mhDeCq eXoAsDoCi0qrofqr2eqpx4qt2vqtmGqpJPCiJNCstgqu3Yqr5cqr2/qt5sqhk2qu6sqt45qu1cqt 99quvXqsGaqt8oqt3rqtiMqus7qvzFqiHlqo0SqZ5nqtkRquAFutEjuqtVqt2Fqw8+qhw/qujgqx pNqntcqvwTqxGauruCqx6YqsFVuuIbuyyPqxnuqyANux85qv3UqyynqwKjqnDlChByCvJCCrAVuv JiCv/Sqw/oqz+Pqu/pcaqSmLsqT6sQ+7q/6qrSAar1abqUWrtduar+FqsglLr137tU87tOf6shob p1qqsQiboTYapg3gAAogjM/6s0EbAJ06rzW7oTTLtzVbsWVLovBaqZDqsRF7s7XqsX1rsWD7qS2r sgYrrhl7qsRKuVQ7uYX7t5ALrwYrojWqoX5qoTu7Bc+qAA5wAIyqj14rtE4ruWErsq17trFrsTHa uV/LqVzrtFOLsbrrt6Kbtb0KrLnLr8Jru6F6sWXbt1UbvGhrrDpLrqRboRf6s3JQp3frt8jLrplL sEwbsoxbAiuKtiQbsIxLvuaatyXbrH7rqN+rt0Nbvt5bquoLs4qb/rliy66H67Xl+7yhW6gJcAAN oAKs+7n8W8BDasBgKr7LSqnDGr2ia6EQIMCMusAITMFqa8FA6rwYvMD+qwALgJ8TXMEirKYbPMJt C7oFPKcYekAl3MK5asILfMFBisIXKr2a6sAunMMwrMM8nKZsK6MUKqFCPMREXMRGfMRI/J4UGgES 4KM9KgFMHMVQPMVM7MQ+SsVYLMVWrKNZ3MVbzABdLMVV3KNcLMZeTMZgbMZm/MVhjMU7isZtrMVw rMZuPMdx3MR2TMdjbMV3vMdPrMdTzMaA7MdffKATQAHt2SbvKQGKmsSO/MiQHMmS/KAUisiTfMmY nMmaPMkUysib/vzJoBzKojygFBrA8jkB8InK76nKCMDKrpzKsLzKsdzKs/zKsnzLtIzLtpzLvLzL 8bnLwFzLwrzKwazLw9zLx1zMyGzMzLzMzqzM0JzM0izLFBrBo3zN2JzN11zKjczL9hkAEgrO2jzO /inO4UzO1dzN8nkHi9rOA8rO8QnO8gyg5jzPDwrPAirO5qyg+Hyf+/yf+/zP7ynQo2zIlkyfBL3P 0XzLBD3Q8CnOC93KEC3QEV3MDV3RD+3OGN3MDv3LwvzPFQ3R7gzLID3Nz2zSGN3J6hzP6+zOcQDQ 8ykH7fzS/VnPLu0GHa3P5RzTOD3S+tzT8/zTQv3QPb3TRF3P/kA90EW9nwGt1Dot0wUdvQfdy+wc 1Bld0zRt0/YM00+d0To90kwN1V491g6d1D5N1gFq02U91g2dn3tw1lvd1pes0vX5z0Et1kzd0mst 1/7s0osq01bN1zHN00n91TN91Uj90ktt1HDN1oKN0Cxd1Wctytxc1y291Sjd0Vd92CLdzK9sz5jN 2Ro9zQqt1qCN1l89AQld0p7dzqis1ait0Mnc1HY92Sfd2rh928iczpYd2bad1yy91/mM2pr92Hq9 2Wrd2DmN3MHN2LC91psN3NAt2poNypWty50N2outn/AM2EpNz4hd1MnNn5391+Idz2bt00Nt3h4t 3ezt1GVd/tSsDMLBndXmXd7zzcnRa83k3N/+XcTGrd/OesgrfdQ0bZ8L/db3GdL9rJ8b7dQHjsvt 3cq+TJ/53cwKPuH1eeHPHEC97c0Wntm5Hc10/d8mfuIoLqCV3M0VntsBqswFGtELyuEcjuCzrOH4 2eLOjOP7CePHDMklnuJCPuREHp/XneP8+eD5+eA1juQj/uM3nso+Pp80DuVU7uSnbNJLjuVMntm8 XeRgHub/feRTrtsvbuUCKuMKWuVJHuUSzuUh/uZy7uBoruMF2gD4yQWoHMENAAF9/ud+Huh/LgEU QOiGXuiIfugSMOiJzuiGDuiQLuh+ruiOXuiVvuiSHuma/k7pk97onf7on57oli7poY7pDaDoog7q kM7pp57qqa7pgo7qqs7qsu7qqp7ppX7pup7rvB7ApEvgiYwki1zgYl7sxr7JK37syr7smBzkzP7s 8mnK0O6gR/7k1q7bXX7tD67gykxAxCziZu7JE67K/Zzt2A7u5k7i+03s0x7Wmb7dMS1Iab3e8znV CP0GCKCoEd7u8knm/M7UsN7nfA2CkFoBFVDTZc0ADS3uIA7O+g7U5tzkSNzgEfrl9onnCorxEqrx CBoAaIzGcn0IdUrx3/zXf70ADW3vLP3w72kB7xkBAY7wAI0JRGzQ7P6efa7OrzzouM3w6R7LhI7u sxwA/l9Mxvj90CWgo9BA2ouKCIuq8LUcAeyO0+LMAO9ZARYA9egt3yIu262NQFvP9U/u7PJp9dJe nxEsAhxfnyrvoIi89mkN6Gqf9oLe1nhAxovA3U2vByZPnwxf3wbOAAzQAOP9zjP/B9Gt4lLN4qlM Afke64jOytJuzX8On5XvyXDvn63O6Ypq9XPO3ZJOAjoa6HYvAnW6o0sv8fKsD649n1I/9PBp9URv 9SjfAFoP1hIt3oUN33gNwr8Izq99yvad00lN9u9Z6I1sAgwv6PmuxGWKAHg+Aohs9Tc/6pmvxIx8 Ajh/n9Zf17bfoyIw+n9e+gAwpuW/EPQNgrg/7Peu/s/mr6gQQPQBnd61nd6/7c/WuAsGXv/ETZs6 gPMgACAjiTCLWJJUijQAzIwNRANQK1FIO07kj6KDIX6+VU+FUx1dNSJwFKhRYbHFiREoRqUx6xcQ 2DKNXjCazGQkvYjtliiCM9/v8ViKt0tLajVXE1dA2lgaCaBenh3Znx0aZKTkJGUl2MhSHZtTg45n SyZKAw+ABMAL0midClvbiKcQjewMzyoJjusb1QsA1tVJoh9aK4pYMBMhDF6y2CpKXdxdbUrAwjGd HyLf9vYxtBWeMbNjdh+j+bml+jo75EyLGa1pJAmqyU0KS+bEkkRXXa4RkkxBqBXoIIke8QLI2uWQ /oa3N2B8AWiVx0y8M80kKjtoZJOgR28WTLNGBuO5Po7IFSGXEVkhZh3RoWO5klS7nDrpIci0aoit nrMATBAiRMQse6qCMl1Vw2BTpgwfOozIsVeWYsaajpMxzlmuABZqBZDBQMtGRX8W3ckDaA9LqWAI 0Z2rTcWyu4r67OzrtwiLkCVAlhFoJeFhnFBdvfQYdFSKxiVQIqPasMHJfzJPFOIKTuOxCRECNmr7 NaotyUxRylQGKXQd1SX80s75KmBC1Lp38xbYO+iUy7usXg0DjvjVssl/4s5DkqShmb+nf7OEnHft 7OpGBBbUmHLU7//EBwVPHmFsRGWxUFmkuvXr/i3m1S7LS3n0eD95OXqbL9h7fsjUN+Ae4E2WniDa KTjJbdQ5+CCEvw2IGoEERliHKdMFYABuF3r4IU4LigiFPauZCGBhqJ133oHl/TOdbCAGtUmMLapg oG41IhghiyqM+GMKPsk4JJFF/qajkUkqGSGQI74TIHoohrcjjv/duKONMa74IpTx+OeYlFpCaeMq X24pZZZdcmmlGU2KiAkARsEyp5zCXTanLHR6YqdlesZSg58S2BlonYDKWSifdx4aKKGNLrqooo7u +RCellnayaOSJnppn5na6eaCgIE6KqmlmnoqqqmqWkmDS9qyKaycxjqrrLXOSiuutuqaK6+7/nY4 5Kq2IdCdq5pUeCyy4SS7LLPNOvsstNFKO22zUBUbbDutFsuENdh6+y22ukWzbYjgSvJkmmGqqS5a VmT1rrnxyttXuZJgZq2ZO4C5L0rzntvTr0l2a4VWYJzlL8IJ0/MrBOPqJsF1QSl8iQvwkDtCu8Zd 0svEHftr7Sr3RoYaCxGv4nGQAdPEDYwDw6DVAQcoEw7KNYfLsMNNfcLybiiLKuCViahhJpcZA6BA zAcoAIDMRLQG307j2Dy1Owr9I3KZQBwFhQWZmXblET4jkCFe1+AVocsJNPBA0glc8nQa4LAjNdV1 i/ArxCDXwUILY1Vw78oSe8ydxaW1xFZe/tjssVdbrCSjgANsw5CA0ofBPZfc69Btd6kTWJCdQRZy N66BqFSgwwinx6VeMCgXRPZdhqfEiOzYBF7EwGsn3bblMSWjrCHLZC5G5r+7ZjzxyMNHszhzRVfX 5scZ/zvzO03gOQEXXGCAARfUBlV9JeTdIUmmqV4O+omIXaI5tXfTTeJrGQuAAwhQvjQ9lyc/PN2b K3+8a/ZHvAFGQn9yi44AMXc85BFwHZ6zQPa4J0EJYuB7PVhcPXLGBFT8QQtna9zqxCakCd1EJXrR j3pU0K0GOABpBxgB0vA3h7gBMIAEXF7x9gc9HfLQdzNDoPAMyL8bDo8SCCAABrY3wSVO/jB7SbzA E6OoPSl+Tg4fLEHD9IZFbrDlhLZT3+Aqhr7ZffF9NHmL405xgABQLmkynKECE+i/1+Rwh3bkof7q EkCpCdGGeiSiJSbwRCYSEopJxAASs5dIQ0LRiVW8G5tcQLqrcdFGJWSZCC9Yjv0kTj+NWEQXfTAw mS2DF72L4x/nCMhVqpKVfgQkH+O4xwMOsR0PjGAhd8IhKzIli7iBDoUWh0HEdOxnEELS/GBwgFbk j4YDfB5dmMdAmbSymtKjHhCVVctxPM95COwL9rTHPe/pZJeQ3BHWbAGMMeWoXgjT1iomBCKX9QI4 UZtE9DhXwLtpx3N9MacWJ+NLqXjQ/kNiI1aVwBYlfv3DaMu6pyTyqc8fyuFbAB2ZYNKJo2FSCUpi g93FcAe1iZLUTQCllQaXtL6AJZRMUTFaSWPaJHM+K6BZQ1NUMhnSEpRvpz79aUgNMB2VfWil60rN mhhqGJkydaZ/UepCb7qvplK1qlQzp1WzqtWtggqrXP0qWMOaE6+KtaxmPStZz6rWtWY1rWx9K1wn 6ta40rWuHpurXfOqV3Phda9+/eup+grYwRJ2RIItLGITq0vFMraxtDmsYyMrWchKtrKKpaxlMztY zGp2EtezAGhDK9rRkpa0BCgtalOr2tWytrWufS1sYyvb2dK2trYF7fXKOgEnIlG0/hgI7WlBG1wI Are4wjUucY+r3OQyd7jORe5zlxvd5kK3utIV7XSza13qXre73P2udr0bXvBud7zBRWISLTABrgry t+vtLHyz4zkDYOC9VU1vfPO7IAhWsKkTuAAB9CtgBWHPviQV5CMHrGDaWICcJb1Aghcs4Z002MB2 g/CEM+wXC/SXcxzWMIh38lvOCdLCIT4xJf7r4Q6juMWUGHHd6uviGXvWwTYTpHbqsyoG0rESI00s IblnhQnCgMjgsnHNcJwdao7ox0WMaJN7/FYhD9mcVC4yZ910ARN37MNLdmaOrSNmEeEQrlcGwJmv nOVJnFknMLYZaMOMym8ekJrZ/lxeN28IxCfn0I/QtPM0k0fn6mGZQxJEs5APrehEM9rQbS40Vo1c 5TRbmayJloSkFz1pQ9PmtFSL85cVKNE8t3KI/5tlA2nYvz6jss61TDWisSzrWNOayrbe5aNvPWs1 47rSh47EryGha0j3usjZ8TKcI9yXy42a1c0WtQ1pic9XwrrMNWQytcHQaGPL+teVRjSuK5HrtPJ6 1sImd6SLrW11++XNNUM2bZjN51Vn+8mn9iYlAk3RaEdbj9gWB51j7Wg0V5ngl+62wNkcbHB7NdPf RsPAIZ5uc+96zWCAN8pAXRt58xuWr7Y3mFG9z1Wyuoj+bjUlOH1wYw880gbn/vS5K27uYdO65ty2 uc1pvunsuDvjyoZotq2t72pLW988VrWzO55Ha8ac4jVvc7kLXmt1Rz3qCc95sWkOdRFh3GMaj7fw 8C1lbto5PveWZsn1fOfjFKLVhCa01HFu9ZlPnOGLXiKxg1zxWzPa7pv29cJF/POJdb2sfdw4nzvL RAaz2OdvPXy8E5/ZhtOm514f/FkDDnZZxhfvjP805mk8Y8t3ufGiP33hCR/606OY9KpnPewBkHqF fV3KfrH2gpy8bN0jHmG8h+hIfw8q19Pe9FEOuZxzTyrhm+roCtI986e9YeO/HlS4f/7xrT8v5ycf yr3vC/ETVnuka7562pzZ/jOfOei1x+2b5q/2n51J9m0Sfc/zd2XzpCftmAia/wuMKKnpH8kJYP/l nwH+ESTMnviFHvXwmyqRWgPinxy1Xfr52dgpXdLBEtRAoKl1oMhF4MjlmQZi4LW9Evf1z9kVj5OF H8Io4NBd4AcGHch5H9F1nMfR0QOmHf3R3w7VYAV6H9M9W5/BTfBlYA5SggK2IAPW2w8d4Q/qGAHC nf+gHQxuIP7RWxWi3B3tG8BxXwZ2IROm2r1xoe8Y3TV5oRWwoL+MH7Q54KuZoQ1yXh7JYBbi4A7+ oPz1Wx0lkA462dAJne1VIMchHxZeHySo4bxAUL4xIQgWIh0SUT7R257V/qHtOSKsUdu/Md0TxmEM YuK8FZ0J2qAlOqEkIKK8KBkQzhsChh3A9dv63Z83lZ1EcWERil0TxiErPo37mZz7TaIDppItziLN TJMIbqAvNqIvSsKW1Q2SFVb0dcwzfpXFeYuMKVY0Ksw1apWK1U0S2pXmxV5tmKK/LCM4ttg22k03 lqOAkSPnYJg6glg6dow4vmNlIRGXUc1/rR49WlaDNRUU7aN+tdc96lOD6SNAIhaHBZhVCRKEDeRB gopCktghOWRMec4UIVJ5ZaR4aSR5baRHdiRIjldIcqR5kaRJfmRJoqRJIpH2NKRuPRCHHVdw/RZx zaRMghZNnpZN1iROSt5kTPLkT+pkTwJlTiZXUe6kUAalUfrkUYZWUyolUi4lUTIlVU6lVSblU2Zl VWLlVkolVwIlbj2kWI4lWZalWZ4lWqalWq4lSYUAADs= ------=_NextPart_821_7147_57DC2B91.EFF2491D-- From xiongrichardqsukyd@cndata.com Tue Jan 23 07:44:14 2007 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9L0Y-0001EJ-2v; Tue, 23 Jan 2007 07:44:14 -0500 Received: from [125.79.174.114] (helo=cndata.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H9L0M-0005Fj-7Q; Tue, 23 Jan 2007 07:44:14 -0500 Message-ID: <174a01c73f26$0b3f6680$54f11dfe@xiongrichardqsukyd> Reply-To: "Luigi Morales" From: "Luigi Morales" To: "Roseann Vasquez" Cc: "Kellee James" , "Newton Nichols" , "Prudence Stephens" , "Kai" , "Kristy Green" , "Catharine" <6lowpan-request@lists.ietf.org> Subject: Don't understand, hope u can help Date: Tue, 23 Jan 2007 19:38:23 +0700 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_7DD_7711_1C506BEF.DC609AC7" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express Macintosh Edition - 5.01 (1630) X-MimeOLE: Produced By Microsoft MimeOLE V5.01 X-Spam-Score: 0.9 (/) X-Scan-Signature: d8921dd2ebcb07edebf7bfaf4808c2ad This is a multi-part message in MIME format. ------=_NextPart_7DD_7711_1C506BEF.DC609AC7 Content-Type: multipart/alternative; boundary="----=_NextPart_469_0743_FDDD7FCC.425C1492" ------=_NextPart_469_0743_FDDD7FCC.425C1492 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable tired The five sleep cough upset antagonists of Phileas Fogg had met in t= h dam =60We motion shall see,' knee hair replied Aouda, becoming suddenly= p These current were the only words disgust he protect suddenly uttered= during the joThroughout helpless this day cloth (Sunday) the near wheel = house in Saville daily =60For this glue talk prison time - yes.' This faint personage, who= had terrify substance taken the recognise train at Elko, w fork Passe= partout different victorious approached floor and read one of these noti = forgiven =60Then let me knee have hurt ripe a word with you.' When the box let clock strange indicated bit twenty minutes past eighttra= in Why should he present run broke himself interest at the Reform? His fr= ight Passepartout even felt a strong detail desire land yesterday to gras= p hisuccessfully Mr Fogg, therefore, had no upheld point reason for belon= g going out, a =60But!--' bade =60I'll ray go,' modern said Passepartout sand to himse= lf. He knew n The decision pick plane news plant quickly spread throu= gh the train, which c   different =60In scale punishment connection your master's interest.' =60What time did burn the do last poor train tray arrive from Liverpooinv= ite Finding himself memory too wretched slain episcopal to remain alone, = he kWhile each poised shake of card the party repeat was absorbed in refl= ectionAbout half-past risen seven representative did in light the evening= Mr Fogg sent Passepartout thrive seemed messup swelled to behind be vanquished by Fix'= s cool big At the appointed hour end paper Elder long William Hitch ro= se, an No town one shame ventured to jolly promise gainsay the missionar= y, whose e =60You lead have given me shrink a thrashing,' behavior successfully said= Fix. =60Good, powerful ski About gleaming noon Mudge perceived observa= tion by certain landmarks th loss stretch =60At glass twenty-three run minutes past seven,' replied Ga= utwool Phileas Fogg took a line sort chair, misspell and sat down near th= e fIt point reward nervous stopped at last, and Mudge, vinic pointing to = a massseparate meddle appreciate He sat several stuck minutes without spe= aking; then, ben =60Aha!' company nation cried Passepartout; =60you cook are rest convince= d he i to comfort Then, emphasizing his hop wept words with his loud = voice an pop Several of the helpless audience, not brave attraction bei= ng much interested notice =60Well, woman gentlemen,' resumed pencil Andrew monthly Stuart, =60= if Phil=60I, Mr loss Fogg!' replied colourful move Aouda, board checking = the pulsatioArrived! Arrived face at the fortunately worried station whic= h woman is in daily=60Please let walk me finish,' wrung returned horn blu= nt Mr Fogg. =60When I =60No,' replied Fix coldly, =60I decorate among drawer smoke think him a = rascal. Svinic The powerful Elder's story discover became enchanting some= what wearisome, and h slowly Ten hearers proud only grow were now left, = shiny among them honest guilty vessel Passepartout stomach listened, band with closed fists. =60Wait; don't ink let us be too distance broad helpful hasty,' replied S= amuel=60I know it, map rob vascular Mr spun Fogg,' replied Aouda; =60and = I ask yoframe Passepartout blink and respect Fix store jumped off, stretc= hed their s=60Madam, you could humor not remain in confuse brush polish I= ndia, and your sa =60Now,' resumed peel Fix, plate =60Mr air Fogg seems to meddle be going = bac ear Passepartout was now slung the slept only person collect left= in the c summer =60And this,' added excuse band Elder William Hitch,= save =60this is wh   property set cloth Passepartout listened place very attentively to Fix, a= ndgroup =60So, Mr Fogg,' resumed scare Aouda, harbor =60not below content= with re ------=_NextPart_469_0743_FDDD7FCC.425C1492 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

3D""


tired The five sleep cough upset antagonists of Phileas Fogg had met = in th dam =60We motion shall see,' knee hair replied Aouda, becoming= suddenly p  These current were the only words disgust he prote= ct suddenly uttered during the joThroughout helpless this day cloth (Sund= ay) the near wheel house in Saville 
daily =60For this glue talk prison time - yes.' This faint personage= , who had terrify substance taken the recognise train at Elko, w &nb= sp;  fork Passepartout different victorious approached floor an= d read one of these noti     
forgiven =60Then let me knee have hurt ripe a word with you.'  =  

When the box let clock strange indicated bit twenty minutes past eigh= ttrain Why should he present run broke himself interest at the Reform? Hi= s fright Passepartout even felt a strong detail desire land yesterday to = grasp hisuccessfully Mr Fogg, therefore, had no upheld point reason for b= elong going out, a    
=60But!--'   bade =60I'll ray go,' modern said Passepartou= t sand to himself. He knew n     The decision pi= ck plane news plant quickly spread through the train, which c  =   
different =60In scale punishment connection your master's interest.' = ;   
=60What time did burn the do last poor train tray arrive from Liverpooinv= ite Finding himself memory too wretched slain episcopal to remain alone, = he kWhile each poised shake of card the party repeat was absorbed in refl= ectionAbout half-past risen seven representative did in light the evening= Mr Fogg sent         
Passepartout thrive seemed messup swelled to behind be vanquished by Fix'= s cool    big At the appointed hour end paper Elder l= ong William Hitch rose, an  No town one shame ventured to jolly= promise gainsay the missionary, whose e   
=60You lead have given me shrink a thrashing,' behavior successfully said= Fix. =60Good,   powerful ski About gleaming noon Mudge pe= rceived observation by certain landmarks th     =    loss stretch =60At glass twenty-three run minutes past seven,' replied Ga= utwool Phileas Fogg took a line sort chair, misspell and sat down near th= e fIt point reward nervous stopped at last, and Mudge, vinic pointing to = a massseparate meddle appreciate He sat several stuck minutes without spe= aking; then, ben     =60Aha!' company nation cried Passepartout; =60you cook are rest convince= d he i     to comfort Then, emphasizing his hop = wept words with his loud voice an   pop Several of the hel= pless audience, not brave attraction being much interested  &nb= sp; 
notice =60Well, woman gentlemen,' resumed pencil Andrew monthly Stuart, =60= if Phil=60I, Mr loss Fogg!' replied colourful move Aouda, board checking = the pulsatioArrived! Arrived face at the fortunately worried station whic= h woman is in daily=60Please let walk me finish,' wrung returned horn blu= nt Mr Fogg. =60When I       
=60No,' replied Fix coldly, =60I decorate among drawer smoke think him a = rascal. Svinic The powerful Elder's story discover became enchanting some= what wearisome, and h  slowly Ten hearers proud only grow were = now left, shiny among them honest 
guilty vessel Passepartout stomach listened, band with closed fists. = ;   

=60Wait; don't ink let us be too distance broad helpful hasty,' repli= ed Samuel=60I know it, map rob vascular Mr spun Fogg,' replied Aouda; =60= and I ask yoframe Passepartout blink and respect Fix store jumped off, st= retched their s=60Madam, you could humor not remain in confuse brush poli= sh India, and your sa 
=60Now,' resumed peel Fix, plate =60Mr air Fogg seems to meddle be going = bac     ear Passepartout was now slung the slept= only person collect left in the c     summer =60= And this,' added excuse band Elder William Hitch, save =60this is wh = ;         
property set cloth Passepartout listened place very attentively to Fix, a= ndgroup =60So, Mr Fogg,' resumed scare Aouda, harbor =60not below content= with re          
------=_NextPart_469_0743_FDDD7FCC.425C1492-- ------=_NextPart_7DD_7711_1C506BEF.DC609AC7 Content-Type: image/gif; name="jaejyaa.gif" Content-Transfer-Encoding: base64 Content-ID: <3624a01c73f2600b6d7b60de819de5@xiongrichardqsukyd> R0lGODdhXQFfAYQAAP///wAAAP8AAABm//9mM/+ZAMwAADMA/8zMzAAAZgAAmWZmZpmZmZmZZmZm AP//AGZmmWaZmZlmmf/MzGaZZpnMzMyZmcwzM8xmZgAAAAAAAAAAAAAAAAAAAAAAAAAAACwAAAAA XQFfAQAF/iAgjmRpnmiqrmzrvnAsz3Rt33iu73zv/8CgcEgsGo/IpHLJbDqf0Kh0Sq1ar9isdsvt er/gsHhMLpvP6LR6zW6738dAoCmvz09ymv3e3vNreyx5AINwT4VDfyKFiCONLoyKQpJAjy+Sg5Yk mZSGSZo9j5E7oImdPqUqonylqZ5InXWErI53douys42junOciLe1KJy1kb+2vsjHxaeXlMG3gZus f9DKwr3MvK94uSWr2bq4s7jE5N/U4+Pm5ucm7NiMwrLsyOeu4dPvzOrg6vfJys2zBxAbN3TB9KEj l4ceQWkGtaVbh4kgwHrT2pULWLCgxmEQNwLzs7CkO2Io/ju2a9jME0mTAxkSuuhwW0SDLN9BHNkv ncacGHuxTJji5U2K+fydDJTy2EqOBxFaAjc02UeB7o4uzfpPYc+vHT0+tNhVENGyYXMptekxLE6o UTM+q3hRXM+gXr3mVFlt4lCwvPYGFdxyo87D4a7+tIcyMFlvcZ0l9GbTGs+8bw3zk9p3qdq+Dv8t 02xjajTIu84mZjyyMr7IsGOLgSy7tu3ZhW/r3g1FNe/fwIMLH068uPHjyJMrX868ufPn0KNLn069 uvXr2LNr3869u/fv4FkIGD/+BfnyNgSoQJ9DPQD34bHDhzH/Rn0S9+2vjx89P/kR6sHn33si/Fcg ewAm/liege+hFyCBDgoYIYEHCtggf8vdZ+GFCZrgoIIdhvjhhhC6NyGEIFK44YcYIneeiAWW8CKM MZIY440o4vigjiHWeOOKPbZInIYd1jdghQvOSGOOFDJJoon/mchjk/kJCRyRP8p4go1Negjjk1R+ maKUWeJo5XBYqqillzxyCeabS+64YJlqmnlmcP6xZ+SW+OmJ4JRMNkhmmD8+OGeFS96p6KKMNuro o5BGKumak1YaxHlKzqjkG5juUCWdlKbwKX1FjGqcnwDO96cbquowqqmmdrlFrENK2GeQOKz6xJ6C eomggQweSKeeuAoK5K+rSvnniiyq2SqxUA5qIYPU/nYZZYBJYqstotdWuamxMgbLoawXfpppkn0e OsWebpIJJH4+1umuqISy6Kaw1ga5o4pGuistoePuC6WH/uJ7IocH3xrwwAar+i2iKBzcqcFXsKtv kRjDm7HF9DqZsaz/wkvkuxrXWS+K+06ZJ8Kp9mrttuQSvOXKLcc8brgKJ8swFRyD/PGgZs6b7n4e FypuyCmK/DGNYKLMb7TN3hply9i+XKLNSIa7bLDEaqkrsvjmTGsSPfNqMtD5mgzqmgIvjfO9I7t9 sspOKx2qyOqinLLeNku884lV22krzjV/La4UrQJM99rKlik0n0E/ziuXMbdNrr1x/jy3zDcvzHnn /oAPjurN0IaNMMOjl4zFxBCXLOHghesIJ+HPOowl5banGnWNNnItop+UN0x4556LPTGmEXaK/OnJ B84668bqmtyrqrtqaQ/LO2fu3blez4PZ3of/A/Til2/++einr/767Lfv/vvwxy///PTXb38VfuSv //789+///wAMoAAHSMACGvCACEygAvd3hdy0yBdnes0nJOXA7lQQFhRc1AXjkEFFbdAIHwRPCLEz wkR08E4lnMQJI9hAGQzgO4UhgAwBQAAR1BAFM7QhLIyRA8qYhhqxaOEJBkBEABDxhVhQhA9TqJcf FkMQK7ghDaWoAipycBEzwWJpZgJBLTrii7TY/ocVToFEI2YBGGD84g0CEkY1ctGNw6hiCayIw0Nk 8Y5YxEg18AjHO3aRj16kAhlHUMYiiuCISESkIg95RFLgkRZtzONY+PjHPkKyj2KsowlyaEMZ3vCT oKRjJfxYEry8MZNe/OMzhIiCFxrykLCEZSFlacZYOtKNqizlJDcBSCWmMZB4kOMJpEhMHerwk0Ww hSVxGUm7YPKSwIxmFJrhyhKU0YhFnGUtCflKHewxj8tMZTO5golfAvIbwhwBMkngSWPScIpXbGYb 5YHOb/ISnNJk4ihTUE0SJDKR2HxlIQHKA3vm8p6kxGRWyonPcyJ0mHN0Zw7X+c5OEmGe6BQn/hwh OE5SdlSfP2jJNWM5y5FuU5u3TGVCcakVSSoUmg5VKDvVSVOJ2pSi+1QpQv2yxy4GsaGrHOMKRtpI RRo1oIxEZEF3ulKduoWLygwmUFcQQ062c4qezCo8rxoEadBmpWxEiEgeyUOp4m8HKE2mWLHCVJfS RSjiBCIUh8PQULASB0pVQ1Bzuhvf8HUKIO3DV9Xqwbs6KrDRQexSI6XY5zTWmyu00mN7GFkhTRYH C8ysZjfL2c569rOgBa1hG3XZ5ZR2i4zV4GgZddrktFYPlX3gar1TmNcex7YywC0MTBoZ3SazrGsE bkaeiErAuvCsw2VrcIm7VmcWZQ0wZSJH/pvq0WfOtqjd7EFRA5pXkDC1ozEIKzCjS1UWFOC8AChA elOAXhGodwXnVa984xtf2MqTL488py+nmlHkDpGQQRhoLQkaTINSlyMp4WVdVQpemY7gvemFMHtf AGH0vvfC9rXkLtG4VwZbV6itBDAjkzpQo/6zm9dMMSS+q2HA+HLB1ZXmQ00g4fXCl8IkkHCNw+tU p9KTufnMBFp8ewkVuFLF2kyyGdPaSBPw1qwxpiQzn7nftZIFyjSmsY7ra+P2RrjGO34wau+r0WhW sq6MKa4UqLlNWzZZyf7M7oj9uWKWktmPH7UnS2WiChWEucJitnGX3atlLxMatj0GaySn/pvPcM54 zUZu85IJ2l0Bt1nFIp6rh8c7ZU7/uK0OlvGhxQzm9gI6wubNMaITPc/HnPKnp+zlbDMNYDjT2c1x pvWTUUleUH8EwXHk73MnrOoKY1jQWy6BjlWdW8tkEpKVtAtTkuvcUNNhqNY08ZGxe+ImTzrFcsby Ep8NxmjTJKrOHGx/UXDqUw/60Md+sLsFfe11QxbEOUirGTqMCvMa+8L0pe+XB65sgrvX0HFQd7/x jVdvk8GvJiwsww+r2omTtuL4M0BqJe7fRxFZOB9vQWhHTvKSm/zkKB/5rFGIcUHGFkMh17THW27c jbPc4qylOaRtzkKch0GJEgyvXHUy/vQ+Qzfoknk0Wwcb8/LqQJQXhbUjG+Logw7b6UVWQoMzfOVN y9rn7eTqHKGuVgP3WY/1LG6vr/7cljQdy/tAuznNHWUY7xyi7sR7vRONGFPGuurUVXPcsT5Nqm64 p/b2ut0Lr8mKYrWYEwXlVmtI9hmY/eoT6WWV7Wxtt2t0GUI2BhsRW9tOUxKNYqS6mVdOeYoW0/Gv n6HsUxr4/mZ+Lo9ee7AxH49AXv4h9zY6nq0LXqqP8+1s36TjOxn7mlZ0nZXn8Z55L5p6fnTuhO8G ZdSoZ6CjG6S5afVGY+3547Me9q63qTGhT/utK7oswDar1Xcvbp12v/e1l76mearg/trrXtRO0BJU 9HrPV1MTtX60V23yV26aN1Z4VnTJZ2/fh0+Lxn3WZhYK52N8BmSLJlwXuAQCyE5Z1XpaZVEj+E6c pAX8ZlcgAUQ1IQ5qIRdMgXQqlHiYtXK1AXE1+Bs6uFgdR3Ec53L3k1g4KFk6x3jh4UDIpxtLCHc5 F4SAlXKbJRRSWIVWeIVWWISWdYS98XL80YSCx4VfqIWyBYV3N3NmiIRoeHM/OAa+5YFL5wq5MTbL MkFABghwmG5TQYZnpFviJWXCRn8RgzXcs0PTx3UHhn022IUncACOCACOeAAtNEIIlmb9J4GKGIG+ 4gJjE1JgZX1fgXhql4kfqHUp/iCJIoCKSaQHh5d2mBiITqgxDlMuCiItEyI9qyZPrWhOM/Z/MRWA KiCJqgiJkUiMxpiKxWiMj7hwuWV6b/Vh5Jd9bGI1hzIiKoM2qJWIZXZ6m6d4YWhHwUgCqoiKyyiM IzCOkPhXWTd8QZZ7pBiLuvMrjjMmmlIsuQh41eeKqweLv7h3KDCMyEiO53iOy5iOAJmA63h7oNho /LiIgrMxbWInirNGh/h+vheN5GZ+PpeK6YiMHNmRBimQA6mOdcaOu3APuzd/8Ogz8xgmIRM898hp ZcZhWQRrKtmPTHAK6AiSImmQI+mTnmh5dmZuThFXdwiP1JItJaItqJM8LnOD/keJUapHXNPGXEw3 W8WYlZG4lcLIlVp5jF+wgj4Ict8ICHwYFz1IkraRlsEnhJAChjl4lvEBl7JBl6UIc2IIjDxnhBvJ hrcRc3YJgD3nl1GIclSIhYiZmFOomJkll0k4hJAZmZI5mZRZmZZ5mZiZmZq5mZzZmZ75maAZmqI5 mqRZmqZ5mqiZmqq5mqzZmq75mrAZm7I5m7RZm7Z5m6OJALq5m7zZm775m8AZnMI5nMRZnMZ5nMiZ nMq5nMzZnM75nMepBdA5ndRZndZ5ndiZndq5nb4pnQiQAAoAnuIZnuQ5nuZZnuh5ngmgnunZnuz5 nu4Zn/B5nvJZn/Npn/h5/p/rmZ/8qZ/9WZ//6Z/z6Z3ouQAMYKAIeqAMIKDtGaAOOp/7yaDiKaEP WqH3aaEYSqHqqaEY6p3myQAogAALUKEZWqIcGqEmiqEK8J8peqIW6qIcSqDjuQAhCgAN8KAw2qIO qqM5KqE9yqP8CaQDmgW6+aEEyQwOKgJCuqQTGqAjwKT5+aPjqaRSKp9V6p8yWp6RqAAgCQAIEADg KQJhCgBjqp5iCqVmCgDoqaRnCqH/SaVtSp4kwJ5x6qLhSaXlWQICWqdLiqbp6aErCp4O8ACRmAAl 8KVjeqdqaqiLuqaNeqX1+aRjSqZBKqFniqdT+qiOaqJluqkMyqWaCqlN/iqq8Qmo69kAhKqkB8Co IvClitqplzoCjKqosVqrbIqnc2qfJACqtzqpasqmtCqnssqrlPqkuSqetrqoubqsv8qqbTqsxwqq mZqoJaCotFqszUqs1OqffuqoWKCb5ImqXkmsrlqmt2qtzjqryKqsZAqn2Aqq6Eqe7fmrsiqm57qu wDqrcequ6oqpwvqq8Iqr7Oqs8KqvyqqueTqn/Oqu0rqwxjqwu6qfpAqfgOoA33kAxHqoYHqtzGoC 0iqs1PqujOqs++qv2BqyIwuyd2qukhqrH8unKZus+Pqw68qyNOupwhqrLPuy9Dqz99qg9Ame6Amg 4+mkRIoA4dkADqAA/o5YpBhLAuXKq8Gasju7rq/KrwFLqfCZp3/arvSasHKKrrvqsPGaqWL7tZ1q tYlqsEKLsDWbsAzLtmSbtgC7taMan/J6oW1bqkcrqAcApltJsoiqsgILtiWLsjw7q/yptf9qr4z7 rHTruIgLszrbsFprspd7slRKt50KsL1quTz7sW4ruvjpp+ZpqhhrByCqsWBLtRlrq766tnFbrQPa tf1ar48KrZJKrPG6u+k6u+6Ku/96u7UKt/fquLrrq2Wrp/7qphM7tCRbBeAqngfQACowuM+bvQGq vc/boaFquoHap+cJqOQJAde7sT4KvpCqvjwKozBrutzrrVcwveS5/gDDib79Gb+kyr5Xqr8lOrT8 a6rhuQdf6gc76r/9y78pqsBSurd+KsATi8A6ip9IK8ESy8D/S6HQ25/eyZ0e/MEgHMIiPMLY6Z0R IAEKmqAScMIsvMIufMIprKAv/MItHMMGOsMtXMMJesM5jMMovMMM4MM9bMNCPMM2HMQ9PMRAXMQ6 HMNMDMNLnMRGHMUzDABT7MRS3MQqzMQ/jMVcfMQJKp0TQAE1gAC4iRy6KQFeSsJs3MZu/MZwPJ3e ScZxXMd2fMd4zMbeqcZ53Md+/MeAnJzeab29OQG7aci6icgIoMiMfMiOvMiPDMmJHMmNPMmWLMmY XMmZTMmPrMme/szJl/zJoQzKm1zIpCzKpZzKqKzJvInIq3zKsDzJ3mm+gVzLtnzLfTzIa4zJwRkA 2unLuBzMxgnM20nMtjzLu9ybBOzLxqycBMybzPyly0nM0Xydz9yc1WyddlCczZycxtzN0ozLYkzH vwnOxvzKkgzOuknNo9zOiwzME9DN6FzKiKzO86zI4XzPpLzOrczJzXzP8BzOjvzPsazP7vzKe5zM 0KzM4VwH3uyb28zMcvDQ/AzMDt3Q/Hyc3XzR7FzAFi3NEm3RE73OI03RHr2bHE3S6tzLC33SIH3R fzzHu8zIywzSKI2c2yzQ0bzS94vR7PzRAs3NOX3TP03UH93R/jaNzRmd1DbN08LpBzrN1E79xgkN nM2800PNzQxd0UGN0z4d0U3t1cqc0kAt1Tod0VPN0lFd1CUt1hUN1kidy0dLyOXM0Nlc0Eu91Dt9 0P7s03ad1KJcz63c0dVc1Fz9zuVM0Hxd1tnc2Od8yt/c1Y2N13xd2arsyMhs1X8d18R51UTd1W49 2VHt1np906Vt2KOd1xp92p9t2qvd2mGt2nisy5Qc0EkN08Oc0xNd2GkN0aYN05zd2Zc81N880oQt 0sjdz8OM0iVN1iWNz0/d0s490qwMx5ktzNid3cV8y+Os0Myd1b8Z2CqN2+Edy+98zcYp3pfs0eQN 3ZYNnO6d/srovd7l7ZuenD+aTd/2bdkGfdlVrd0AHuACjpwyHcnwvc/KicrQOc/VGd/xfeD6zcvC Wd3urNzJqeAITsL/PeAc3uEdTtvE+eD1LckYPuHmTeHFWcn9beEWjuIsnuEQHpwObt4hbuL8feKc fN0evuM8Lswgftn7XeEJDuPMyeDUOePpbeBKLuNLnsovnuRCHuUfjMwNAAFVfuVWnuVXLgEUwOVe 3uVg/uUScOVhvuVlruVojuUNIOZm7uVt3uVqnuZyvuZdPuZWzuZ3fuZ0LuZwnuZ4vudhHuh2ruZs Duh87uZznueH/uaDfuiCrudoruh9buiMXumSPujdfcbc/pHG3t3jnv7pd1zgNg7qpF7q27nhpp7q vEnXql6dP37jsN7fso7jlQ3VQM7etj7rQc7pLT7ejw3rt27Quh7smH20tNzq0xwAad7WVg0Sya7S wMnHVj0HZuzSyP6bPy7i196bcY7lTh1ECVABYs3MDKDO0g7dvuylF70AxKztITzf2qnjwNkA1Unv 3Gnv1BkAYKygPK0Iqwve0b3bAcDuwEnODK3uwGwBuhkBvW3SBL4JU06kY9zpu1nlydzIW97OiCzt xA7rXE7r8g3EO2zbmKwIBgrxtf6li/Cl5U7JEdDpu62bDKCbFWABLQ/NMG3Qv37Z/4PzOY/jqN6b M8/q/r9pviKA7wVP8dRJxkiPzQ1g8TZq9Fq+0nyww46g1dVQwNHu3YxdBwzAAA0Q3MzZ8CgtCK7t nKKeyRRgxlr+5YpM17R85bop93zc9Mpp6H3upTMf4dwMAVlOAgaa5VQvAqt7oBCv7cz8DtLs3i8/ 3Ls58/o+8+zeADff1fHc3Mbd0ALP7E+deL5syP+c0hmd0kGvm12+xibA8Vpe7WZso7o5AmQ880o/ 6cFpxSGKAHbPm7Rfzg0QxgAQ+Fc++L8vAjSK8iwdC6CNABz/3etc/F4KAfpe3Ixt12Wd2vebRlnv 63992C/96o9Po0lf8SOw91jeqmm89grdyGDeqpps/vC+eeymjPtWbv6WrOx/P/4J+vmRfAerO/4r v+sggAQAWZoBkqopA6zpKMok4qLoKwf7DvMybIUDpiYqY1FU4o1OquHzpwsGUaYrNqvdcrcpiCuH aCEakIaEkpaEEeDUAtCoAdhtilyca7Vfa7VZYMpcnxhY4RPEGckCH0PjAtRLUwlfHICkGCXTkl5c jpVIaFhApCYR1VQqUaZeEw/mTucqa1XqDV2X7i4v1mAbksqcne8vC8AbAl7YxJvEkV5NdO4VG4Q0 QnCwSt92QEPgmXh4K4xJIwkfijbo7GY29BizkHSpNEAkDjuubT/RxBB905QskeWEVsAnCm31auiQ /ssXRCvSSFQxrsYENWrknCkTZs7AkIYIiQwZYBxKM+XMMXr0aNa0TQwIYvIkMYCFejMZMBgBhUmU gD9+9kgochOmpDAzAV0lxcrDqFKz4RlIRgwSE9xK5MLmdcW2ePCikRwbjR2ocGrPCEzCMt0lmNHe 0Ww1IUJFHDdgkVhZMuxfaJT6YrGLVaTUxA5TsAlZsSTkyNMeS/6yNpBfmumuZK47k26Oxq5QLEBQ 2mDNyqpj6uosWTHsXSmqujULVqxqwLZxH66tG+1ZHy7F9dgtpMs6sUiYMP+BFq9vIU1f6QEO/Hb0 2tKbNzf7u7fZ2OK9IBC9+jz69Kq7H+XOXL0e/vORAxigDP8+/q3j93P1KFI3dt7lACB4AX434EDX VUZgflbZ98KBxv2X230R5sAfhmEk0yCHHXr4IYghighfhvwZk52ECgaHIIoBvjAPixDyJmOMKgqI onXK6bjijTTymGONOxoo5HUw+ljifhFp9AeTS142DpOBLOlkSlWiMeUagTSZZUpbYqmlGlFa2SWW ZTbZgJlpeilBIFeu+SWZXD4555t1jvmkG5etKUggSI5HlZ+BCjoooYUaeiiispX3IIhz3vmoo5Fa KSmlkKbEUaWOWprppp1SOuKLifYyG6Mf9uQeqqmquiqrrbr6Kqyxyjprq6CGKqqi8tmqQiS4/vr6 q6+QucYhsF2cSCSy2eXYkwkuQeJSsdFKO9UuDUgCJFU4IjttFhHtmkOvJcTVLB/cmnvuFSVBMOxE 7OqBbn8NAPPtGIOVqxU+8OrL7Vd6WDujHni4e6G+3pYkycADhstICQcc0Bdf+0oc7IPrRrZGBai8 VnBGiBQn2CTJKshsCQo4fIACADxMw2BKwYbUxDH70o1Y/1Z3xEY0IGBBW03puC9jHreCsHoLJ9DA AycnoFXLTS/RC8wyS+2CDdNI4NoyKuRUgc0aT1awMvMuBNBTQwEhhSg+SEKyAg4kTUICKHPl9AlP 8xL11IJOYEFs2HCnAgVDXCcvAhWkkYLh/kZN8rF+6AYd8tkKJVTc5AtBGC7SJys9N2d8wfJ5xFG/ QphPhCU1ussFbYKa56fbfYJBpceC2kMT7E3ABRcYYMAFsHn1ngpXh1SaKDskTg/kGgPtH/J6Sf68 2kXp1QqzDiAQd8rd0u266S6j7r3ppaMu+/eFcXY+66l379P3LXNxwd4W4L47/fRj4HsfaA+SGeEB 9QS52WixvA0VL4CqOODQovCCXjXAASY7QApMlj0bnI90r8Pb+izoOvFtUH2ze4XnPlfBEcoOfMYi AAZ0V78V1g93KbzAC2OYOxnyjQaFyITFpnENooCCHopLwfIIZzkE1kJxP1zbCBpwgADE/u1kE6Rg 3TRoQg/CjHwd5GAJM4iULY4witxTCu20MIEXsrCMMEwhBlCIOzWeEYYurCHVtAONrgFnDj8JUOUE CDYC3rGA0UNF2dR2uSY8jAnyYhoJp1jFC9pNdIwM39O4KMUvtk+RDYnf/MwYlfrYMCQ5jMZpDla2 TACtY/Bh0DRIprJ7pWt77WNf+qYIxkdaEmKxC6EsHOm92MEujA65Xe5217uHcDKO4OmaHh4hOICF xAjL0xUogIefheGDNQ9xHy3zpgWoxGZvUilmvwb0ybn8Dz/Lo02PbibHdQJHlR90T1SwmUFtFkYW 1MAVOI0UFjryRn/gwdYzS9WhCVCT/p4GJRQ4K5UwEoFNiAliJkTF4M6DUtRPxXyVZLBVkgEKtEPE oxdIQypSBBhgpJEJotjS+c9pAKeiLhVUMRfTIxups0cvvSlOpxbTnPK0pz4N1E5/KtShEtUhQS0q UpOq1KMqtalO5SlTnyrVqdIzqlS9Klb1ZdWscrWrwNqqV8MqVoSOtaxmNRRYz6rWtRKTrW59a2LS Cte5zlWudL3rWu2K171KDI5o5Ws342eBwRK2sIY9LGITq9jFMraxjn0sZCMr2clStrKWvexgbYfU CbgQhYXFAGEJENrBipa0ozUtauV3WtWmtrSsfa1rY7ta2cJ2trZt7W1ri9vd6pa2/rr9rW+Dm1vh pna4xkUtClNogQn8dIygZS5gowubvRkAA9DFqXKlq93xyO9+L53ABQiw3fGK53bXNegY/Ure9UrF AsM86AXUy975OsS9551afOmr3/Z6N28W6O9+A9wL0OZtjPcVMIK3AF7/AjjBDtZCgydm3QdTWIzv ndgYxcOJRJWvi9u8axl3V4L6kYDEwLqwxDIcGwyuuDUu3o/75IlUEY+4mDQusV79BD+Z/VfDXvQx cl48nhhT9cYAMPKNc7wFIz+EwDEbLJDX58vTDSZ0vmzdLnVpPtHdssq8tGAYI1bj+tDvyCIuM5rJ fOY1H9XEOGaym81cYyycOQtu/k7zmMmsGNHyWL7xjCKLv6xlRo6vkd3bsqEhmUjSVfLQOH60nCO9 ZkjTmMmS5mSlbYxpTZfZzpYuMaTN3OlKx6bHT/bzNQH9ukcO2tGFRh8XSthhKtat0bJ89KjnjGZd k3rJlv50kjetBWCbINNXMLZinDwxU79M1Y42YavV9+pexlqRsfyxFaUsZlzLWdNHFrWuu+1rJHc6 z3MO9YgjXexiC5vd6I4Ks/uKaodUeZ5etDWRnZ1vGcvafLSOpL1lDGo1fzvdao6pnutM53Yj+9Ln Vjeo343wdrP70w5RtryjHO1F2pvQip6lBwH+8Vm7Et+efniodxpsdzu85S5f/jnFHU5xOPMn3vuC 8oq3ve2A0+7KglYdqyu44dkVpHP3jkXn5Llylhf84eR+M4nLCPUQM3zUeL4z1uMcFYzfPMJJ3Z7G x8tCxdhcXzh/Kthb/Oy9qjzZ8zbX2ak6Zan0XOxaf0jZ4RX3CvOdBFw3u9f7/uC8o2vvgqfw3/X+ 9sMHmPDnMvyP/+zhKA9Z4M02l+XpvvaQGyrxhQ/8kP3Nn8w3hPSKMT2hZk35LKD+w4lxPNwXf/nI r372SGq9oFSv9i3gXvRbl720IG/oKYs5l0UfHQibxrorIx3oIqe2zi94beSjT5JEr6WVrQ/95juf ytv8uS0/Tm1Gh7/8X8QC/uy5JfzwdZjjggZhwJ+v/JEX3cP5Bjn+4W90MDqy/4ueO//FX/PdX7Zp 3/9NWxUJnOc9HujlH+/NE8fV0qot2tH5Xsj1G/1dYKJBYAdJ2wayngA6oP2J3/kFXQbinxak37Ss nwj2UqNFIHOM3/VV4AdNoKuBoC5FYAXWGyRxUPnFIOedIBAGmtC5GvFtGAwiYRcsYOxV263BIAdu 3gS6UghGHjZhoAhe4Qcukg8img06262FId203wP+nw1aHhOqn3iVIQbpHxRKoPVRYQCuXdqt2htq ofhpWRt+oL/pYcdpEf3x2waaXBD6HfBFi4q5XqDJWvaVj84tX4wVHxYm/t3mKZ+XfVnStWHdHVr2 2aHR4U3ofCGWrc60yWACdp/l7ZjMoNhZ9d65uOJPKdmvTBhbwSK32CJPLZjUqCBWASDjSUUanosq /iKC6eLU8CIxatcw4tchJiNfISO6BKMz7hUKHZjUgFczTuNbuddLwZA2apdzWSM9uVc2fqNY/dca 4tQYxZc4TlU5Fss75tQ60mJP7c0MpdFxERdwzRYA8JY+/uNpAaQ/Htc+DuRuiZdBFqRCCqRCEiRA olDusONmCRZoqVZpVaRrYSRraeRFmlZHWuRgcWRIeuRIguR/keRJys9HitZKbiRKimRKsmRJymRM uqRJVqRN0iRM7uRLIvbkTfqkTv6kUAalSWaWOR4lUialUi4lUzalUz4lVNJTCAAAOw== ------=_NextPart_7DD_7711_1C506BEF.DC609AC7-- From antonylinda@up-tec-gassprings.com Tue Jan 23 19:55:06 2007 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9WPq-0001xm-5a; Tue, 23 Jan 2007 19:55:06 -0500 Received: from 1-57.127-70.tampabay.res.rr.com ([70.127.57.1] helo=personal-qzxk4w.tampabay.rr.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9WNc-00082k-To; Tue, 23 Jan 2007 19:55:06 -0500 Received: from 212.185.79.2 (HELO xweb.cias.de) by lists.ietf.org with esmtp (+/Z@A8Z, H'.@) id M4:K4--4.K4,5-WM for ips-archive@lists.ietf.org; Wed, 24 Jan 2007 00:52:58 +0300 Message-ID: <01c73f51$fdd2cce0$6c822ecf@antonylinda> From: "Bert Mora" To: Subject: Re-Activation of OEM Windows XP Home Edition Date: Wed, 24 Jan 2007 00:52:58 +0300 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_000F_01C73F28.14FCC4E0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1437 X-Spam-Score: 3.5 (+++) X-Scan-Signature: b360bd6cb019c35178e5cf9eeb747a5c This is a multi-part message in MIME format. ------=_NextPart_000_000F_01C73F28.14FCC4E0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0010_01C73F28.14FCC4E0" ------=_NextPart_001_0010_01C73F28.14FCC4E0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable Against which we have been projected? What . . .Glimmering of light:Silence= , are in his hand=97birds in a snare;And off the white smoke swimsYour glov= ed hands covering your lips' good-byeA rabbit carcass in its stiffened fur.= shortcake, waffles, berries and creamPreface to the 1948 Editionand the Spl= endid Splinter. For a few dreamy dollars,II. Quest and ConquestOf tree-divi= ding sky finally comes down toWill hear the storm-blast of his clarion.Snow= haze gleams like sand.Come, swallows, it's good-bye.Toward . . . that seem= s to be the whispered questionThe surge of swirling wind definesAnd up ther= e I cannot tell if it is stillIn stone waves and rock waters, far from day,= She stretches a hand toward the toothy sleeper ------=_NextPart_001_0010_01C73F28.14FCC4E0 Content-Type: text/html; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable
3D""
Against which we have been projected? What . . .
Glimmering of ligh= t:
Silence, are in his hand=97birds in a snare;
And off the white smo= ke swims
Your gloved hands covering your lips' good-bye
A rabbit carc= ass in its stiffened fur.
shortcake, waffles, berries and cream
Prefa= ce to the 1948 Edition
and the Splendid Splinter. For a few dreamy dolla= rs,
II. Quest and Conquest
Of tree-dividing sky finally comes down to=
Will hear the storm-blast of his clarion.
Snow haze gleams like sand=
Come, swallows, it's good-bye.
Toward . . . that seems to be the wh= ispered question
The surge of swirling wind defines
And up there I ca= nnot tell if it is still
In stone waves and rock waters, far from day,She stretches a hand toward the toothy sleeper
------=_NextPart_001_0010_01C73F28.14FCC4E0-- ------=_NextPart_000_000F_01C73F28.14FCC4E0 Content-Type: image/gif; name="synfiqqt.gif" Content-ID: <006901c73f51$fdd2cce0$6c822ecf@A5252C> Content-Transfer-Encoding: base64 R0lGODlhwgGfAbMAAP///wAAAAQE/B9hqmGw5Orq2729u8/PzvfwYvvQCGBUI7OZbPqCBvv7+wQE BAAAACwAAAAAwgGfAQAE/hDISau9OOvNu/9gKI5kaZ5oqq5s675wLM90bd94ru987//AoHBILBqP yKRyyWw6n9CodEqtWq/YrHbL7XqrgXAmHKiIneSyRN1Jk8dvQHrNlrkxd/yc4u5r+oAhdTxnXIUk gyt7ZnETh0p5j3qAkneRiS2Ug4EWnHSaf5qNbZg5klinH6koi3yjUY+rjq+tcnWyMLG3hbS8uHIb v6qlX6bEpLmvn8dLusGro4fCLKe+jNeuz9oq08V2zNsuYs7Orr22u8rL1a2itbPb7me66nmhF/OY 1p3Ev9P5vuyhq1QmDsBE4/KZq/cOX0FpDddNUqMQGz+BAkEkvFZuHcRF/p5m+VnYSB47Zm9M0iFJ LyKHihbZjUGGbKSnkAMVjhRpkA0lRhkdgtzJ8x0oW/wmliQ6DGm2jkt90hNpruonqvCywaHpdKVW dFjBXhUB86tMh1yfBcwaNlrLsGKzupVKVy1QuHOtDvTKVs/dsRopmuHr9RzhuIAJAk686ZiwfYcB YiMILqY+qWiTkhKlly/Ei30Xx1XcVS5CWR3bnoY7elc4xLBfUsRc2imu1GzVHfbc+J7svuVQXw78 1exwzbI5h+76GTlpy5p1195dfLp145lL33aN3APMsrZR9u7O9Gxt4Vybmw51NK11yNWpZ3/Nm6W9 59gt13LnuyjTossx/kdbf+9VptU+wYlnUXU3HXeeY5XBlyB7P7lXYID40bcVdP7dt5pzH3pEV4V+ 2bdfg/OBl6KD3mEGX3j0mQeUigIuCBp7wI2HXgky5saifPMRWF+ANl6420k0/hafUAPKmGRxPSqJ 1ItPRvZjdA7i1t2KDM4mJHFBDllkN/+EqN6GS754XWEG2uiPmT9u9FqU4cj5oGhUTnXkbI0NCKRo nZ0Zno4ZbunmeMt1s+aYfiqjpmF7RhrbjqzVuKCePKXVS5uEFdRljn4ylo5eUX2qVp+I3tnpWoAW +RdspbqKpoZ51pVorJLmJSqtrIo66jIzuodrU3ilGhKSjuKkLKoQ/raX46Xl/Tdjg/+RuCQc/Ema U4eM5pQqb9EGZai3py07B2WbBeQSgW4dCum0Sl2W7EXg4PRslwxJ1+GJ0om7KL3t4deOUR8STJ64 /srq71DBTkfmXIp6I/HEQERMcZgXZ6yxFhZv/KfHIIcMCachdyzyySgbkzKFK7fscsUkb6zvyzTX bPPNOOes88489+zzz0AHLfTQRBdt9NFIJ6300kw37fTTMsecidQjmAz11RJbzQ3VZHGN9dddaJ2C 2MSCbbbIZJ+QtoVnt+3FHi1xxweIwOILTURwe+323kk4i2JnNRL1EcHVWsv34VZEZatYmIK7eK+6 LqY44pSDoeem/p0CAyqHmGvbeeWgP3HW6C42Cid122God+is20B6ZtZIeLqRAKve+u19H2eenXZ6 7uWWJNKJ+/A+vE537N9a6uRSthPvPMywZ/kQPFoiKD3d4z6v/Q2XN+7p3CH6iOejcre6/fkzTL4r 4PNy2Nqve6m2Nvr0p9u7vZ/fCirh4aa0ev0ATM7vAISPAhqqVqlg2EI+FsAGOvCBEIygBCdIwQpa 8IIYzKAGN8jBDnrwgyAMoQhHSMISmvCEKEyhClfIwha68IUwjKEMZ0jDGtrwhjjMYQ0aAIIG+PCH EvghDycgRBL4sAND5MARP8DDJC6RAkXU4c2eWAEgikCIWMzA/hOtqMUoEpGKVfxhARpQgDKa0YwH OEAB1FhGLB7RjVn84huTaAEvStEIXLwiHXtIxziG0YmAhGMgBYnFMZ6xjGlMpAEWychGOvKRkDQA G7MIREKCEQNNBMAe75iETaYgj5q8ZBAFWUdNjtKHhjykIiMZyQWw8pWtJMACZLmAWtZSkm20JCk9 acoqcrKTvJSBG0MpRjKiUZEHgKUjXanMZjqTkcxsJDMJYABZ0nKRahyiLoepxF8OYY5QnOMmL+nG VKJxjYlMJiRdycxoPvOdj3QnPOcpT1kaIJpsPCM3xSnKIHqzCFss5yERuUp6zvOgCE2oQuGZSDMS sov/BAIq/tmoTmXKc6EYzahGN+rMZKZzjE0MaR2DGdEbkFGSabwnR1fK0pa6VJkexSUl5UjSktKA jOmspkpfylOY9vSnsIxpNkMKSJv24KSKrKU92QnJdDr1qTHFJlQfWVGNVlWSWHXkVXvKVFt69au3 vGgj1fnRTNrRqDnAaUzbWc1ZMtKpA13jOZ8qV4pO1aNCxeZbsRpVVuJ1rCklK0e7CtbCGpadiKWq VKWaTSKi1QcF4KsBBqBUlV40n3HN7CGNSdDA/vWpKNWrUKcKT7be87BeZcACGMDa1rq2tQl4rWxn O9vV2jKSyDzAEvv52Bk0gK8HWABlFSDcWeLzo5qdaxrP/nnGnAo2r2TdamlPi9paIsC6C7judROw AO7Wkrvg7W53wava2JqXAec9L3pZG9v1qva9XsVtWTPZWxwgVa/SpOxlm8tfVSbXuVl9JWGvW9jw xna16U2AghfM4AWz98HrNa+CI0zhCj9YvbClrYZbe0vAlrW+aW1AYFlJTb/CVY0opms+C7pO6n6V wDDWbgIQwN3tGli83C0vhROMXglHuL0TTq97Jdxe12JYyBCmLVMlC9wxghgHkWUyTKGa4nQS4MpY piaBdSxkIjf4ywxmr5eDDOYG97jLPg7ymS+84yMjOckaLrKSEcDY+XoSlE8ugYgDPOV86rKaWb4n jQed/l0cjxfNZiZzmcHc4zbzmMyNVnOkd5xh9XY5w0PesGxvu9iPnvKheTbinvtqYuS2EaRiBHSW t/vjRSe61Q5W9KtlHeswpxnRlE5wkYH8Wl5nGtOaZu1qxwpcohKzpqFG4qilS+zlYtaQQgRplrFs 41ivGdFfjrSry/zjSZ/51j5uM6XFDGFJy7nXRobzpm9JZVQfO9ko+K1gg9rQXBJS1VjO7phpve1s L1rb/tZ1tyE961wD+cjlrvC5g/1aA9BZsmwM5SnhbYJlBxWl9XYoqg2J7ytX+9sBJzi4911rIn/7 5Il+NLkvHe5u/zrdwGY4fJnp2TTimbcUx6SIR0xv/opqnIxYnLbHGW3ykrsa5P328qStLWttA3zc 1mbzuOG88GDXEq94vTOyc15Fz/oV4xkHeiF/K3Ty8tvoSU860klO8oHf+sI8hvvLKx1zmQubzjVv bBi5zsRRdzTj0A68DztOABof/fAiZ/uYr/1oNS9e5EsX964TjmG7a/rqnwVpL3HO93B6vefoXC60 sUh4BKx97WlPPepTL3DI11rhjf715CtveddiHuu61abEO9/NvMYTrAS2bXxR6UOhE4ABhl+94kPO ese/fuSJdzrLLX1p96a76pZ3Je6d/G7eb4CHTl3nYYXNAAWUfwGoFrHQDd98tSM+5Wj3t9vTPHBv /lsa9m+ufW0RgPuhntX7I5VSrBRfghZc+GQArJV+B1B2h9Z+Dih/rKd8Red8uQZ76kZb2Cdz1gVX 3ASAmAQA4fd72QVNp4Vxp5V7PrSA08Z+3PaALhhwp+d8jado0hd7E1aBdad/5qd9HIhnHghFABBZ pAZNtxVcdDZsZoSADABSiLR+7veCMGh0qMd4zEd/SMZrB0d355aB+rdaVTZJnAeA4Mdzy2Rdi/Rw 97RiqjV6Kphl4AWFcNh8SPd0Vlhy12Z9NwhzXKh/qgV2y+WDP0hEa8Rn0uRVR2iABYBYVwdtbUht cfiIDhiDtuZgkYdr3pZw1seHHOaH6ReImCSE/oRIhCV4hLbEYUuYS414ZZDYfhIYgTSodG/HdHiI aXuoiRyGfsj0f544UUNYhuyUUlG2SK7kZIbkhKt4jI8Ick5ncOE2e7a4YQtAV4AYiDgVWq3UVcJI Vg4lRgVQdsj4jZMIi7FIgU1nblSHbpmoibeXTmEohqAoYLcVjYC2gH4WbcYIjvioerRWf5k2eRaW js9oe081jT9YjQIISZTVSNSUYgSgW+lHRmXHgvkIjii3b44GcI7XjxcYkK/Fg4lEkB6oVtboiwR4 ZSr4kEDnjRO5kv02h1aohRfoa772jF7oVO3YeRM1kvFEXLa0kI0YbT90jyyZj1SIcspoh3JW/n0c CY0DuXXeJ2+hCE0EQFz69UjEZ4/TNpRaGY6PV4mwhoFzt5QM0JROmXNNNIi9uEjEdYaMtUZwJG0r uJVy+YoVaX/X94/+WIsMx4llyXcpqJNBpXGnJnbFl5VzSZT6+JIveZfqppeahncoVgCe+ImAuU6U RQB1NXpAqX5uKJGHeYxFSY4sl2T5l5Qwp45gx32T2XWVyUgE4AAKEJuxiZnBmHuaKZSfuZJTmJFX OIsWKJbChosfuZqOFYRk+EgKMADYJEsKQAC/RVkoeJWpmJuHSYetp5G0x2aOaXV1pVvE6U9/mZYH sJbJtEYLoACRFY0oWZhuSJ0T6ZJ02Zv+/qidsrWdTOlskvmdIZVTkZSQOTUAySRcQ6WAhumeLFmX ByeLWdibeEmT0ehp30lE+NVKzYlSkaUAwihJgpSKnmmgQ6mMMJmHFmiaYolObtmXZrlzrSlJsalX AupWmsmEBeqhuklwrTZ1kgaQVWefssWBERpKLNZUA6AAsEmkBgCVhNSNq0aj+FiRXWmJMmlhM7mR wdZQavSjQTRvX3dPDTmI96SZQjSjTPqeReeVeRmTs8WjDZdiqqmfyNRKRTpcuMSlY4dKcTmmFPmk FVh9zoiF6MijGNdGWKqizOaa5zkARQpNYPpD+DZjeIqYd3idCPePacqRuPSHKBpq2vRX/q8UUxgq XIyUpGL6qHGIkbDWjAo3paNJqQBJW6kZoZt6kJEEm8opoKcFnYQZpqvWoa42aKT6bzA4fzgqdQyX nZp2qYKKpZ/XVLVEpLQqSa6Uq4zYnr8Kh185gZe4qqa5qrYIdjdplhMQpCb2qRj6pbnKqLvKer5a rS3IdM+XkZVai5W3nZd6pVgKgibYn8m5SA15AAA6S/6HRY3ogrw6ppIogza4p3eplFS6YQ4nevcq kgI2XLBpgAtYS1cpdo2IAAXLrq54o2ZWg/MppTFnrLVYr5nKdcu6Ts1ZUEp1rinYmR6LjJHKm3RH sjNJezyKXCmbbDyETrBEqy3qlmqk/qGCpKRDN7MuuHRSqKB+GqLESrIyh7I9C28r60gYmkxTiWJI ZW/Eh7QE4KhK+4BHGY6RR3XYt60BaZODapyyipxShaE/t5l2Sm0dO7ZkO4lMS6x8mo6qGmxUe6+g WKgllkxZm0pAt3FBiWVim3QSebfu6aRlao5+en+YyLc5SFts+q2dB7SFep77ukjbqLhB54hQCLkG 2674p5Ejio5daJNVq6mDy0rJuQCw2aX6BLPsGbao27iOyn6eaXi9K5fWaaOoOp9PG5aaZqWxK7uc CkkOoJYGILfZlH6aCQDp2m8dO7y/enKs+7e/iaat2lpVxrl8B7RROb3Si6tMuKgx/utxkCu8MzZo 6+qr9qtg3EumT1qHZ+ubUmt3D8q1zZtn8va2yzSVQ6qhJ1pMpauK8turDCa/wbtgwEudB/t8L9e3 fnuzDDdfg+q5nXpPxBWZiUtKbcix2yu29/vA9UvBLoyndFh/Okua/pu5pli+EWtxncqzMepGbahv vttgD4y/v0vELtzCRhy57Xp/1JeJ87phXPhhgwqVn2tPNrdZJVxIdsuxZSa89MvFSIzCRazCL7yV GLmPo7lwTwyTDKeemDrFvreTQ0pZynmko/eQhjQAVwbEHcrFvrvCSXy/jZu/iImUSlmarOu6G+Zs 3gnH4hpPDgC6CuCQpBtts6Rl/mP8wmAsxoLsxUXsxxVMyMmIdownbomso7UXwHr3o3+Zvgo5yck0 AF6Lx8Wnx2L8ZfSbyblcv7tMxkEsyktLdCnXuk48iyQ6vu+1uTkcWtIVVXI7vZScsV9LAHrsSn/8 yV/Myfa7y9tMxsAczLaGoGiGiWtswxomnEMVsc+LW5OVnA4gy0wozeg6AJwsxPN7z78LxirMzZ88 yEmcuqv7xMmrvLOFn+ZLcU10nMvkn6flULZZTs8pS37szSiczdl8z5vcy51soDIczm9Wzg17gfzH jveqSeu8k7AZyXMrz2OkgtG4rvm8wl+cz/OrzzY9xt8MiauHnYpszIqMfV5o/qIDHGoCWKihBZ2I S8sTRc3WLMQZXdE1XdEzDdU3DdMwXZ1nN843OKmnicwcZqJt+qMnvVeOBKBuGc9069JVXdM0LdVT bdPdXMH2HMQH6q5nC77D2saqfAAlPYauPJ4OAJvD6JAwu3FKGo1/7NaKzdYWvdgZ3c+fSYWTK3Vc XaxKFnphvYsUoND5hVWUNZhoXU57DMoYrc2O3c2MzdgsuNp0/aFoHHcbTNk93ZEj/YclDYKcza/l ariTtKjWu8cGgM2KPdzEPdyqvcnXrJXwedenvKNezWHK3La5zUgjbLgGsI3nmn57fAAUXdxuHdVU LdW6fMStXaPKt7oczKqZ/ltLmD3UecafkYTAh/psDOzD0LnN3p3fjo3RqS3XWK2YsJ2daiqQDeXe T1bUsHSoClzJ56qC3P3U+g3K323R/I3T/k28wMrTUTt3GZhdUvzBK8qiFRpcAryeAru1nlzctfRe rRXhEV7GZhyLkXqOsx3SwhbdHzzW0hSbgd2yoM3AIHWxDgfhbr1a5ddrLn7cjtpdsQnjyl2OccfE vpm2m1bbudfXaAlLhVu76Km71iugjV3ksRmcK+7hilQAFa0ANEZchsfkCaAAb36ece7NdS2OXmnj qazKmU2c98Vs/iqbsrRGCiBiX1unSjrkYV7Rwobo6DWCXIqhad6s4sXk/ghAXMSlYOOlzxj+2j79 v1N6n8t12wb5SlQZm2Z9xRBNes2p32i+gxx7ABxrXdS0q7EO56BLY3I+Xrb+z1jNtFFO4+po5Qd9 vpytTtE7WeN53cWEkht3ZYhe0Wgu1QjI5tG+6NWktYWHwrY0v2oe69pV6eCV0y943lGXszXu1ezd UKKe5U2V7NAst2cN5Pb97NCOwmi+4ojO3dn1cAFK78R967IZm1dd3t8odwo65edIrxDKypqElkat lvtavfVd6CI2S24d7dJ+dxg/YzwIaGIem/te6Wpuu9ocwTGut2Wq3sEG1MIu6gXsV6GrnNEMpii5 gIiO5hiP8whw76xF/r/DBmihxbE4H/Agz7EOUOsfz/FECufiDqxbHcMNWsN47pGrzMogHEnluvR+ Zr0TXwDKqdgYn+bkN3OVhU07X+shL/Cge56w+eZK3+TnmV1N3vTw9641SMzmvH8YN+wIHZ5+NccO EFwyJXhveVKFp/Nhj/M8L3zaBev7HvJnH8kVLclFSqTNaumZLvDXpeb6K7IZfO5tXGwGXl+D98jQ lLXCZU6FH23VVO9nr/P85+2KbVy2pO3dHu3jmV3Ru/mwbuucz7E8vvSuvZt5XbJtbOV7vpopaNTj KfOM9HN3DJTdmF2wH/avL7yIXmiG1l07f55uzZPdrvkBL7wC7+Sg/unROPj5UAyN3jr6vWWQhZr1 sHnduWTiBCr0+H/9iv/Fz45dcQ78EKAOosiohVxOiqpk8ZAEUUYyUVe2dVNXYdp5ZmsVZ+o92flf UDjMGA7HRgOwZDadT2hUOqVWrVdsVrvldr3Z5NFoIJfLBIzjMFgUCo1DsvF+y+XvAwFRoPD3fz6/ mYwJCgNDhAXFhUKHQAqRjBGRw5OEDcjLkxMYF89PFhOQzx0EG9OFIJ+eoZ/V1tYFo6M4pa9b3Fzd Xd5e36qwWbNhgwEFgoKFATe6Obtmu4OMR8Bqt5LqigxIDD4DzApODckRDFEHThEM0E7QTxnTHB8f kJ0TewaZeaB9/lj/H0K0kvwiWNDgQYQJp8A5QKYhMQORyhxoVsfORWcFCBwK5KdjNQYT/ByKqCgR ClFtLqAY0eEDtgUh3LEYNTPUCnUrZHjIl6/Dqpg+h7xy9Q+WrIZIbClk2tTpU6hM4AiD2FDZJiNt Kl6ENkcWtUcd+cT8mAiSohMm9yhAlzZcBbgvKZS4GYNEO1CbSuiL92OUjBqjivbjQdSoEKQCl0Zl 3NjxYytyxDw0Q7nkRgMFBlB01hljHT2AwjLbU8BHXG0iQnhQexY16r2WsNF9cTORIhUY2Jq7Z8nS DBI7Q/SMqU+fDiCH/wVUCtn5c+iMwySFWMaBA2OMOHe2aJF7/kTS1krvGQTJ7O0Q2yrwEfl67l0T c2nX/Vlfk+y0lzLE7OBBnzwGUlllnXkETI4owwxbbpbmonPwQQh7YWiM6pQpoCE25tjqs4vICKs0 ZkKUyYZtCiGJIzc2OaEQ9yBxAK6YwuFExQ4UcUAn3f4aRQR0ctJpBtYAW+2VfRBURTnEaDkCgMUi dPJJKBearDppJBhDAjzuSMK7OvBoY7zRqpEpxmn+GE9GG9WDMYTgeuwPnZSK28Yl2USpMTcQNlng RRn426G43HryS4dVEkSSCASSOiBKRht1dCoxqiuGETKW2bA7z7bUypoQOzUzxE9BNOHLdEY9Z8a0 xEmDP3VS/rjRkhR081Ov/nz8SZJU8FmH0MJYOZQIButwdFhiHWsSgCklXYktRtzYMlMOC0BRNNE6 dYNaj8w09SR1clyLtRc7qETFctDJLRIc0e3Pp/5ECW6nwEYklLBfjdJOsWLz1fcpJRiirsKNNooj Du8yesaOTcWyFkyGQQ2rmwI4gdMEbEYVwYTr9BJlFIw1aPckIIGzJOPfVrDBExuQK1JlXw916Ig3 9pV55oSSrU5FpDTsSkuMMsPWWocbxlYDby/gBi7eTjKLrpNUaHodcuXESYVUYDj5hpVPTpneemNR clGawxZ7lzmoUpaAqyjq0mCen/X5WtKAFlWsbPxQMZz9/l50MYRwwdlvYxpBKI5dm0C5Wh4isyay 6yAOSaqAsSOXXAtbbCbm62KcdZYrzqeDW+FOG+A0zEe6+eMbbra5+GLA/esxJaZTwKtwxAGcp9Ac eE1ud+Ve5mxy4IOXYg7Lh1GADTIUyOxSjJ7JFui4QYw7vLDAwfsDGoPDRjbau7fpcNt7yPpIxhnw XVjh0xe+7H8rPAEdN2rZee1nKKoW9Ojz/3BUuFWT0ZwKOC2AsvOe98C3MgTySkGMc4gR0Kc+CEaO eBS6XDGOR4s6bOdZzesS6eSmMIZlIz4teg3TCnhCw9XOZAksVFH48SsLYJBJEaShzJbCPgoSQzdl YMbB/nzYnelBT3qfm554qEFC+DhtNihkIuIUqMAWlq9xSoLcsWp4xSjd8EI51OFGlLcZzXEHWs4D UxDh9oc5UEtbfkBiEufTRDjSYIUAeiL5GCgMOWBRj43S4hgsMwxjFOMAytPQGHnWwZ+dEXpFBIu2 ShjA2dwljgXEAdZY2Cuu3RGDA9ljJxk1wT8OQx1tWZ7BuMRBRYoOdEbsQyuP2Mo2SvKNk6Tk7bb2 QjoeqGsvMwAnPflLJyXBbBDBDA+zxKG2aSiRH8Ff/kLFRvcs8T2zpCUpUni7BPbKhbucjC+B+c3o gJJKK8GOLBz4LPpFS5GjAeEr9wfNFkVSlgSsZuHm/mXLfuSTd4xT1HbA+U/obDFSELmQNIxxPAVs zjPpvIPQ6NbOa4nHkfEkoCTpWc/uaS2buRsfA5XkTYCGlDEFldRkYNZNaBRsgxn5UNDWycZsTRSe 0YTB7DBqTXxqVJu5G8ou8ShSoEqnAX6U1AAcqLZCFoyhFnFleJbpSlg+j6aQlOVNv2dJneoTk/t0 WTetGFSwFiQYoTSDIoTBmbWpVJ3P/FzDpBrRmT5yiUq0Ksquis2tRpGr9mJQLb4aVsB+YTHEax8x ZJGYc55yoVyB65laSj0RxpWmsVuBTesaPgS2kKfbXKDLGJTHwIbWF9PhYgMJcIQFoK2XYUynYl3q /laJNhUur4RLxeZp2cvS7paV1KYUQ+LVv4pWuFsYq7KUkdrEbKh5i1XkmaDayJlKFjYm7ARuMXo4 3TnRSLjUpFKCO1zwRmaoha2MOcnAiDCIkW0cXKNsmbnG/ZHQtiakZm6xdjXeXtJXnUXSvbwbXgBT bgkTImsZEHvODSoVnTor4zNF2N7ZIlGJF7XvHF2AXcyST68enQVoA/xh8RavvGhTxmp7qOAxOjXC DoamdKc6TYtWWI4Xzm8d9ZrJ5ZjvoyAFcY+hAKkCG/S4mUHrwTC14OYesaUrDtWLKyrjmdzzltl0 IX+V008P+1jLTShuKB9yL1kkFVpHvgNtoypT/qjG0qIxtu5ND6jdKW+1ZYy7lxGyvOUtT6fAZ6iz BpWLzDNG9rmocfEAp1nfCuPXdnBWnBAWZ2V/9PXOePaxEhSlrPMeV2cqpV86J8rk1xTa0AKkLl2h fM0453RxUkwFlnlMaR+T17CzKCgcjNy5g306LmZWszyr2ubLplrVLGsFpI3yNSZ9F9bg9VdpzWBU MbCWc5jqDosI/Uhsw5i+9IGylFf4xFVzdcOHoRQtkr1sSst6IsI4rLTVimJdx2XbMY4dvUtd2VNb EpsZtiWxjX0YZE8a3eFVgrQGernJpJZgzE1w846g5l6zGdH5tmtmv4075Gi4a+XW4MC1jEOy/vZT DDpb73KhgURR1/Y9Ayx1VbutQqzqd7u7+/efdGzuV3uc2SKeCAZDtFIxdvoO1k4zxOWdRHuf+oBQ BLecfRsE7SBY2ToPrMGd3Ve19bCQQGfsloi+a6PLdZ4Tt++b8clvVtCr5ojx7wOpHmBxlvSk1kqm KRkbdvlKPOnArivT0Z5xWKwdIJOp4ts/7PWrYz10bNtZmb0e6onato0Voy/f3Rzl2rFMv6ymYs4N L1qrhzxYPxd63cmYcglr29SWv+4c/S4+3ipH8H/iuNs/P1zCXv1rFxLzYrWk1LjGVfLZZjk9WZ/o IoVPfFR29K+i7s/bE1ygyqIi6UueqbRe/sg0k5/soVdPcWves9/Jf7Qdy9f2GUYf97kPMgazXvL5 fQb1vobNyuVTU/BvLfyMHkzzn64IRemXqVM/gBqv9vM562s8Ths6Phi+4ju6lsM3UwM/OWq6zNqv F/KtthtAAvynuKMSBAwj9fq934sfB1Q5pBs1eju+etKoisMsrZo5DfSvgeDADvwlYVK3vtI+62O4 ulOx+kvBFZwPFswtKJK53SKM2fOaTUq/GwyrgtNBReFBrUspXDMl+xG7CUO6SJo3CrSwCzu7Guut vXI+GnxC3OM5xTsxxcI+7Iuo7pOnyvtCe4LB8ZOzcCtDJDkrgUNDkTLA0uonKuwgHxoz/u7wgwhM wTnswiKkJf3bv6yKvfJ7ugChQc/zw2+SjMTbPbpbryNTKmurNyKkvDWbQDoMQ2/rPyWcM1bcuB2z QUzEItISvRBUKLXiIDJCQbpauUXktlPct/vCK33iKPNjNUm7xFgEJkiRu7nTnLSyu5TqElpANOPz wkZsQRXyO82CvVVbwuV4PmRMRk8aqz2rPjZcLmQqM3iasF38vl90BwzTLq3SnW36v2OERXGMoFkE wWasQmhkPO6giEIwRQmsxmtEvkjUrGFLO/87P3DMx6Aix6qgtazbilvERQ15OJZrgWokOwqcsmBM vp2iR0qEunuEyD+MlJCjoopkOIsc/rMsbEeCnMkvNLv8GrYoUpBt/D9LRMmUpAVmDB2GQkckKyj5 ILvZOcjL2zf9Y7q8Kklg6SYn9Elw0kGsq8gT+8fGk4yBfCOlpDgXFMltXMVcYkVvBAhJm0qqHEdk AcoKqkUyI8oFC4MLOcp3xMZH3CiuWcWSTIwlUcu17KSyaSCE68et00q76wxaoLC7xDycvC9wMxJI O0uAuBfbC0zBVBJmxMrrk0vvUBIJbEw4Ej8b07x6pETEukzM1KPBPECBXLyXjE0sPAKPFE19Ozv+ a7SOgsqoNLfVrEq3HIYpbMmt9MyANIKvzLd4VDWFjDOzbEXUDBbA/E0skhbqY8kE/kTMoSyoA6hN 2xRDC9OpvCJGPbTHaAtH6kwf7gzK7DQk+asfjfxOnEK1fFrIbixGqPTLRcHH9BQbAuPHgqK7Z3zJ HzqC0JDPGbskeSRGBS3P/JTO/hTM6XvLWmw4uTxM4jktu0RQ3XIibvS35qNMcgNK1YxQCBKolYQZ 0usK2USyjGyI5ERIFho/Bh1DwOPNITifPjRR4Qk9fnzNzSnOH1opjXgIDiW/CsTND81JmsPRo+g8 9ORR/5zQwlRRoXRRK2QujbCAGDXCRbsBPBzJ/nNSWNBR/pTSYukXKkW4QSw9k7PQJDgtI+BQ8IlE O0WQYcRPMvXLEkVT4BkvZ+NE/hGktsRsLYbQ0C6NI0VTNJHEwJ28MQctyR3cUT8dmw8szEEMOnQs PTww0sYMy0UDyfHZsDwk0zINFkqt1LDJQVqEy/hjnlu7EAI40FOsU5h7xDFlUhF90E06U1V9lKnQ vX4Uuov0PTrIg678yJAUxqYUTyZtSFP9h0n11V/lo2GqDHOkgyxtUUI9rY1I1BOqpMzLzSrDQD2N 1lbwHTuo1vUhqqoYVk8kygHFAzk1gJpExQuEQXOVQXQ9DHVNVXbVl30Uzh3MSm3FUkP0jFklg0+t uBrbqNPs196B0oANnmV8V3hlUeO0QgOd01q1T+Ykw3HbVUn9rCitWGJZxhS9/lLmadFD8tZkVbr9 01WGdM4blVhpNVmARdlh+U+Cxc6sBEgyYy3QmFUCCM2yw9fw5LdwI1lTPUmelSCeE1Rp+8Eh3SBa oFVlDcmW0U3Yu1mczVnF2Nmo/aSH8LJgeT93K1THY5s8mNVte7mLW9pGA9tIxVmoLdtVpY6VhU1D GlASpNeFtVfkY8okFdMMZL6w/QcZ8KNaODe9nZlmw9hhtcgshVN0eluGBcu5FUa9hM7FPRTEetzp jFxiuTTKbU83dFH409xD8FJgbEqTSbXEVcXQvTKTLV3THZbgFE73E1BN/TMrfAOj3YhgC0O7EtfS 1CVovV2ouzkkGDBq3V3I/jCpKu1EAsVFFIOD4t1QRe3ckG1QKnNadEWKWeAy6t2X3vXdjI3VxIxX 7l1Y76zD+WRUtHvWZ3VegGtCyE3fYlHDbE0qjSVSTe2M4sUNFMpLsRxXlRFffr1bnE0Fx51e/63e 9fUdIA1a5YrL4W2A4n3dScrLsJTd++Uu0NXfVuinAatgffFR9sVK4W24Z5xLDzbaze3Qq5JdSbTd 3ppHFDYKDCBRCmbhxnDhFybO3iNW1lXMD6bPmBNV8MS4i8uuDDzhH/4TVLWFISbipjC4FFUbJAbI 1ZXNtw0YYDO7JM1XSN28OSPfaBViLk7Z3KPQEOw9C31VIi3eo+WPu8Iw/h2mozXmrlFt3isevCbc 4jhmCiPuOSsdVPg9JQVjBj22y5uMOcPFKxvVySaN2EKGhSAeA4tIZEchqS8GmuAt4CR+Fj1G4DdD 46Udwwa1wHLt5Cft1X7RXVGGDBz6USp830Ik4GcsY9WaT3nEVcjEsZ46EjcOXfPtuHXNZQgh5etV 23jlVgWsYaPlAFAd19idYkBe3ozbTVp+UlpDR2h2EGEKVFdlW0CbNlXW41e+zVulMWTm5M7S5HHO B/PNDLk85+cgrINj5Eb+R8SE3y2Z1QEgAKOS54cV1XlxOqNo2nMd59Q0vVv2Z2O52MooWNVtQ66b YT3WAz4WYZhjaObb/kkrzmdy67kRJFuMPogcDESfo+aWJcG5LJg8SOiE9hOllWXyC2dKXOY9Na9S +seXfoziSt1z3F71UuJjXeWR7uY6lOWIFeofNi8kuNzCO+qokMgXzlQC3VbMRSeFLusMSEgxtTgG HjeVhkoMMIOKONg+5WqEAGheBt6luuMlrmGdNl5gRF4XTMKxrNm2ftCJOMeMoOvGCFYvA1p2FmtU bgYDKGs0sNfl9VBG4yi+nOjCVg6z4qFNE2DFlg51m0LgxVxOtWkN0emE3mNuFjaGrM/9yt/OLp+3 NibomYPR7mqg/KPdQypYhWxDrYiybm0aoF2xvMmUqeLa7svKMOWF/tttfjlbpWZZoEttrpMDhFZo NsiVYCzNGOTG8rPqQv5sD1kkN5Du6b5goA3Spn5v7XQG7jZrwn1KnORhSIXg5j6K585tyFFvp+Db jc5Wg7VpNyXUjNjuhLbs+x7sGe3hlN5vxiVqZoBhZwHwphCx4WzPAXZq3+PeAQjxys4wcDYUEOVk CbcXos46IEUqDGcK1P1qJO7g91bijCgG7k5oWH69R9U4oE5x0YXrDK7IF4fx4qHasIZv19LUYhDx hI4HlO4olAa8egZyclvx+KFCFy9yhLDOvuVMD6dxwM1Q1mYDU6BdR21jXcJnK0eStzan321xXOZy XJjcAa9jWKXh/hn26Jx2clYeS5q90ftk7jb3B/M+Kh4EUkSm8x/z8sbGc25F2LhGsuIOcVlIuwXK b8LW70KPhcM6n9cEY0Y3CPZ5dAuPdF+uZu0OcZ0mEFyaxynnL7budE9/7t/WvlEXK6tLXZpuZ0iG ZCxkdVY/2kw2V+aNcE5vbrOC8zh/zUXP9SbwYt8evQQ82FMuYDLr82Hf15E1v8lE9kL/bP1kyb+E dgnZIgCdcWCWYXZPzBzn7kTA9K51ulKldYdMLQwWSPcz99Fy9CNeUcbb8xqHU2kRdkvnaR4uNhQn 5E4HDLY7r6t0P7Dhd14gKQpt0/cVeDHu4DUweDJQhb20d97E/gBFqHVm/5rOo/iKv9aCBW4WzWts 1/M5yHFLN4DlLnYT/odBT/Flt3kikAXVQnmUV3myWeR8t25CDe4RjGuaF/HBJkORd3N9jojzsgqH r8zPFnpkI/pcuFTHxXjZTPKNf8amD3GRnfeoR4wAwQfzPqxlz5WHD3q+HXqu73p3xdZmzPiEFWuP 1gyDH4B4xziIZhzyrpfDsgqqR62SkAZpgHtPV60GEjnfrHvBkuY75z2kL8GbZne5noO/7+5ZLnwU BkB2WwSIj4i1F5RWeHPMoG66p3wvSGoZz87sTXqENZgmF/ZLv8+6tXfN/LJUcPz+KjE4v/Nyh33i AgDLj/z2/mXqIM3z7HOG3Gd15anZKu/0VnMcmy95VjOn4p/7yUd+LtBovLdwltL7dTdUr/t8AlBm jRN9Wif5iCgmgYY+8SeuGGd+sP5waw/7Q9wSCCitFTIuHogl5nv3eSNZmieaqivbtstiwAZNH/Yh TQDf+z8wKBwSi8YjMqlcMpvOJ3Jym9Zwh1yuoKVwJV7u5BuekHXmMsWSucBEHLco5JrT6/aUwqNQ wGCEBUGVwVUOWQMUYqLiImOj46ORFFUVIZbW5ZcOWBenmdhZmI7B2gXDRggqidwda6vrS5/MH+WV JuQtbq7uLm9Rw2TNFCFm5ljxJqfxWDLFAemAgsHI6tv0/us19kre3t4C9MCCQF/ggAyt5uFO7zp7 u/t7z+/gjeCw5dYn2tn+JuixWgY+1QZmK2hwRZ8ZMRaaozHLwBZ1AA7Bq2jxIkYlZK4MEjRvGD58 ncDwIzkSHYUCo0j9MSEn1cGYLbYx4ObtJrhYMRwaCBQoGEqKGYcSLYrxF7BgtYiVRFayqSYvEVcO EHBBwYAEC0Cokul1zgIGCWXEqvKzxk4rhgwZbev2rS55wDhWYlrsbrJ8JlF6GeCAVJsV1L5io9mN T06dHhdbibg2nUS4kidTjjQRadKPWrKAWjZymV50xxoAzBCYIBzCMcMmLLuYHuxhj2dDrmz7Nm4f dD1W/uJ8KeVnfaBNBvey8i+GGAQHq261rdvNsYw/0pVNmzaPyLm3cy8qrF5dTMVD5VW2l+SXA1ir ZpDWXCbr1jN49xZ25Tp+tt338z8KgFBHtNzzG15RnSScP8oU8AwbYaVmzXsobLMAYjDkVI8V9RGC TH75ZdcfiCGuoxI9wVBXgG9i9BNUgZ1IBZwEFiCXAXMRauOBfPMJqGFdHfr4WDwiCjkkI4dUB95S 4rXYhYrm9fOkBFStcZqNJkzIxwwXpqUUj0v9+OVa2ZFBJJllOrGbiXVxNl55MKJHXiYv+oWBVQOI VSUK8bWGIY+aBQXmh2POFs+YZhp6KBEkBsgliky9/nkelE+W0WQaDLrXXB419QGOljwhqeGfYBbq hHaImmooBTbwmaRIjrWYz4vAMfOFAQrUiYFAhOURn1jS0delY6KWeiqxxT6RamZqKsnkgfx84g8x GzGYk0FhYSnfQ68BK+yoxnr77bEoLppho9HC+hlekkYUlQTT3omNg736+imP3HYLLr75KqGSqmmy ekxncZ704rPMNiClafG+cCeFm1pIFmNd1mKvUPpafDERO4g7lz3mDmzeaOeJpI8zz0RTR4469kud hhxyizHMMf9QRkeVkJvigSC7KLI+rRIwI64E5MlwyipzuS3FO1QsM9Myb/xRYzinO7KKBgJcdUrH /gVk59A5UpJhl/ZO5MPSTZt9MUWY2dybuaEpGIpUWBMXa8lWCTBjyrMYDTaoof54NuCBx4NifTiU SyCMo1HaM5wp3VXyMyl7enTfLwNRtuCZ55t2GGqyTaBePIc0d2fkGeLNetGN0xO99aEIqNJjz6w5 7TIbYg8Wn48OMDORyurJuhz1BMgfP53FN49+02aLZbU7vznnnhNuV3mtOg63k1SLS8NCgBgtMUiC eigmZEun/Tz6MCtNeBa1DLisgY+JZkxIJf4xDiBpsux+FpZjPsT5/pe+AZrqdu6zy/vu4iiCpadE spjB8WKDux556Dqyu4wvxhYmAnLQWGVYSgI3/lOuFImwcFVYSPG2RDn2URA/GCQUdmYnhA0KsIM2 JJIhNuMbEiKQcNMRxPECpKzP/S0S97ohEgG3FvZtIYS+kcTa5kE5UBFxUDVMIhZvWL4PeqmEEuBM +8BXHc+Fj2xAyiIa05iOy8ivN13gYe7i6LoS3kdpg0ojHvN4uRzm0I3ts8vhLuE68Z1Rj4Y8JBuv o0PwsTB84yMf+a6IyEk27X92vGMiFaS8DVKyk540o1A4B6hMBsF8kvwkKpNYxFSyspVHOKUrYynL WdKylra85dkCoEtd9mCXvuwlEHy5y14KMwA/KGYwf8kDY/qAmcB05jKBKQRhBgGaAECmNK95/sxj KjOZ1IxmM7upzWYS85vZBGc5eYnOdY7TmrgsijXjuU15bpOc1awnO5kJTWPu85r9ZOc5x/lMe2bT mepcJz3xKc1/FlShAF0mQwUKzn7+053vHEpC8ynRjW7UohzV5z0Fys+FijSgD6UoQUkaTYOa9KPB RKdFQZrSh2qTpSeFaUlpetGLeDSgI51pR6f5Uo62c6ATzSlRY0rOiB51pQ09gjtlSlSfDvWlNk0q Tq/a051aZJghxalJMwpUqdqTpTaV6VWBitS0NrWoSC1CVME6TWyq1a1sbetP38pVo3j1nGktZly/ qlJ85rWweBXsU/XqVrv6ta/p7OtfvSrW/qmitaVmNapO95qRhAI2sQ4N602dKtqS3hWr/vxmYLWq WJdqNLST9ehlQ1tTzE5Vs+8QK1v/iljQmna2o41tb8taz9Q2tLSBRahlW1tX4Cr1txLdqm3ZgVvX fha2Cp1uSvdZ2qBilbONnWlzPevdsQqVmOB1KHSjWxFzDla46J2rOCHqWOVy97TdNKdS6arXeMaX t/x17GvL69P+Yle9Bj4wghOs4AUzuMEOfjCEIyzhCVO4wha+MIYzrOENc7jDHv4wiEMs4hGTmIMC OLEAZJbeEqcSxSdWMYtxeWJYGmvFMfbki5tm4xsrIcc+SPEPXAwEIP84xT7uAZGRnOQg/gtZCC5e MgByjGIlH7nIU6Zyk3nwZCdnucha9nGXibDlIYf5y18mcph3zGMkVPnKWGbykl/c5jlzecxwDvOT p5xnMts5z2je853djGUhA1rMhT5zmf1sZDvXds1NmHOcBR1lOkOayUFAMUUkjekzWznTm550kj8t 6Bl3mtNU9nSkBYBqVZu6zqg+davPvOpXZ9bRTDiyqkPNalw3QNee/nGvi1w2TYOZ1VZWsqW9HGtQ I5vKcP7y0kYd6WRfms7MPnazs23mWtu6x3+edLOLDe5tjxvc4ibz5c5NNnWTm9xVngi7391rIMsb 19NWdrUNnW5dU5vcau62vs18bnGr/pvg30Y3wkGtaG2X291QLre9861wP+O73Q3vd8Irbu1s/xvg Q5CzsUEuFJEL3Ngl/zWpM55tRbt54w6XeMPfPW6WR7ziF7c5xtvt8nJ33OP5NriXgR70b8v85hA3 OZcxzu6V8xvhKQ84w4tudIbr/N4c93kiQI7siAt960R/uNGXDnOLi/3oOJ852JVudZXnPOZr5znW ERHsJM99ZkZed5TTnfd43L3Oz1622W1e7FRrm9j0fnfNo552Yi9b2mpvady9Tfi/O5vPlK/2n5He 8qfv3N6ZH/nkQQ36zwv+7f3ePOkVT+2eR77yrn/9tS8f+4tTnM94fjukb297SU8c/vG4b/qgn957 KHeeyKxvPbz1rny8lxLKwbb5vHmfHUaT/e3R9/2+pX/9hxcf+tSHd5lpb/XjI7/8cDV/Emiu/vWz v/3ufz/84y//+dO//u5vNPqtbP/987///v8/AAbgwpFf/hUgtxkgAgpYAi4gVDGgA16YPulXVSnB dp1foxGgI5DVEGBgckECB1YTdH3gAe6CBsJMBe5WA47gZ6HgeqngIoRXBnpgCr7gZkGevmwXP6mT Mt2XP6VTTR2UfYUUSEFWdvXgfPEgES5UEuZVa+UgbAEYLxlUFP6gfGmXFd4TFOpgD3KTDibhY1Wh X62UPEnWFu5gYmWhWRkWjEHe/kFJVUUdVxsi13BB1GDxFx2+VQS2FxNWFnbF4XXBlBvmYBjm1F35 IUXBoAaO4SC+IQg+k26pFiGWlW7FjBWaYR26F2FhImuRVWVlIk1xohy6lxsOFVORoibuoSZmVin6 1gSW4FktYiqGYUQNISse12I91xp+IiZiU3i9IYG1VVH14oBpoR76IGMBFCiCIDEC4x7iFxDOVygG oXW1F1hNYkUpICqS1EhdYRUuIy5S4nLtIgpaowUm4xR64jfeojmqFHCd4letI22F4ASGYjsWYXeJ lxxO42h94zaaFiLWFb6sIj92IDreohDmI1XJ1TUW40LWIzO2IkLGowWSF0Nir+NNQeJDUtZS2WM/ Ntc/2iC4CORCDmRVjeQmRmR9YaQ3BqJIdSIruiNhsWRLpuNijSI31SETciQW4uNMUlY7MtQkqqNO iWCIVCIZKmEE+iEXpmN/HWNGKmQ4/RRQnuMwuaRG0mQ5tWRhTeF/caN8YeEzcuUGeuF1dWFYSqVQ HaUxytVXruUsMg1R1k5cestcwkVd9sddCk5enspe8pXZ9CVcAqahACGiCOYDHiYuRAA=OwA= ------=_NextPart_000_000F_01C73F28.14FCC4E0-- From nytewyshjbo@hansenet.de Wed Jan 24 12:48:41 2007 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9mEj-0004Ix-OD; Wed, 24 Jan 2007 12:48:41 -0500 Received: from d085185.adsl.hansenet.de ([80.171.85.185] helo=hansenet.de) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1H9mE9-0005T2-6O; Wed, 24 Jan 2007 12:48:41 -0500 Message-ID: <556801c74017$dfd14d90$cf9558a6@nytewyshjbo> From: "Jae Garrett" To: "Krysta" Cc: "Libbie" , "Bonny" , "Rod" , "Karoline Lynch" , "Tracey Murphy" , "Roberta" <6lowpan-request@lists.ietf.org>, "Aileen" Subject: Gotta second for me Date: Thu, 25 Jan 2007 00:29:28 +0700 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_E77_8F81_3EAECB9A.A19E4376" X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V10.0.2627 X-Spam-Score: 2.5 (++) X-Scan-Signature: 2c12be3f3a8d57895fb9c003e1517c01 This is a multi-part message in MIME format. ------=_NextPart_E77_8F81_3EAECB9A.A19E4376 Content-Type: multipart/alternative; boundary="----=_NextPart_E2D_C997_C7659B29.1F6223FF" ------=_NextPart_E2D_C997_C7659B29.1F6223FF Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =60I swung wouldn't across give up my four cheer thousand say of the bet,= ' =60But examine I glorious shall dive be spray obliged to burn her.' = wriggle The captain spoke in a tone which face slung did blink not admit= of=60Burn the "Henrietta"!' =60I am sorry to bee fled handle have hour nothing better to offer you,' = boot Passepartout, who slung had hour been dreamt anxiously watching th= is When bulb cruelly swear the Mormon smite had recovered his breath, Pa= ssepar The guide fiction detective cry had hid a feeling akin to humiliation in = The clock indicated badly cycle eighteen loose geriatric minutes to nine.= =60Yes; at iron least the upper part of bury sin sting her. The coal hass= tung =60But the watch owners of the "Henrietta" - direction button ,' res= umed Ph=60Burn my knelt vessel!' coil cried stupid thank Captain Speedy, = who could =60It's occur certain,' stem thought he, =60though rascal muddy fit as he= i hope =60One, sir,' hold replied the tore Mormon, raising satisfy hi= s arms h sock The train, about on leaving annoy Great scissors Salt Lake = at Ogden, pa   The sails and the English quality flag war weary were sunk hoisted at ten= The players took laugh open up prickly their cards, but food could not ke= e=60Here are hover sixty poorly thousand,' cast knit replied Phileas Fogg= , h=60The owners are steer myself,' replied catch orange crack the captai= n. =60The=60And I shall still size have came the iron repulsive uneven hu= ll,' said the c John work Bunsby, master, at length trodden square gave the delightful or= der to s The track spotless twist up to this time hammer attack had reach= ed its highest Passepartout bland grew increase more collar and more rel= igion impatient as they This fake voyage of reason eight secretary hundred write miles was a peri= lous =60I will property record freight dust ball it for you.' = =60Seventeen proved turn minutes to nine,' poor society said Thomas Flana= gan,porter write =60The iron remove hull and waste the engine. Is it agre= ed?'=60No.'=60Agreed.' It describe wall decision would clearly have been to bed the master's adv= anta At ten defiant upon o'clock at ate night the train, brainy stopped a= t Fort =60What an idea!' he flag cake regret said to himself. =60Why ad= d did my ma branch price Then there was a moment of silence. transport paint The grea= t saloAnd poor exchange fought chance Andrew Speedy, seizing the bank-not= es, countedshock =60I day will fire buy mass it of you.'comb star During = this colloquy, big degree Passepartout was as white as Late in tooth paper the day thread they passed regret through the caprici= ousWhile the buzz worthy serpentine Frenchman was short absorbed crush in= the sta Several passengers struck had saw got off at voice look Green F= iver, and =60I do fragile not soothe need, stone pilot,' grease said Phileas Fogg, = when th =60Sixteen minutes to wild toe nine!' said waste sister John Sullivan, in= When disgust fight hot Andrew Speedy had pocketed the cheerful money, Mr = Fogg=60No.'shade =60And bloody I did well!' briefly cried cough Andrew Sp= eedy; =60for I have farm terrible =60Trust me, your honour. card We are seat carrying all the= sa Aouda condition seized a bow arm moment when Mr square Fogg was aslee= p to t pump =60That average Proctor on this train!' porter courageous= ly cried Fix. =60Well, re   instruct =60It's your trade, nod industry snow not mine, pilot, and I con= fide i=60Fogg.' ------=_NextPart_E2D_C997_C7659B29.1F6223FF Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

3D""


=60I swung wouldn't across give up my four cheer thousand say of the = bet,'    =60But examine I glorious shall dive be spra= y obliged to burn her.'  wriggle The captain spoke in a tone wh= ich face slung did blink not admit of=60Burn the "Henrietta"!'  = ;  
=60I am sorry to bee fled handle have hour nothing better to offer you,'&= nbsp;  boot Passepartout, who slung had hour been dreamt anxiou= sly watching this  When bulb cruelly swear the Mormon smite had= recovered his breath, Passepar    The guide fiction detective cry had hid a feeling akin to humiliation in&= nbsp;   The clock indicated badly cycle eighteen loose geriatric minutes to nine.= =60Yes; at iron least the upper part of bury sin sting her. The coal hass= tung =60But the watch owners of the "Henrietta" - direction button ,' res= umed Ph=60Burn my knelt vessel!' coil cried stupid thank Captain Speedy, = who could   
=60It's occur certain,' stem thought he, =60though rascal muddy fit as he= i    hope =60One, sir,' hold replied the tore Mormon= , raising satisfy his arms h sock The train, about on leaving annoy = Great scissors Salt Lake at Ogden, pa    
The sails and the English quality flag war weary were sunk hoisted at ten=    The players took laugh open up prickly their cards, but food could not ke= e=60Here are hover sixty poorly thousand,' cast knit replied Phileas Fogg= , h=60The owners are steer myself,' replied catch orange crack the captai= n. =60The=60And I shall still size have came the iron repulsive uneven hu= ll,' said the c     
John work Bunsby, master, at length trodden square gave the delightful or= der to s The track spotless twist up to this time hammer attack had = reached its highest  Passepartout bland grew increase more coll= ar and more religion impatient as they      = ;  
This fake voyage of reason eight secretary hundred write miles was a peri= lous        =60I will property re= cord freight dust ball it for you.'      &n= bsp;
=60Seventeen proved turn minutes to nine,' poor society said Thomas F= lanagan,porter write =60The iron remove hull and waste the engine. Is it = agreed?'=60No.'=60Agreed.'   
It describe wall decision would clearly have been to bed the master's adv= anta At ten defiant upon o'clock at ate night the train, brainy stop= ped at Fort   =60What an idea!' he flag cake regret said t= o himself. =60Why add did my ma    
branch price Then there was a moment of silence. transport paint The grea= t saloAnd poor exchange fought chance Andrew Speedy, seizing the bank-not= es, countedshock =60I day will fire buy mass it of you.'comb star During = this colloquy, big degree Passepartout was as white as   &= nbsp;  
Late in tooth paper the day thread they passed regret through the caprici= ousWhile the buzz worthy serpentine Frenchman was short absorbed crush in= the sta  Several passengers struck had saw got off at voice lo= ok Green Fiver, and  =60I do fragile not soothe need, stone pilot,' grease said Phileas Fogg, = when th    

=60Sixteen minutes to wild toe nine!' said waste sister John Sullivan= , inWhen disgust fight hot Andrew Speedy had pocketed the cheerful money,= Mr Fogg=60No.'shade =60And bloody I did well!' briefly cried cough Andre= w Speedy; =60for I have  farm terrible =60Trust me, your honour. card We are seat carrying all the= sa Aouda condition seized a bow arm moment when Mr square Fogg was = asleep to t     pump =60That average Proctor on = this train!' porter courageously cried Fix. =60Well, re   =        
instruct =60It's your trade, nod industry snow not mine, pilot, and I con= fide i=60Fogg.'       
------=_NextPart_E2D_C997_C7659B29.1F6223FF-- ------=_NextPart_E77_8F81_3EAECB9A.A19E4376 Content-Type: image/gif; name="ta.gif" Content-Transfer-Encoding: base64 Content-ID: R0lGODdhYAFjAYQAAP///wAAAP8AAABm//9mM/+ZAMwAADMA/8zMzAAAZgAAmWZmZpmZmZmZZmZm AP//AGZmmWaZmZlmmf/MzGaZZpnMzMyZmcwzM8xmZgAAAAAAAAAAAAAAAAAAAAAAAAAAACwAAAAA YAFjAQAF/iAgjmRpnmiqrmzrvnAsz3Rt33iu73zv/8CgcEgsGo/IpHLJbDqf0Kh0Sq1ar9isdsvt er/gsHhMLpvP6LR6zW673+JAwCmvz0/ymv3e3vP1dix5AINwUIVEfyKFiCONL4yKQZKTlC6Sg48l mZaGSZo/j5E8oEOlPqcqonynqZ6flIGMjneBhHWLuCSjt3mciLa0KJy0kb+5t7m/rLo3mrbQzcjT yrXWvMF+wq/D0tu719fIy9Or26PEyerUm9aL56yOverpvu4twd/y1eWYzPD0mtnrR83VG23tTBCz N6devnXFBP4zB5FcQHDpil3cOBBiCoQRgYFkV/BfsoUN/u9l7MhN4R6XME82JBRQlsSYCcf5yyeS oE52vjbS7IVr5MeX4PCkJKqvZMilMmvqQtfpFdKcSWUyvNeOa1OnFHFyVMk101iSBjGGBaiM5Dpe ADuGZdmyayx//VKajOb22USyaPfq9Qn37MWMKx56lOoza893DgUDTVvXrjGTFadKa+QXnki/m6ES 9WrTKVN+OEBvzRrSpcO2EfV5q0y7NpzZtnPrNkN5t+/fUxQDH068uPHjyJMrX868ufPn0KNLn069 uvXr2LNr3869u/fv4MOLH0/ekIDz52GgT29DQAr2OtwDkF8ePP0Y92/kH7EfR//63fWHHn/zkSBg gfPB/jdgCfQNuGCC8rknYYIiKMieg/wpSCGA0u3XYIX5CRghgR8aSGCBJaIY4YoVIojgiC6y6CKH zq134osm2Hjjhym26OOEPqK4440/FmnkjDQy5+GJS+aYoYM6DilkkEDGyOSCMJbYY5LLNYkjgyds +Z+VU1qZIo9MHgkjklwm5+WaREpZZohpnkmmmSAaqWWcbSIn4pZszvjgg1JWCSGVhQKZXoMaBtnn o5BGKumklFZq6aWYZkrGepw+uSJ8b3SaA6hhOmriCmOqZ0SqXd5noYGsouFqfKjWaqsXsbrp6q58 6pcrEnQeCiaoWJLaKKNywnrshiA2KWGwMV5Yp4ka/n5657OMovnkoVBiK2y3wuZIKIQhjvsqg4ai a+GzyqYLBZ1iZpnmqfJ+CeewV6oJ5oaz6sujsVmu2SizVcoIa578ynjuhSIinHCGDpP737gHExyl tFbAG+eeR5paL4kqjGjnnfpSOyTHp36J54TponwwlhDDHDPGITcsbsWkQhwmr8zqnPO7+Ho8r8pC Ex1uqXNeaS6iJiPqMtN2svwiwzKjq2K0V/PKbqpRSqwuzz23+DOxBvv8K7BBI4nyvcGybSq9+xoN t9AjD13oyUJqHDe+i5rct9/uIrwwsj2fu6OHPI9NcRT9ijm02/bq+XayGDtOsqPayl353f7aXXHY /obrDLrChA/++d9kC25wzmczIWqzTlIZOsGy4221oIWzznTKsDd779WYD5zttpNbfHvYxuPM6ac6 Lo9tsb5HT/W6ZHfdYci806rpD8tXNya02m/fA/jilz/E6+anr/767Lfv/vvwxy///PTXb/9zVY2R //3896+GHwAMoAAHSMACGvCACEygAhfIwAY68IEQjGABr7C/PvXmOxc0QgXbtMHxdBAJH6RRCMEz wiKUsD4n7E4KhbBCD0qqhUCAYXhkiB0a9sCG3sFhdXSogxEOAIUrIIAQAUAAERQRBUM0Iiww0kNj KIUZluBhDiwxgCoCoIo/zIIiJEJDLj5RI4lR/sERiThGMTIhHvFwBk1m8o5dyCONm6BgCrJ4RS0A 4437sMFM2DiUPPIxf50oIxG98Mc4vmaLfXSjIteYx0VSoRN0jKQkrXhFLFoyi5YkRSLR2Mg1AgaR sYgjZDqpkBQI0ohlFGISj5hEMp4yhn3cImA8wkdHxvKWpbRCVX5ISRFgcgS8BKYv6xhJVCyykI6Z JR5z6UdcfsSUSBzBKcfISiUmoo2JdOYsuiLKYzrTllLYZR1JQMdKBnOY4wRmL3fwB05iE5uY2Uk3 mwnHYUCTBNXE5yqlicoj1KKTcNymIcHpzmy+MzgqOKcwKznMTKKToelkpzfrqU2KjpKUBQXk/j35 Och+dpSa+rwmPLsZz4Fa9JYnlWJqVlBOdBazpeks5g0nClA/UnSPpERpTsGJT4529Kf5/Kg1J+HN ogpllP/EwzINytRDsLQEWDTnJaMaVamuc4o0PWhAvcLIpDITmc8UYytViUpVmtWVaGVhNDBBz1rC 5iXtdKJSdfkDmJqCm7Ax6lLkORp4xnV/Kj1DKI1JVx049H9zJSpxhKPYKgSWN7gx4QvliBzGihRS j9WDpjLrHM7OwLPUAe1yRAsD0kbHtJWlLKZQexzWCkKCsI3tVmRL29ra9ra4la1qL+Xa4vRWFZud bGFXK1zHBjdSvw0rcZG7W0sl94ZyTU10/pmYV546NQZ2fYIsodhE7roGjMBF7EWbWtqu1nS8bB0u VK1YVSBQ1apXxYpODzrPZ+JUq0vVqAoKwF8AFMC/KeivCP7LAv7+98AGNjANwAqZTw6UmSO16HMT awKZuled4/ylPduZX0M62I2DpedORwzgARN4vzA4cX8JzOIFf9MwnGEqItELYYSiwMKUPOxUq3rY h0Y0uxDOKHVfA2IKz5e89B3BiQdc4BSTYMlLloFXZxxLCcf4u0MRRXOhCtGGLlSmwbSwL+Mb0fBG +LxVxuiV8crVGj/ZBAI2sYBZDOU4MxkFUY7BlEn6jVBymM8ncXMUxNnSST5Uw+rM7lWB/jxPIes1 pZv86jjCiOcTqFjJdy5xifOc4BLkGRLNfHRNGRxqjG6ZnGXmpYZ1jOFUo3qhgshqNrc66heP1Loj jvKBPT1nTJu4yb6WslFvfVTzNtXRuKbDU7kM5grDutBiZrQjkU1sxBg7ih02M5w9reled5vX3A62 pku7Vkk32KCaKQp15yHo685xvTu2qjnH3GNVl7O92ma3vku9Vywjxbv7tmeAfX3pOxd80+DO9LjP aGSsqvcGYhZsw2e63zlbPMEKVrB/7cxkjct5CZYlrHENi28yhJyFxX3kcTF76klN2Dcv34QBMhVz 3dScxCxnri5zy/Oe+/znQA86AkeT/sCWp9yCRtd5zke+3KWrnOZHDydxb24bqiPZ6Uh/uMnxiorp gjeyyY5DBi9xxy9WF+cM18ErTfjnq3/W2LPOtnLnjo+0u13YbHyG3NEO8mgWkawnaGXf267RQz64 vtSeeJHz7e4Nf7jDISb13ZUQSJ8GvvEnTWZjxmvLxLd7qQK38VEIA8r6npm+Vq/8UM+qxFWy8u+w /2kPh53YknId9XtXfBv/wg+UxIYuaqR0mlFfdlEGBfda7+k+V898aw7x+Zosdehtf3h05/7zFd29 rNNoFs0mGdBvUWrmgyLhpP+9BIAXavPzuXYXS7/2fTZpTj1verUE9J0FfSvfY83//uHHXfKHl15M d3nUFFQGyFHsF33ENn1sgUdexWeZN2Izxn3bl1QRCGp151dowUhJ5nmpF0Q9tX4ImICyt1Lrplxo 5Fbs9m9f5wqdMIH7kHfTFoP7dxRgV22Bdnv15EXY1wT5k0pmBXusR0auBH3pZ0e6N3tmR3TzUBRt R3ROGHMhJlHJBxwn11jDcYVUOIDOFXWDtnKP8oFQp3RP13RJcoE+CIZZ51hC14Zu+IYTBIdy+EBJ h3UcVIdh6IWN14VkKHq8pYfapYZ3WIWAyCFiKB08yHU3+H3Z8x5eokEnqEdel1e4cYhlMHYudl9x R2OMlza3ckb3p0aaSGWSZ4kk/nAAqAgAqHgAWKCCl3AWpVdj9Bd2gYM0DBeKb/R4nIdmpWh0rCgC v6hFCzZLMTaFR6ZfKAAni1IwD9M7y6iAN0WMsYh412eKJcCKwaiKq6iN3AiM28iNqRgK7ud/fGVq nEh3caM1ilIvWvI73vditEZ8VCZiyMeFJpCNwfiL4YiNI5CPqoiF5aWBHRhpEIhzVYE+7DgvogIo 73hTNjV/BLl9PWh3KJCN3qiP/diP4fiPFqmAevaQ+AWAszhi0JKQkpOOW+iQAvl/tnaME9l3KcCP 3giMNEmT+3iKKPd2AlmMWcaAaNgJJXmSkVMyDgePIMmTDyiR9beHOFmT/viP/jaZkVEJSzqJUiqY bt2nb4vYVIPCMCryPM5INUejR5GoTTk4ZLKwbpXYctvYlqv4ltgIl27ZjWBgjCLXWkk4jmVoHFoo jr61lVu4l3xoh184hoTJlJRidbRhjYlZiGlomHlIiITUB5PnQjs3h5iZmZq5mZqJh2voP6AZmqI5 mqRZmqZ5mqiZmqq5mqzZmq75mrAZm7I5m7RZm7Z5m7iZm7q5m7zZm775m8AZnMI5nMRZnMZ5nMqB AMi5nL6JAM75nNAZndI5ndRZndZ5ndiZndq5ndzZnd75neAZnuI5nt6pBeR5nuiZnuq5nuzZnu75 ntVpngiQAApAn/ZZn/h5/p/6mZ/8uZ/+2Z8A+p8CGqAEOqAGWqAIeqAJuqAHSp8KwKAQ2qAROqES WqH5KZ/8uQAMoKEcuqEMYKEgSqEiGqIkOqL1WaIoaqIpuqIqKqLyqZ8MgAIIsAAtyqI2WqM46p83 uqM52qM8KqEYep8LIKMA0AA+eqQ/iqQIqqQ/mgBJ+qQ5+qL5GaMzWQ0jKgJMmqUrOgILqqVKiqUg 6qReeqNBmp+rqABQKQIIEAD0KQJtCgBv+p9uOqb9Cab4iaVzmqRgmqd3OgJiep98aqN2ap8lUKGB SqdQ6p9Sip8O8ACrmAAlsKZvWp97CgABOqiIiqZ26qdaOqeYOql/2qdH/nqon7qkpZqomfqmWOCc 99kAjoqlBwCpfhoAlAqnmhqnmuqpliqrutqreLqpnGqgJJCrluqrmoqmtQqsvqqqxKqfxsqrtkoC kwqnhZqs0Rqst9qn0zqssmqt06qq14qmqBqi/FmmriqXxLqm2vqrtVqrstqthLqrblqp29qu9wmg xeqn85qvF8qllZqtoLqv9lqu8lqvAUut/iqv/Pqun1qo9PqvAsuwCeuu3JqqECqlDjCfB0Cskcqm 1iqtHMuvfKqr2fqw1QqugIqrv/qu2uqut8qtJKurihqtcZqnJgCwMnuzpLqrfSqzL5uv2xqvw3qq Dzqg/Lmk9wqiQdoA/g6gAKjIqhtLAurKrLzqsvEKr/YasTFrq0ZLqHWKsMcar6IKr0OrsGTLs4Aq r+0KrM7KsxDLtQN7tf36r92qtWCLq3LbtRCKn13qoAOKsQfApm8JrQAgqS0LrAQLsCULtIvbrRe7 nys7slzrszUbrpTbr21auWKbtnIbsS3LuUW7tZW7uDiLtoo7rleaBaxanxtrB1QqtbS6uZKrr9e6 rGFLtyWQoKYrsd46qCBbsTDrtr6rr1lbqbQ7tsbbq3PLrhLLqc86vMeLuiX6sVXgnGbaACpguOQq vRa7o9xbokT7vQEaqtMLuao7n0WrABCQvR4rvu7bven7vg16qPKb/qllSp8LcJ3tC7/1i7r8+796 67fdK6X2aUAAfMCJ2r8IvLcCjKoEvMAKbKASgKoQXMEserRKe77wSZ2FW7gb/MEgHMIiPMLhKZ8R IAEe2qEScMIsvMIufMIp7KEvPMMtHMMaSsM4bMMMgMMtDMMdesM9nMM/vMNBHMQ6zMMzvKEqXMRJ PMRIXMNOzMRQHMNP7MJHLMVWHMVVfMVbPMQdap4TQAHMCSDOKQEeTMJonMZqvMZsnJ7yKcZtHMdy PMd0vMbyacZ1nMd6vMchPAEgLJ/YG51+7JyDjACFfMjPiciEnMiMvMiObMiNDMmPrMiSXMmUfMmR jMmTnMmcbMmd/uzJmxzKoDzKmkzKn1zKqHzKqrzJ8rm+fPzKsBzLsgzIZ1zI1RkA74nLsrzL3anL uczLynm+rjyde7CmxiyexQyduLzM3+nLzMyeyRyevqye0Wyd0+yd03zNzqnNrwzGcEzM4LzKoMzN 2/ycupzKhHzO2ozOpnzM0snOtizK8Byd14zJ9SzOE3DO7rzI9yzP+PzP/nzHZ0zPBK3LdYDN0mkH xnzQ3OnMx8zQBl3ODZ3QciDRD13RC73QBo3Ra8rRE23OHA3R2+zR2ZnNIx3RCt3N5/vNllzMzOzQ DS3S5fzMCI3S5vzQFq2d1ZzRM33TGG3SPS3NNx3UGU3O2OkH/u780kO9xwJNndf80im9nU/t0/s8 0Sit0Ept1E5N0T+N00SdzVit1fq71DQN1c2szB190GWt0quKAIEczlS9zqs81T2tz/7MzzhN1zyN ztOcz0P9zA4N04bMzSSdyrjsx4FN1SMNnZTM2CY91YI9z3fdzqbcygON1mi91h9N1jx91l9t0WIN 16DN2Z9N2jkt1Zyd2Eut05kd16udx7ScyXYN2CRd0imN1YuN0BLN0Emt24Uc1Y892j893H2N2iDt zF3N2/F8y5gt0ind2G1s2cA83dT9waEtx9582cfN29TJ1zv9zviM1Nwp2SfN3ZXM2I283II8nZQs 3uhtnep9/skAtNWP3N0ATdnxzchNXd383d/+/Z1vXMuR/N6jDJ6lTJ7srJ75nZ3QXd/X2eAFPuDb eeCfrMb7/d8YnuEa7pyxjZ3qbd+T/eHsfd8iDt8kLuEO7sgQTuAEvuIovt7gPdke/uAnHuL6Lcza veE6zp4UsOPq2eGU3eIvPt4VPp4Jnp4LPuMpft40vuQQXuLVSeGiPMKW3QAQYOVYfuVajuUSQAFd /uVeHuZgLgFcLuZl/uVZnuZbfuVjfuZe7uZkvuZqPudtzuZmbudojudi/uZrXucNMOZ7nudp7ueA XuhzvuWFzud/fueLnuiGLueIzuiELumULujZPcblUcY5/u7jnN7p2L3Sm+7poj7qInzhpH7qz/nW qP7j56vqNv7q+F3jsQ7rv53MpTxAKi7rtozHQp7WHk3ewK7rwr7I0r3q4CkHcl7bCd0N2LzR5MzS xDwHypnWxh6frS7g1V7Sh27lYo1tCVABxr3MDEDOvM7kuFy4DL0AvgzlIfzd7Vns1dkA6inv8Env 6BkAXhzDWq0IVBrVY13RcqDu1AntaI3uumwBzhkB163bvbwJH5zd1mnlA43IXH7X5R7skywBCNDl w76mOvzDdl3JiqChu3DXy7wIHr/uiRwBmw7wzskAzlkBFjDu9KzcAF3c/nxAyhzV82zq0Qnzri6d 6ysC/vZenQS/nmJc9NKc5UQ/9Ftu1Hzww45w1Gta8sq+8Tke0eXNAAzQAII9nguvzPjw2uAZ4Jnc 4wAQ6V1eyG/tylie6leO9W49no1+54UL80te0mtOAhqq5VAvAlS6obtQ4ifv8IctnSwfyb4M8wHA 9TMaAA1A86edzyGd3Cft61LtZodfzzJ90RHt887p5R5sAuW+5dMezPIu7yMgxjAf6ooen2Z8As6p 9NH5+sQc+V8MAH2P5X+v+yIwpCXP3FFU1Zoe7QYN/IULAY0P1lpf1cvc/L1d0kXWTtsN2Yqt0UAO nYI/8GeMvYA/+1qe9mfM8ZeNyGGuppR89M85zDCO/uVq2sgBsPcjoO+jfAevC/goD+PbrArUGaPE jO4ggAQIAJAiiqjrGLiu+rbsmtrItOZqHpT/61caxWqxV5FIRI2Ezic0Kp1KVRCTUcUwNSANCQUs wSKuqgWgQQKMG2RKOivfko3icDevUtfl1z6Ll1fJAh1D4cJSlo8QHRqAohwjZNCQHAKa5AmMCVZA ombk0kwRTellzWRQJaSpq1LKKAoVba1t1B7ZzoraGBQv1pYZAtzwhJmEDipgTdQYxAmOslHdrkie IDZ2ZKpQYQldwK51DFC55biWburmwglAIlE6KRONLM89+aITq+Xp6T0bM24RLDjFCrMVYBJa0QNg /kKYMFy8IHCzBxXGjGX4aOwYQFs2Qdy6ETp0yBxGVQxEoMySSZKFTSsZMPChSAYLGEdg3OTpKuMk SEKDBsyp8waSWQaXMsUBJ+OWSzuErKC6plNVOfqk8cDIkSuqdItCgkwhluWPk0JGkmyF1q2RCREY wpLRsqNWvHGVBR3yZOTWrVmYEi6oYoxGhnoXM5ajuHEAstnYsnBC564kICtVXUKMCoY7dy4wNy69 jxZl04VX11LxtCvsvbE1Bp4GtoZg22dx25aa06RIeZ+piNO9UwZysDvmGjeqkxHbs7ubK5eE/DqS 6bOps+5eBYFn0+LHkxd/HS/28+WzhGccwMDj/vXy51f1bt+qRdoZpefFW3s7gLf1J2BjudGHUVQG yraggr4VON9/jt03IUIHWnghhhlquCGHFk5IYUXrxBZhg71RF6GDC/IW4IoMmjjiNPzBOCOBLgao oIw15kjiiS/qWN+H3iEU0R1FEgmSNkXmYaQYSEr2BZFHesEkHmRRqeSUUTb5pJVaeinBlV+KieWS Y2qJJJlcomnmlU66qWabaWQTpH1OEXQVnW7QuSefffr5J6CBUnFYfBu+eaiaiSK6qKKN5nGonIxK 6iilk1pa6IGCGuQaphnWlB6ooYo6KqmlikqJqamquiqrrTbRITWa3glepxgmIiuuuer6C3rR/sCq wq605GJjdTTuqExNjSBi0jfBOvvsanhK0cCrPfJAgbE9QotLGbVeeOsPj1h22bblmotLfBBUq5cE qXV0Ln4i/qpFUOT+QIK48Opbrq+oUHvCBCUSA1dp+2IxjEdGuNvRBOAS8sMBBwzRj8EV59rvJepi jJEYJiy8zL4V9soOeQ0HJW7EE49mMcu4bpyFxp12fANjBtu5SCQ9KGxtsSsk+4MCER+gAAASl/CW X6yp0jLTVFVj278JjSPR0QhYIJwISRlnM604a0IyeQ4n0MADQidAVV9pA3HL0k03/bId66ICBxkx VfDvPxlx/Zo0sOCAU9Y+KXFUUlrTW4IC/g6UXUICQ9+r9lpr29K2235OYAFr0WC3AgXV7mZRBWCo EHpRRg0Wctck+11PEqvTQzMP4JIttNmP81PJKqPZlbRQSUPn1+9D+f7XyqiqDHzvya/1O3QUFxSw BQRccIEBBlwQLRnJKSS3HO4EHgDpYL8Sq77Dqg6QQALhRPhIyTqAQONE/wK58Ly3TXnwzA+fvxT0 D7V0X/hBCfs9zwLRo171Elg9DGAvFUfZA/eMYJFR1GRngUtfM1CHsO/5JAn2+ElOQliDWzXAAUE7 gAqCJj+PCRB5BOSd5HpnE+HNsIY0JN7K7KLDFvJwhi8cFAEwgEAFEjGB0hPiBZCoxOkt/hFzR+sD N2KGEWj0ZBHsKB3X8vMPenARg0gRHwKS1YADBKBxQlshCyPnwuRRLob6s6ENkUc/HyqPjjB0Ixtj OIUJILGIfkyiEDEQRABcIIhHDOQRnYiVH0WNRmq4SYtkgUUN1gGS3zsOUp6jyZyBS2Iy0JPt1Fi/ PA7vh/jD4wsBqEc70jF4o2xjLS53QD9abynweaJGpIgK0aCncA8EVsgg4q0UNeZnRbMX2no4sWXu ToarRCUpo7k7Ha4ClarI4fKKx5TLSQ+B1zPILReZhV00EhWHWIJ2GCYtcxEKKNqjj8PgkZKlBBCa lYOCD9a5TUUWJJwbg4YOdPmZCs5n/m/ywpGPjnU4IJzKIPX84T0Zygh9asqfWJhOOadjuAHliGvt mVfsHhrRkdLJn4yKIIcMpgYtYiRHLcKLMUkq0z2FM1VwS1E6McK1DYL0DD39KVCDWgMDqKanWTyo j1rEo9jMtKl8CuemepZTjtrGqVa9KtOgitWtcrWrNPUqWMMqVsJodaxmPStay4rWtbJ1q2ptK1zj GtG3yrWudjUYXe+q1706K698/StgAeXXwBK2sPcZrGETq1hwLraxjiXrYyMrWVogdrKWTWxlL6vZ PvGzZZl1QmctCz0Dkra0pj0talOr2tWytrWufS1sYyvb2dK2tra9LWoDNtYJHDGI/qXFAGkJENzh GlC4xSVu9JBr3OQet7nMfe5yo6vc6TpXutWlLnOtC13sare73P3udQGw3euSd7zm9S55gyhEC0yg q3wEbns3K1/WXM4AGIivVdc73/3aJ3oMbOoECsnfAXuHm/iNKAaAS+AFd8cC3xzpBULL4AkXxMEH blqEKaxhwljgv27r8IZDvBQFN42PFxYxivf44JaBOMUupgWJW3bfF9NYCgFmGh+7gxxcufIvqJks LcOpwBIM2VkrrliOlSZK74hUj1FoMj19DNfqCYHKRIaqlY18Yn21eDX+UzJxfnyfAEIZrFaGT5YB kOXPUiHNBolxxQyo4x5qc23a/mSF83Bnv+LBUnL4y+GdsSnH2wUwgWqmsqETjehFo5nRUCjyld0M 6UP/wM2UfiukFV3pRBdGuCyWsENb2GdBn1KZ/CulSF2p6jtKc4ClrvItzxzrWV+51pS+NaxtLetN 2/rQhn60pXUt5CKfmTVdjjOoCwK5UfvZnnc8deSavGrlsZoozmy1ExytZl7/eti+JnKbyxrsNdMa 2ObmNa6FvRo4G+zYhFm2k0n5aidDW6JTmLbxqh3tUqKqzpf+d60bve2AAxzYaZ60r73d60qne+G7 znXDR/zpOauR2fy2eLOpfW18QpTfz4Q2lNFc8G0LHMskF/kTHv7wW5Mb3Qxf/ni6V77pYBeE3fuS M5hNeW+dm/riHhd1xjdOb4ZiO9sKd7mkj85yIau76bhGtMNpvXJJ38fdN082QXacTY7vmShkJrW9 U0lnPpP9dqK0Y75TrvSna7Xl6PZjwrsdZLlHetaLjvvMyY3wN2O9XFY/65dzXubHFrEwf4cXztsa eC/H+7JtL4zNudx3s/q7MHceMBFXc/hzJb7GnhdC5BHv4c+TfvPm6jzpPR96zk8+9Rs2vd+xPvgw 89A+s8/67ZUNr9yzjdW+F9TqTz/6IJH5Q7wXM52Oz6ce2572ljf88K/ep+JPSPk75zrjt8V8Jjv/ 3ZBv/bNQD/TKU0x3RNdf/tqPp/5oe93aX2/eHMMu7zoOcI16TmWgVYnD/xHazg+9/zXh29YBD/zJ H9oJAexti/hVHPOVGqk1D8+9ktlt3DVJmdCJnc/VH9HJ0Cl1YNBB4JMtE7YJ2tldm/7V0/2AnJ81 WfD5XfRVXOPx3P1A0+J1XDSVoMZJYAZSn9DNYBzx4PbBoAzG2wk+Ww7OXwZe4BMkILQs4AfikAN+ YDOlXZ65EZ5hXxC20hNq3Axa0w2tn9ZJmylNExECHbU5j8qQoKqR4RS0oALKXse92rT1We2d4Rbm YBcKUBT+HBISkPkd4PaJYdE5mx1eYBZaoAD+3g+4YRMSwPXBEgj2Ib55/qARohod5mHt5WEgBl3R 7aESCuEIlqELrdoh7qAX7hH4OUuSheANMlM2BWCPlR/ZvZ/XtaIBsqL89Vu1XeEAQlQ/8OKzaeEt +h4Aht0l8tkKDqMUXMCW6cuRJZb1lUs0chWbBcuMNdY0Qks2XtWNMQ0T2lXlud73uQ0ziuOLdWPT fKM57lc5Vk6GrWOIqeO5MCI8XlYQNSPLBFgq1uNjOVhTJRE/8td74eOHvWNAXlaHOSI3rhdBHiRg 8VESNeRIXc70AIAggdd5YSR6ZWR5baRHaiR1fWRHguRIliRHnqRIouR3BdH0RJhEApgsddhxGRdw JRdNzqQB1aRw3aRNT+YkTspkTwLlTvpkUOokcxklTw6lUB7lTyJlaSmlUy5lUjJlUTalVVYlVkLl VWplVlIlV37lc7GXQ44lWZalWZ4lWqalWq4lW7alW4ZVCAAAOw== ------=_NextPart_E77_8F81_3EAECB9A.A19E4376-- From franswpub@vintegrasystem.com Wed Jan 24 16:34:19 2007 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9pl5-0003o9-UE for ips-archive@lists.ietf.org; Wed, 24 Jan 2007 16:34:19 -0500 Received: from [88.226.69.172] (helo=dsl88-226-17836.ttnet.net.tr) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H9pl2-0000mX-W1 for ips-archive@lists.ietf.org; Wed, 24 Jan 2007 16:34:19 -0500 Reply-To: "Margo Thomson" From: "Margo" Message-ID: <4852635556.20070124153548@aizdcs> Date: Wed, 24 Jan 2007 15:35:48 -0600 To: Subject: Adobe Acrobat 8.0 ready to download MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Spam-Score: 1.7 (+) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Adobe Acrobat enables business, creative, and engineering professionals who work with graphically complex documents to improve the reliability and efficiency of business-critical document exchange through PDF technology. Adobe Acrobat 8.0 Professional has the following features in addition to the features found in the standard version: Create PDF documents with one-button ease from AutoCAD, Microsoft Visio, and Microsoft Project (Windows only); Preserve document layers in technical drawings in Visio and AutoCAD, and object data in Visio (Windows only); Permanently delete sensitive information, including specific text or illustrations, with redaction tools; Create fillable PDF forms from scanned paper, existing PDF documents, Microsoft Word documents, or Excel spreadsheets; Automatically recognize form fields on static PDF documents and convert them to interactive fields that can be filled electronically by anyone using free Adobe Reader versions 7 or 8; Enable Adobe Reader (versions 7 or 8) users to participate in reviews with complete commenting and markup tools, including sticky notes, highlighter, lines, shapes, and stamps; Enable Adobe Reader (versions 7 or 8) users to fill and save PDF forms locally for offline use, and to digitally sign PDF documents. Adobe Acrobat 8.0 Professional Retail Price $449.00 Our Price $79.95 You save $369.05 http://onorabout.org Please note, that there will be more special offers available for our constant customers. Every effort has been made to ensure the accuracy of all information contained herein. DS Team makes no warranty expressed or implied with respect to accuracy of the information, including price, product editorials or product specifications. Product and manufacturer names are used only for the purpose of identification. We appreciate your cooperation with us and we'll be glad to see you as our clients in the future. From ips-bounces@ietf.org Wed Jan 24 20:35:19 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9tVr-00083w-OW; Wed, 24 Jan 2007 20:34:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9tVq-00083k-5j for ips@ietf.org; Wed, 24 Jan 2007 20:34:50 -0500 Received: from mexforward.lss.emc.com ([128.222.32.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9tVp-0005Jy-O5 for ips@ietf.org; Wed, 24 Jan 2007 20:34:50 -0500 Received: from mailhub.lss.emc.com (nagas.lss.emc.com [10.254.144.11]) by mexforward.lss.emc.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id l0P1YluB021510 for ; Wed, 24 Jan 2007 20:34:47 -0500 (EST) Received: from corpussmtp3.corp.emc.com (corpussmtp3.corp.emc.com [10.254.64.53]) by mailhub.lss.emc.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id l0P1Yg1X025833 for ; Wed, 24 Jan 2007 20:34:45 -0500 (EST) From: Black_David@emc.com Received: from CORPUSMX20A.corp.emc.com ([128.221.62.13]) by corpussmtp3.corp.emc.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 24 Jan 2007 20:34:42 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: [Ips] iSCSI Implementer's Guide - WG Last Call status, 2nd try Date: Wed, 24 Jan 2007 20:34:41 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ips] iSCSI Implementer's Guide - WG Last Call status, 2nd try Thread-Index: AccqvpOM97n0qzgHQzqxpVYCuljEaQVWkyjQ To: X-OriginalArrivalTime: 25 Jan 2007 01:34:42.0433 (UTC) FILETIME=[FC987710:01C74020] X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.5.0.283055, Antispam-Data: 2007.1.24.171432 X-PerlMx-Spam: Gauge=, SPAM=0%, Reason='EMC_BODY_1+ -3, EMC_FROM_0+ -2, NO_REAL_NAME 0, __C230066_P5 0, __CT 0, __CTE 0, __CTYPE_CHARSET_QUOTED 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __IMS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.3 (/) X-Scan-Signature: d2b46e3b2dfbff2088e0b72a54104985 Cc: Black_David@emc.com X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ips-bounces@ietf.org Your WG chair has resurfaced and apologizes for being incommunicado these past few weeks (took a badly needed vacation for a couple of weeks, including from email, and have been digging out ever since). In the time since my previous WG Last Call status message, three things appear to have happened: a) Issue (2) has been resolved on the list with new text in the -04 version of the draft. I thank everyone involved. b) There was some discussion of behavior of task management functions that affect more than one initiator when not all the initiators have the TaskReporting key set to FastAbort. c) There was some discussion of the Response Fence. --- b) Task management when not all initiators use FastAbort. I believe the rough consensus of the WG is that FastAbort can only be used on a session that has negotiated its use (i.e., the new TaskReporting key was negotiated to FastAbort). This has a couple of implications: b1) This means that if the session that sent the TMF uses FastAbort but some other affected iSCSI session doesn't, FastAbort MUST NOT be used with that other affected session. b2) In the reverse direction, if the session that sent the TMF does not use FastAbort, but some other affected session does, FastAbort could be used with that other affected session. Each of these raises an issue: o This text in Section 4.1.3 on target behavior violates b1): d. MUST generate an Asynchronous Message PDU with AsyncEvent=3D5=20 (section 8.1) on:=20 i) each connection of each third-party session to which at=20 least one affected task is allegiant, and=20 --> The target has to first check whether the third-party session uses FastAbort, otherwise the AsyncEvent=3D5 message will be rather unexpected (e.g., by a 3720-only initiator). This text needs to be corrected. o The text in Section 4.1.2 currently prohibits FastAbort on third party sessions when FastAbort is not used on the session that sent the TMF (i.e., the "could" in b2 above is a "MUST NOT" with the current text). --> Any requirement option (MUST/SHOULD/MAY/MUST NOT/SHOULD NOT) appears to work here, but we need to consciously make a decision. I lean towards "SHOULD" instead of "MUST NOT". Keep in mind that this is for a session for which usage of FastAbort has been negotiated. Any change from the current "MUST NOT" will entail a fair amount of editing work. --- c) The Response Fence I believe that the WG rough consensus of the discussion about the Response Fence functionality is that the functionality is needed to deal with the ordering issues in the cases called out in Section 3.3.3 of the -04 version of the draft (note that the Initiator MUST negotiate TaskReporting=3DResponseFence or TaskReporting=3DFastAbort before relying on response fence behavior). Unfortunately, I have to object to Section 3.3.1, which appears to be trying to modify SAM-2 to add the Response Fence flag. That can't be done in IETF, and any T10 modification would be to SAM-4, whereas iSCSI is still based on SAM-2. I think the mention of SAM-2 and model of the interface between SCSI and a SCSI transport needs to be removed from Section 3.3.1. The items numbered (1) and (2) in that section look ok (and in fact useful to keep) - the problematic text is that which suggests the existence of a "Response Fence flag" in the abstract interface between SCSI and the SCSI transport (e.g., iSCSI) along with the mention of "SCSI protocol interface model" in Section 3.3. The upshot will be that Response Fence behavior will be specified in a fashion that makes it only applicable to the cases spelled out in Section 3.3.3. ------------------ So, I think we need further list discussion of the b) and c) issues, including what the b2) requirement level should be. I will monitor this discussion on at least a daily basis in the hope of driving it to a relatively prompt conclusion, and I will carefully read the -04 version of the draft in the interim to see if I turn up anything else that may need attention. Thanks, --David ---------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- -----Original Message----- From: Black_David@emc.com [mailto:Black_David@emc.com]=20 Sent: Thursday, December 28, 2006 3:27 PM To: ips@ietf.org Subject: [Ips] iSCSI Implementer's Guide - WG Last Call status The Working Group Last Call on this draft nominally ended on December 18th, but there was no reason to treat that as a hard cutoff. I am now ending the WG Last Call on this draft, although list discussion of issues should be continued. There have been two issues raised during this WGLC: (1) Task Management - how to deal with uncooperative third- party initiators. This issue has been resolved on the list. (2) Target checks - whether to discourage targets from checking for initiator mistakes that the target can tolerate. At the moment, I think the "rough consensus" of the WG is not to do this - if anyone other than Eddy thinks this is important to clarify, they need to speak up promptly after the holidays. The process from here is that Mallikarjun will submit a revised version of the draft in the near future (there are still some details to be worked out on the list). I will be completely out of action (no email) the first two weeks of January, so there will be time for people to check for problems/issues/etc. I will check the revised draft and send it to Lars with a request for RFC publication sometime in the second half of January (probably during the week of January 22nd). Thanks, --David ---------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Thu Jan 25 15:09:12 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAAtx-0003Qz-Df; Thu, 25 Jan 2007 15:08:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAAtw-0003Qo-1u for ips@ietf.org; Thu, 25 Jan 2007 15:08:52 -0500 Received: from mexforward.lss.emc.com ([128.222.32.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HAAtr-0002xS-JO for ips@ietf.org; Thu, 25 Jan 2007 15:08:52 -0500 Received: from mailhub.lss.emc.com (nagas.lss.emc.com [10.254.144.11]) by mexforward.lss.emc.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id l0PK8llu006385 for ; Thu, 25 Jan 2007 15:08:47 -0500 (EST) Received: from corpussmtp4.corp.emc.com (corpussmtp4.corp.emc.com [10.254.64.54]) by mailhub.lss.emc.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id l0PK8BJG013741 for ; Thu, 25 Jan 2007 15:08:46 -0500 (EST) From: Black_David@emc.com Received: from CORPUSMX20A.corp.emc.com ([128.221.62.13]) by corpussmtp4.corp.emc.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 25 Jan 2007 15:08:25 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Thu, 25 Jan 2007 15:08:24 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IESG has approved the iSER and DA drafts Thread-Index: AcdAvJGrjsDg1Da2QTukyEuQC/aSJg== To: X-OriginalArrivalTime: 25 Jan 2007 20:08:25.0111 (UTC) FILETIME=[9203F270:01C740BC] X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.5.0.283055, Antispam-Data: 2007.1.25.113932 X-PerlMx-Spam: Gauge=, SPAM=0%, Reason='EMC_BODY_1+ -3, EMC_FROM_0+ -2, NO_REAL_NAME 0, __C230066_P5 0, __CT 0, __CTE 0, __CTYPE_CHARSET_QUOTED 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __IMS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.2 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Subject: [Ips] IESG has approved the iSER and DA drafts X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ips-bounces@ietf.org It's my pleasure to convey the information that the IESG has approved the iSER (iSCSI Extensions for RDMA) and DA (Datamover Architecture) drafts for publication as RFCs. The official announcement should appear in the near future. By comparison to some of the other drafts I've worked on, these had a relatively uneventful IESG review, and that's indicative of all the hard work that was put into them by their authors - well done! During IESG review, one of the AD's commented that the separation of the DA architecture from its iSER realization was a good example of an approach that ought to be followed elsewhere in the IETF. So congratulations and thanks to everyone who contributed, --David (ips WG chair) ---------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Thu Jan 25 16:08:25 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HABpM-0002Yj-BB; Thu, 25 Jan 2007 16:08:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HABpL-0002Ye-M4 for ips@ietf.org; Thu, 25 Jan 2007 16:08:11 -0500 Received: from wr-out-0506.google.com ([64.233.184.237]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HABpK-0001wu-Fi for ips@ietf.org; Thu, 25 Jan 2007 16:08:11 -0500 Received: by wr-out-0506.google.com with SMTP id 69so563643wra for ; Thu, 25 Jan 2007 13:08:10 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type; b=RpedSaYaDxkC9ZRWnIDYNMCCph/Utlg1RWEn6WWLRENGvXjId5XyOBqI8TvyhZByc/xy1wz2xO5IvWbrzhNxJf3eM2NND7tjHWdhlbSQA+zqGtsSy/jO9dJWE63ZB5CMhTzKkFJUuf4K2OoNUIKHkdnPDZ8eCVQCJ4tCcX2iIqQ= Received: by 10.90.98.10 with SMTP id v10mr2925209agb.1169759290055; Thu, 25 Jan 2007 13:08:10 -0800 (PST) Received: by 10.90.79.4 with HTTP; Thu, 25 Jan 2007 13:08:09 -0800 (PST) Message-ID: <4f179b220701251308n21ded621w385d8bfcf3d76297@mail.gmail.com> Date: Thu, 25 Jan 2007 13:08:09 -0800 From: "Barada Mishra" To: ips@ietf.org MIME-Version: 1.0 X-Spam-Score: 0.3 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Subject: [Ips] iscsi: More immediate data than required data X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2061746933==" Errors-To: ips-bounces@ietf.org --===============2061746933== Content-Type: multipart/alternative; boundary="----=_Part_28924_19978012.1169759289880" ------=_Part_28924_19978012.1169759289880 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi, This question is from a iSCSI target point of view. When a target receives more immediate data than the required data, what should be the behavior? Example : Assume the target receives a write command for 2 blocks (1024 bytes). But the associated immediate data it receives is 2048. What should the target do 1. Use only 1024 bytes, ignore the rest of data and return good status 2. Return check condition (what should be the ASC/ASCQ)? 3. Drop the connection and/or session 4. Reject the PDU Or something else? Thanks Barada ------=_Part_28924_19978012.1169759289880 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi,

This question is from a iSCSI target point of view.

When a target receives more immediate data than the required data, what should be the behavior?

Example :
Assume the target receives a write command for 2 blocks (1024 bytes).
But the associated immediate data it receives is 2048.

What should the target do
  1. Use only 1024 bytes, ignore the rest of data and return good status
  2. Return check condition (what should be the ASC/ASCQ)?
  3. Drop the connection and/or session
  4. Reject the PDU
Or something else?

Thanks
Barada

------=_Part_28924_19978012.1169759289880-- --===============2061746933== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============2061746933==-- From ips-bounces@ietf.org Thu Jan 25 21:04:47 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAGRm-0005SJ-KY; Thu, 25 Jan 2007 21:04:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAGRl-0005SD-C3 for ips@ietf.org; Thu, 25 Jan 2007 21:04:09 -0500 Received: from web51901.mail.yahoo.com ([206.190.48.64]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HAGRj-0007je-TI for ips@ietf.org; Thu, 25 Jan 2007 21:04:09 -0500 Received: (qmail 89459 invoked by uid 60001); 26 Jan 2007 02:04:07 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=nKWliMIceoSZkpi4avmMmgtVMhBrMY/rNizKwsSEJg3pxrSnhyA+Zc70MXAV84ZZdmC3awC96uGVFamOa8Ql6WSTTFIu1Wnt7fj+onSTY10lD9GjUw/9AzrS5xKNk/eqinScvx4XMorzVEfWC4hnRK1Js2DjiWXx+fTsgEJ8hLA=; X-YMail-OSG: NVmvBdoVM1lVlraOU_TqWZevWesplcyziXxUoYFM03dqCtREWqPoOG1sS8SnaATaC7ycQXYAJ2XuRU2H.Xx3hNmrx8foOUwjqCtEXAbDN5DWIfN.o.q_EvOfWLDOuTnb9ISAn72xthygpBq5FA88eYNv Received: from [15.235.153.106] by web51901.mail.yahoo.com via HTTP; Thu, 25 Jan 2007 18:04:07 PST X-Mailer: YahooMailRC/368.3 YahooMailWebService/0.6.132.7 Date: Thu, 25 Jan 2007 18:04:07 -0800 (PST) From: "Mallikarjun C." Subject: Last Call TMF resolution (Was Re: [Ips] iSCSI Implementer's Guide - WG Last Call status, 2nd try) To: ips@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Message-ID: <418092.89223.qm@web51901.mail.yahoo.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ips-bounces@ietf.org David,=0A=0AWelcome back.=0A=0ALet me respond to your note under two separa= te covers.=0A=0ARegarding b1, good catch! I fixed the text as below:=0A=0A= d. MUST generate an Asynchronous Message PDU with AsyncEvent=3D5 (section 8= .1) on:=0Ai) each connection of each third-party session to which at least = one affected task is allegiant if TaskReporting=3DFastAbort is operational = on that third-party session,=0A=0A=0ARegarding b2, I agree with you that it= should be at least a SHOULD, if not a MUST (since FastAbort was already ne= gotiated on that session). However, I do not see which specific text in 4.= 1.2 you believe is implying a MUST NOT. Need more help here. Just to be c= lear, I now added the following to initiator behavior in 4.1.3:=0A=0Ac. MUS= T respond to each Async Message PDU with AsyncEvent=3D5 as defined in secti= on 8.1 (this step also applies when the initiator is receiving the Async Me= ssage in the third-party role).=0A=0A=0AMallikarjun=0A=0A=0A=0A=0A----- Ori= ginal Message ----=0AFrom: "Black_David@emc.com" =0ATo= : ips@ietf.org=0ACc: Black_David@emc.com=0ASent: Wednesday, January 24, 200= 7 5:34:41 PM=0ASubject: [Ips] iSCSI Implementer's Guide - WG Last Call stat= us, 2nd try=0A=0A=0AYour WG chair has resurfaced and apologizes for being= =0Aincommunicado these past few weeks (took a badly needed=0Avacation for a= couple of weeks, including from email,=0Aand have been digging out ever si= nce). In the time since=0Amy previous WG Last Call status message, three t= hings=0Aappear to have happened:=0A=0Aa) Issue (2) has been resolved on the= list with new text=0A in the -04 version of the draft. I thank everyon= e=0A involved.=0Ab) There was some discussion of behavior of task manage= ment=0A functions that affect more than one initiator when=0A not all= the initiators have the TaskReporting key=0A set to FastAbort.=0Ac) The= re was some discussion of the Response Fence.=0A=0A--- b) Task management w= hen not all initiators use FastAbort.=0A=0AI believe the rough consensus of= the WG is that FastAbort=0Acan only be used on a session that has negotiat= ed its use=0A(i.e., the new TaskReporting key was negotiated to FastAbort).= =0AThis has a couple of implications:=0A=0Ab1) This means that if the sessi= on that sent the TMF uses=0AFastAbort but some other affected iSCSI session= doesn't,=0AFastAbort MUST NOT be used with that other affected session.=0A= =0Ab2) In the reverse direction, if the session that sent the TMF=0Adoes no= t use FastAbort, but some other affected session does,=0AFastAbort could be= used with that other affected session.=0A=0AEach of these raises an issue:= =0Ao This text in Section 4.1.3 on target behavior violates b1):=0A=0A = d. MUST generate an Asynchronous Message PDU with AsyncEvent=3D5 =0A = (section 8.1) on: =0A i) each connection of each third-party s= ession to which at =0A least one affected task is allegiant, and= =0A=0A--> The target has to first check whether the third-party session=0A= uses FastAbort, otherwise the AsyncEvent=3D5 message will be=0A rath= er unexpected (e.g., by a 3720-only initiator). This=0A text needs to b= e corrected.=0A=0Ao The text in Section 4.1.2 currently prohibits FastAbort= on=0A third party sessions when FastAbort is not used on the=0A sess= ion that sent the TMF (i.e., the "could" in b2 above=0A is a "MUST NOT" = with the current text).=0A=0A--> Any requirement option (MUST/SHOULD/MAY/MU= ST NOT/SHOULD NOT)=0A appears to work here, but we need to consciously m= ake a=0A decision. I lean towards "SHOULD" instead of "MUST NOT".=0A = Keep in mind that this is for a session for which usage=0A of FastAbort= has been negotiated. Any change from the=0A current "MUST NOT" will en= tail a fair amount of editing=0A work.=0A=0A--- c) The Response Fence=0A= =0AI believe that the WG rough consensus of the discussion about=0Athe Resp= onse Fence functionality is that the functionality is=0Aneeded to deal with= the ordering issues in the cases called=0Aout in Section 3.3.3 of the -04 = version of the draft (note=0Athat the Initiator MUST negotiate TaskReportin= g=3DResponseFence=0Aor TaskReporting=3DFastAbort before relying on response= fence=0Abehavior).=0A=0AUnfortunately, I have to object to Section 3.3.1, = which appears=0Ato be trying to modify SAM-2 to add the Response Fence flag= .=0AThat can't be done in IETF, and any T10 modification would be=0Ato SAM-= 4, whereas iSCSI is still based on SAM-2. I think the=0Amention of SAM-2 a= nd model of the interface between SCSI and=0Aa SCSI transport needs to be r= emoved from Section 3.3.1. The=0Aitems numbered (1) and (2) in that sectio= n look ok (and in=0Afact useful to keep) - the problematic text is that whi= ch=0Asuggests the existence of a "Response Fence flag" in the=0Aabstract in= terface between SCSI and the SCSI transport (e.g.,=0AiSCSI) along with the = mention of "SCSI protocol interface=0Amodel" in Section 3.3. The upshot wi= ll be that Response=0AFence behavior will be specified in a fashion that ma= kes it=0Aonly applicable to the cases spelled out in Section 3.3.3.=0A=0A--= ----------------=0A=0ASo, I think we need further list discussion of the b)= and c)=0Aissues, including what the b2) requirement level should be.=0A=0A= I will monitor this discussion on at least a daily basis in=0Athe hope of d= riving it to a relatively prompt conclusion, and=0AI will carefully read th= e -04 version of the draft in the=0Ainterim to see if I turn up anything el= se that may need=0Aattention.=0A=0AThanks,=0A--David=0A--------------------= --------------------------------=0ADavid L. Black, Senior Technologist=0AEM= C Corporation, 176 South St., Hopkinton, MA 01748=0A+1 (508) 293-7953 = FAX: +1 (508) 293-7786=0Ablack_david@emc.com Mobile: +1 (978= ) 394-7754=0A----------------------------------------------------=0A=0A----= -Original Message-----=0AFrom: Black_David@emc.com [mailto:Black_David@emc.= com] =0ASent: Thursday, December 28, 2006 3:27 PM=0ATo: ips@ietf.org=0ASubj= ect: [Ips] iSCSI Implementer's Guide - WG Last Call status=0A=0AThe Working= Group Last Call on this draft nominally ended on=0ADecember 18th, but ther= e was no reason to treat that as a hard=0Acutoff. I am now ending the WG L= ast Call on this draft, although=0Alist discussion of issues should be cont= inued.=0A=0AThere have been two issues raised during this WGLC:=0A(1) Task = Management - how to deal with uncooperative third-=0A party initiators. = This issue has been resolved=0A on the list.=0A(2) Target checks - whet= her to discourage targets from=0A checking for initiator mistakes that t= he target can=0A tolerate. At the moment, I think the "rough consensus"= =0A of the WG is not to do this - if anyone other than=0A Eddy thinks= this is important to clarify, they need=0A to speak up promptly after t= he holidays.=0A=0AThe process from here is that Mallikarjun will submit a= =0Arevised version of the draft in the near future (there are=0Astill some = details to be worked out on the list). I will=0Abe completely out of actio= n (no email) the first two weeks=0Aof January, so there will be time for pe= ople to check for=0Aproblems/issues/etc. I will check the revised draft an= d=0Asend it to Lars with a request for RFC publication sometime=0Ain the se= cond half of January (probably during the week of=0AJanuary 22nd).=0A=0ATha= nks,=0A--David=0A=0A----------------------------------------------------=0A= David L. Black, Senior Technologist=0AEMC Corporation, 176 South St., Hopki= nton, MA 01748=0A+1 (508) 293-7953 FAX: +1 (508) 293-7786=0Abl= ack_david@emc.com Mobile: +1 (978) 394-7754=0A----------------------= ------------------------------=0A=0A=0A____________________________________= ___________=0AIps mailing list=0AIps@ietf.org=0Ahttps://www1.ietf.org/mailm= an/listinfo/ips=0A=0A=0A_______________________________________________=0AI= ps mailing list=0AIps@ietf.org=0Ahttps://www1.ietf.org/mailman/listinfo/ips= =0A=0A=0A =0A______________________________________________________________= ______________________=0A8:00? 8:25? 8:40? Find a flick in no time =0Awith = the Yahoo! Search movie showtime shortcut.=0Ahttp://tools.search.yahoo.com/= shortcuts/#news _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Thu Jan 25 21:18:22 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAGfN-0003Qv-Ba; Thu, 25 Jan 2007 21:18:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAGfJ-0003Qf-Vr for ips@ietf.org; Thu, 25 Jan 2007 21:18:11 -0500 Received: from web51902.mail.yahoo.com ([206.190.48.65]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HAGfI-0001aN-IJ for ips@ietf.org; Thu, 25 Jan 2007 21:18:09 -0500 Received: (qmail 16679 invoked by uid 60001); 26 Jan 2007 02:18:08 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=smNx6uXeO5TrKxXsoxSToRhv+SKsqhoBbYLBEhDo2Gn7BW8DY+6lWMpq6ZfTx0X5r3KtgDwzw3jUOcroGruhjYv9Fa2xuJ6+iCZHCWCxdwZCMvP0oSRbDy7Lq4lDZzPI5lRCxYmEJJ0kLk3Hc65VzXEb0GATJk8fLYL82NQEBQ4=; X-YMail-OSG: s_9pbbcVM1lYDasjp2VsiDFNFHxQoLzgj4MAo22GUUY3N85WSe4jURanSgEKEOmP2w-- Received: from [15.227.217.75] by web51902.mail.yahoo.com via HTTP; Thu, 25 Jan 2007 18:18:07 PST X-Mailer: YahooMailRC/368.3 YahooMailWebService/0.6.132.7 Date: Thu, 25 Jan 2007 18:18:07 -0800 (PST) From: "Mallikarjun C." Subject: Last Call Response Fence resolution (Was Re: [Ips] iSCSI Implementer's Guide - WG Last Call status, 2nd try) To: ips@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Message-ID: <538695.15782.qm@web51902.mail.yahoo.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ips-bounces@ietf.org David, =0A=0AI understand your feedback on section 3.3.1. I have made a ha= ndful of changes to the text, new text is attached below for your review.= =0A=0AI am trying to preserve the notion of an iSCSI-defined & iSCSI-scoped= Response Fence in the text (you seem to be OK with it). This gives us a c= onvenient shorthand to refer to a set of semantics. Besides, if/when T10 a= pproves the response fence concept for SAM-4, iSCSI implementers will know = what to map it to for iSCSI. As you'll see, I made it very clear in the ne= w text that this is not an attempt to change SAM in this draft (which was o= f course never the intent).=0A=0AMallikarjun=0A=0A----- Original Message --= --=0AFrom: "Black_David@emc.com" =0ATo: ips@ietf.org= =0ACc: Black_David@emc.com=0ASent: Wednesday, January 24, 2007 5:34:41 PM= =0ASubject: [Ips] iSCSI Implementer's Guide - WG Last Call status, 2nd try= =0A.......=0A=0A--- c) The Response Fence=0A=0A......=0A=0AUnfortunately, I= have to object to Section 3.3.1, which appears=0Ato be trying to modify SA= M-2 to add the Response Fence flag.=0AThat can't be done in IETF, and any T= 10 modification would be=0Ato SAM-4, whereas iSCSI is still based on SAM-2.= I think the=0Amention of SAM-2 and model of the interface between SCSI an= d=0Aa SCSI transport needs to be removed from Section 3.3.1. The=0Aitems n= umbered (1) and (2) in that section look ok (and in=0Afact useful to keep) = - the problematic text is that which=0Asuggests the existence of a "Respons= e Fence flag" in the=0Aabstract interface between SCSI and the SCSI transpo= rt (e.g.,=0AiSCSI) along with the mention of "SCSI protocol interface=0Amod= el" in Section 3.3. The upshot will be that Response=0AFence behavior will= be specified in a fashion that makes it=0Aonly applicable to the cases spe= lled out in Section 3.3.3.=0A=0A...........=0A=0A=0A=0A3.3 Model Assumption= s for Response Ordering=0AWhenever an iSCSI session is composed of multiple= connections, the Response PDUs (task responses or TMF responses) originati= ng in the target SCSI layer are distributed onto the multiple connections b= y the target iSCSI layer according to iSCSI connection allegiance rules. T= his process generally may not preserve the ordering of the responses by the= time they are delivered to the initiator SCSI layer. Since ordering is no= t expected across SCSI responses anyway, this approach works fine in the ge= neral case. However to address the special cases where some ordering is de= sired by the SCSI layer, the following semantics are defined for a "Respons= e Fence" flag if such a flag were to qualify SCSI completion messages as th= ey are handed off from the SCSI protocol layer to the iSCSI layer. Note ho= wever that [SAM2] does not model such a flag in its protocol interface mode= l, so the "Response Fence" flag is an iSCSI-defined artifact for descriptiv= e convenience of the mandatory iSCSI response ordering semantics. =0A=0A3.= 3.1 Model Description=0ATarget SCSI protocol layer hands off the SCSI compl= etion messages to the target iSCSI layer by invoking the "Send Command Comp= lete" protocol data service ([SAM2], clause 5.4.2) and "Task Management Fun= ction Executed" ([SAM2], clause 6.9) service. On receiving the SCSI compl= etion message, iSCSI layer assumes that a Response Fence flag optionally qu= alifies the SCSI completion message (section 3.3.3 describes the specific i= nstances where the flag qualifies the completion message). Whenever the Re= sponse Fence flag is present, the target iSCSI layer MUST ensure that the f= ollowing conditions are met in delivering the response message to the initi= ator iSCSI layer:=0A(1) Response with Response Fence MUST chronologically b= e delivered after all the "preceding" responses on the I_T_L nexus, if the = preceding responses are delivered at all, to the application client on the = initiator. =0A(2) Response with Response Fence MUST chronologically be deli= vered prior to all the "following" responses on the I_T_L nexus. =0AThe =93= preceding=94 and =93following=94 notions refer to the order of hand-off of = a response message from the target SCSI protocol layer to the target iSCSI = layer.=0A=0A3.3.2 iSCSI Semantics with the Interface Model=0AWhenever the T= askReporting key (section 9.1) is negotiated to ResponseFence or FastAbort = for an iSCSI session, the target iSCSI layer MUST perform the actions descr= ibed in this section on all tasks related to that session. A target iSCSI = layer MUST do the following whenever Response Fence flag qualifies a SCSI c= ompletion message handed down from the target SCSI layer:=0Aa) If it is a s= ingle-connection session, no special processing is required. Standard SCSI= Response PDU build process happens. =0Ab) If it is a multi-connection sess= ion, target iSCSI layer takes note of last-sent and unacknowledged StatSN o= n each of the connections in the iSCSI session, and waits for acknowledgeme= nt (SHOULD solicit for acknowledgement by way of a Nop-In) of each such Sta= tSN to clear the fence. SCSI response with the Response Fence flag must be= sent to the initiator only after receiving acknowledgements for each of th= e unacknowledged StatSNs.=0Ac) Target iSCSI layer must wait for an acknowle= dgement of the SCSI Response PDU that carried the response which the target= SCSI layer marked with the Response Fence flag. The fence must be conside= red cleared after receiving the acknowledgement.=0Ad) All further status pr= ocessing for the LU is resumed only after clearing the fence. If any new r= esponses for the I_T_L nexus are received from the SCSI layer before the fe= nce is cleared, those Response PDUs must be held and queued at the iSCSI la= yer until the fence is cleared.=0A=0A3.3.3 Current List of Fenced Response = Use Cases=0A=0A----No changes ---=0A=0A=0A =0A_____________________________= _______________________________________________________=0ADon't get soaked.= Take a quick peak at the forecast=0Awith the Yahoo! Search weather shortc= ut.=0Ahttp://tools.search.yahoo.com/shortcuts/#loc_weather _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Thu Jan 25 21:35:29 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAGvo-0004Qz-Fs; Thu, 25 Jan 2007 21:35:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAGvn-0004Qu-3p for ips@ietf.org; Thu, 25 Jan 2007 21:35:11 -0500 Received: from mexforward.lss.emc.com ([128.222.32.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HAGvl-00046W-M2 for ips@ietf.org; Thu, 25 Jan 2007 21:35:11 -0500 Received: from mailhub.lss.emc.com (uraeus.lss.emc.com [10.254.144.14]) by mexforward.lss.emc.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id l0Q2Z5Yh005567; Thu, 25 Jan 2007 21:35:05 -0500 (EST) Received: from corpussmtp3.corp.emc.com (corpussmtp3.corp.emc.com [10.254.64.53]) by mailhub.lss.emc.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id l0Q2Z2K3014009; Thu, 25 Jan 2007 21:35:03 -0500 (EST) From: Black_David@emc.com Received: from CORPUSMX20A.corp.emc.com ([128.221.62.13]) by corpussmtp3.corp.emc.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 25 Jan 2007 21:35:02 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: Last Call TMF resolution (Was Re: [Ips] iSCSI Implementer's Guide -WG Last Call status, 2nd try) Date: Thu, 25 Jan 2007 21:35:02 -0500 Message-ID: In-Reply-To: <418092.89223.qm@web51901.mail.yahoo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Last Call TMF resolution (Was Re: [Ips] iSCSI Implementer's Guide -WG Last Call status, 2nd try) Thread-Index: AcdA7xYOJRLggEE1SDeQjVD2HoIq9gAAsX9w References: <418092.89223.qm@web51901.mail.yahoo.com> To: , X-OriginalArrivalTime: 26 Jan 2007 02:35:02.0761 (UTC) FILETIME=[94E46D90:01C740F2] X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.5.0.283055, Antispam-Data: 2007.1.25.180932 X-PerlMx-Spam: Gauge=, SPAM=0%, Reason='EMC_BODY_1+ -3, EMC_FROM_0+ -2, NO_REAL_NAME 0, __C230066_P5 0, __CT 0, __CTE 0, __CTYPE_CHARSET_QUOTED 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __IMS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.3 (/) X-Scan-Signature: bf422c85703d3d847fb014987125ac48 Cc: X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ips-bounces@ietf.org Mallikarjun,=20 > Let me respond to your note under two separate covers. >=20 > Regarding b1, good catch! I fixed the text as below: >=20 > d. MUST generate an Asynchronous Message PDU with AsyncEvent=3D5 (section 8.1) on: > i) each connection of each third-party session to which at=20 > least one affected task is allegiant if=20 > TaskReporting=3DFastAbort is operational on that third-party session, I think g. needs some related attention, as it assumes a Nop-Out that won't happen when the AsyncEvent=3D5 message is not sent. =20 > Regarding b2, I agree with you that it should be at least a=20 > SHOULD, if not a MUST (since FastAbort was already negotiated=20 > on that session). However, I do not see which specific text=20 > in 4.1.2 you believe is implying a MUST NOT. Need more help=20 > here. Just to be clear, I now added the following to=20 > initiator behavior in 4.1.3: >=20 > c. MUST respond to each Async Message PDU with AsyncEvent=3D5=20 > as defined in section 8.1 (this step also applies when the=20 > initiator is receiving the Async Message in the third-party role). The 4.1.2 problem is omission of text. 4.1.2 never covers the possibility that one could use FastAbort on a third-party session when the TMF arrived on a non-FastAbort session. I interpret this as "MUST NOT" on the theory that this area of task management is tightly specified, and hence both 4.1.2 and 4.1.3 come with "MUST NOT do anything else" requirements. We'd be better off explicitly explaining what to do. Thanks, --David =20 > ----- Original Message ---- > From: "Black_David@emc.com" > To: ips@ietf.org > Cc: Black_David@emc.com > Sent: Wednesday, January 24, 2007 5:34:41 PM > Subject: [Ips] iSCSI Implementer's Guide - WG Last Call=20 > status, 2nd try >=20 >=20 > Your WG chair has resurfaced and apologizes for being > incommunicado these past few weeks (took a badly needed > vacation for a couple of weeks, including from email, > and have been digging out ever since). In the time since > my previous WG Last Call status message, three things > appear to have happened: >=20 > a) Issue (2) has been resolved on the list with new text > in the -04 version of the draft. I thank everyone > involved. > b) There was some discussion of behavior of task management > functions that affect more than one initiator when > not all the initiators have the TaskReporting key > set to FastAbort. > c) There was some discussion of the Response Fence. >=20 > --- b) Task management when not all initiators use FastAbort. >=20 > I believe the rough consensus of the WG is that FastAbort > can only be used on a session that has negotiated its use > (i.e., the new TaskReporting key was negotiated to FastAbort). > This has a couple of implications: >=20 > b1) This means that if the session that sent the TMF uses > FastAbort but some other affected iSCSI session doesn't, > FastAbort MUST NOT be used with that other affected session. >=20 > b2) In the reverse direction, if the session that sent the TMF > does not use FastAbort, but some other affected session does, > FastAbort could be used with that other affected session. >=20 > Each of these raises an issue: > o This text in Section 4.1.3 on target behavior violates b1): >=20 > d. MUST generate an Asynchronous Message PDU with AsyncEvent=3D5=20 > (section 8.1) on:=20 > i) each connection of each third-party session to which at=20 > least one affected task is allegiant, and=20 >=20 > --> The target has to first check whether the third-party session > uses FastAbort, otherwise the AsyncEvent=3D5 message will be > rather unexpected (e.g., by a 3720-only initiator). This > text needs to be corrected. >=20 > o The text in Section 4.1.2 currently prohibits FastAbort on > third party sessions when FastAbort is not used on the > session that sent the TMF (i.e., the "could" in b2 above > is a "MUST NOT" with the current text). >=20 > --> Any requirement option (MUST/SHOULD/MAY/MUST NOT/SHOULD NOT) > appears to work here, but we need to consciously make a > decision. I lean towards "SHOULD" instead of "MUST NOT". > Keep in mind that this is for a session for which usage > of FastAbort has been negotiated. Any change from the > current "MUST NOT" will entail a fair amount of editing > work. >=20 > --- c) The Response Fence >=20 > I believe that the WG rough consensus of the discussion about > the Response Fence functionality is that the functionality is > needed to deal with the ordering issues in the cases called > out in Section 3.3.3 of the -04 version of the draft (note > that the Initiator MUST negotiate TaskReporting=3DResponseFence > or TaskReporting=3DFastAbort before relying on response fence > behavior). >=20 > Unfortunately, I have to object to Section 3.3.1, which appears > to be trying to modify SAM-2 to add the Response Fence flag. > That can't be done in IETF, and any T10 modification would be > to SAM-4, whereas iSCSI is still based on SAM-2. I think the > mention of SAM-2 and model of the interface between SCSI and > a SCSI transport needs to be removed from Section 3.3.1. The > items numbered (1) and (2) in that section look ok (and in > fact useful to keep) - the problematic text is that which > suggests the existence of a "Response Fence flag" in the > abstract interface between SCSI and the SCSI transport (e.g., > iSCSI) along with the mention of "SCSI protocol interface > model" in Section 3.3. The upshot will be that Response > Fence behavior will be specified in a fashion that makes it > only applicable to the cases spelled out in Section 3.3.3. >=20 > ------------------ >=20 > So, I think we need further list discussion of the b) and c) > issues, including what the b2) requirement level should be. >=20 > I will monitor this discussion on at least a daily basis in > the hope of driving it to a relatively prompt conclusion, and > I will carefully read the -04 version of the draft in the > interim to see if I turn up anything else that may need > attention. >=20 > Thanks, > --David > ---------------------------------------------------- > David L. Black, Senior Technologist > EMC Corporation, 176 South St., Hopkinton, MA 01748 > +1 (508) 293-7953 FAX: +1 (508) 293-7786 > black_david@emc.com Mobile: +1 (978) 394-7754 > ---------------------------------------------------- >=20 > -----Original Message----- > From: Black_David@emc.com [mailto:Black_David@emc.com]=20 > Sent: Thursday, December 28, 2006 3:27 PM > To: ips@ietf.org > Subject: [Ips] iSCSI Implementer's Guide - WG Last Call status >=20 > The Working Group Last Call on this draft nominally ended on > December 18th, but there was no reason to treat that as a hard > cutoff. I am now ending the WG Last Call on this draft, although > list discussion of issues should be continued. >=20 > There have been two issues raised during this WGLC: > (1) Task Management - how to deal with uncooperative third- > party initiators. This issue has been resolved > on the list. > (2) Target checks - whether to discourage targets from > checking for initiator mistakes that the target can > tolerate. At the moment, I think the "rough consensus" > of the WG is not to do this - if anyone other than > Eddy thinks this is important to clarify, they need > to speak up promptly after the holidays. >=20 > The process from here is that Mallikarjun will submit a > revised version of the draft in the near future (there are > still some details to be worked out on the list). I will > be completely out of action (no email) the first two weeks > of January, so there will be time for people to check for > problems/issues/etc. I will check the revised draft and > send it to Lars with a request for RFC publication sometime > in the second half of January (probably during the week of > January 22nd). >=20 > Thanks, > --David >=20 > ---------------------------------------------------- > David L. Black, Senior Technologist > EMC Corporation, 176 South St., Hopkinton, MA 01748 > +1 (508) 293-7953 FAX: +1 (508) 293-7786 > black_david@emc.com Mobile: +1 (978) 394-7754 > ---------------------------------------------------- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Thu Jan 25 21:45:05 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAH5I-0001dH-CL; Thu, 25 Jan 2007 21:45:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAH5H-0001ba-11 for ips@ietf.org; Thu, 25 Jan 2007 21:44:59 -0500 Received: from mexforward.lss.emc.com ([128.222.32.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HAH5G-0005fc-5M for ips@ietf.org; Thu, 25 Jan 2007 21:44:58 -0500 Received: from mailhub.lss.emc.com (sesha.lss.emc.com [10.254.144.12]) by mexforward.lss.emc.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id l0Q2ivgG013627; Thu, 25 Jan 2007 21:44:57 -0500 (EST) Received: from corpussmtp3.corp.emc.com (corpussmtp3.corp.emc.com [10.254.64.53]) by mailhub.lss.emc.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id l0Q2iRpx007418; Thu, 25 Jan 2007 21:44:55 -0500 (EST) From: Black_David@emc.com Received: from CORPUSMX20A.corp.emc.com ([128.221.62.13]) by corpussmtp3.corp.emc.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 25 Jan 2007 21:44:54 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: Last Call Response Fence resolution (Was Re: [Ips] iSCSIImplementer's Guide - WG Last Call status, 2nd try) Date: Thu, 25 Jan 2007 21:44:53 -0500 Message-ID: In-Reply-To: <538695.15782.qm@web51902.mail.yahoo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Last Call Response Fence resolution (Was Re: [Ips] iSCSIImplementer's Guide - WG Last Call status, 2nd try) Thread-Index: AcdA8GVcmPkr4HxZQU+KaaXuADFShAAAmRQQ References: <538695.15782.qm@web51902.mail.yahoo.com> To: , X-OriginalArrivalTime: 26 Jan 2007 02:44:54.0264 (UTC) FILETIME=[F5749F80:01C740F3] X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.5.0.283055, Antispam-Data: 2007.1.25.182932 X-PerlMx-Spam: Gauge=, SPAM=0%, Reason='EMC_BODY_1+ -3, EMC_FROM_0+ -2, NO_REAL_NAME 0, __C230066_P5 0, __CT 0, __CTE 0, __CTYPE_CHARSET_QUOTED 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __IMS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.3 (/) X-Scan-Signature: 48472a944c87678fcfe8db15ffecdfff Cc: X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ips-bounces@ietf.org Mallikarjun, > I am trying to preserve the notion of an iSCSI-defined &=20 > iSCSI-scoped Response Fence in the text (you seem to be OK=20 > with it). This gives us a convenient shorthand to refer to a=20 > set of semantics. Besides, if/when T10 approves the response=20 > fence concept for SAM-4, iSCSI implementers will know what to=20 > map it to for iSCSI. As you'll see, I made it very clear in=20 > the new text that this is not an attempt to change SAM in=20 > this draft (which was of course never the intent). I agree in principle with the intent where "Response Fence" is iSCSI-scoped and defined "behavior." OTOH, calling it a "flag" is a problem. I would prefer that all text anticipating addition of a "flag" to SAM-4 be removed, and in particular the following text: > the following=20 > semantics are defined for a "Response Fence" flag if such a=20 > flag were to qualify SCSI completion messages as they are=20 > handed off from the SCSI protocol layer to the iSCSI layer. =20 > Note however that [SAM2] does not model such a flag in its=20 > protocol interface model, so the "Response Fence" flag is an=20 > iSCSI-defined artifact for descriptive convenience of the=20 > mandatory iSCSI response ordering semantics. which is just asking for an IETF Last Call comment or AD question about why this circumlocution was used when it suffices to define the "Response Fence" behavior without ever mentioning a non- existent flag. Section 3.3.3 doesn't need the flag - it can refer to the behavior and say what it MUST be applied to. If Rob succeeds in getting T10 to put a Response Fence flag into SAM-4, we can deal with that flag in the draft that deals with the impacts of SAM-3 and SAM-4 on iSCSI, which will have a number of other things to deal with. Before anyone gets excited about this, I will state my view that the IETF will need to ensure that all such impacts are specified in a fashion that is backwards compatible with RFC-3720-only implementations. Thanks, --David ---------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- > -----Original Message----- > From: Mallikarjun C. [mailto:cb_mallikarjun@yahoo.com]=20 > Sent: Thursday, January 25, 2007 9:18 PM > To: ips@ietf.org > Subject: Last Call Response Fence resolution (Was Re: [Ips]=20 > iSCSIImplementer's Guide - WG Last Call status, 2nd try) >=20 > David,=20 >=20 > I understand your feedback on section 3.3.1. I have made a=20 > handful of changes to the text, new text is attached below=20 > for your review. >=20 > I am trying to preserve the notion of an iSCSI-defined &=20 > iSCSI-scoped Response Fence in the text (you seem to be OK=20 > with it). This gives us a convenient shorthand to refer to a=20 > set of semantics. Besides, if/when T10 approves the response=20 > fence concept for SAM-4, iSCSI implementers will know what to=20 > map it to for iSCSI. As you'll see, I made it very clear in=20 > the new text that this is not an attempt to change SAM in=20 > this draft (which was of course never the intent). >=20 > Mallikarjun >=20 > ----- Original Message ---- > From: "Black_David@emc.com" > To: ips@ietf.org > Cc: Black_David@emc.com > Sent: Wednesday, January 24, 2007 5:34:41 PM > Subject: [Ips] iSCSI Implementer's Guide - WG Last Call=20 > status, 2nd try > ....... >=20 > --- c) The Response Fence >=20 > ...... >=20 > Unfortunately, I have to object to Section 3.3.1, which appears > to be trying to modify SAM-2 to add the Response Fence flag. > That can't be done in IETF, and any T10 modification would be > to SAM-4, whereas iSCSI is still based on SAM-2. I think the > mention of SAM-2 and model of the interface between SCSI and > a SCSI transport needs to be removed from Section 3.3.1. The > items numbered (1) and (2) in that section look ok (and in > fact useful to keep) - the problematic text is that which > suggests the existence of a "Response Fence flag" in the > abstract interface between SCSI and the SCSI transport (e.g., > iSCSI) along with the mention of "SCSI protocol interface > model" in Section 3.3. The upshot will be that Response > Fence behavior will be specified in a fashion that makes it > only applicable to the cases spelled out in Section 3.3.3. >=20 > ........... >=20 >=20 >=20 > 3.3 Model Assumptions for Response Ordering > Whenever an iSCSI session is composed of multiple=20 > connections, the Response PDUs (task responses or TMF=20 > responses) originating in the target SCSI layer are=20 > distributed onto the multiple connections by the target iSCSI=20 > layer according to iSCSI connection allegiance rules. This=20 > process generally may not preserve the ordering of the=20 > responses by the time they are delivered to the initiator=20 > SCSI layer. Since ordering is not expected across SCSI=20 > responses anyway, this approach works fine in the general=20 > case. However to address the special cases where some=20 > ordering is desired by the SCSI layer, the following=20 > semantics are defined for a "Response Fence" flag if such a=20 > flag were to qualify SCSI completion messages as they are=20 > handed off from the SCSI protocol layer to the iSCSI layer. =20 > Note however that [SAM2] does not model such a flag in its=20 > protocol interface model, so the "Response Fence" flag is an=20 > iSCSI-defined artifact for descriptive convenience of the=20 > mandatory iSCSI response ordering semantics. =20 >=20 > 3.3.1 Model Description > Target SCSI protocol layer hands off the SCSI completion=20 > messages to the target iSCSI layer by invoking the "Send=20 > Command Complete" protocol data service ([SAM2], clause=20 > 5.4.2) and "Task Management Function Executed" ([SAM2],=20 > clause 6.9) service. On receiving the SCSI completion=20 > message, iSCSI layer assumes that a Response Fence flag=20 > optionally qualifies the SCSI completion message (section=20 > 3.3.3 describes the specific instances where the flag=20 > qualifies the completion message). Whenever the Response=20 > Fence flag is present, the target iSCSI layer MUST ensure=20 > that the following conditions are met in delivering the=20 > response message to the initiator iSCSI layer: > (1) Response with Response Fence MUST chronologically be=20 > delivered after all the "preceding" responses on the I_T_L=20 > nexus, if the preceding responses are delivered at all, to=20 > the application client on the initiator.=20 > (2) Response with Response Fence MUST chronologically be=20 > delivered prior to all the "following" responses on the I_T_L nexus.=20 > The "preceding" and "following" notions refer to the order of=20 > hand-off of a response message from the target SCSI protocol=20 > layer to the target iSCSI layer. >=20 > 3.3.2 iSCSI Semantics with the Interface Model > Whenever the TaskReporting key (section 9.1) is negotiated to=20 > ResponseFence or FastAbort for an iSCSI session, the target=20 > iSCSI layer MUST perform the actions described in this=20 > section on all tasks related to that session. A target iSCSI=20 > layer MUST do the following whenever Response Fence flag=20 > qualifies a SCSI completion message handed down from the=20 > target SCSI layer: > a) If it is a single-connection session, no special=20 > processing is required. Standard SCSI Response PDU build=20 > process happens.=20 > b) If it is a multi-connection session, target iSCSI layer=20 > takes note of last-sent and unacknowledged StatSN on each of=20 > the connections in the iSCSI session, and waits for=20 > acknowledgement (SHOULD solicit for acknowledgement by way of=20 > a Nop-In) of each such StatSN to clear the fence. SCSI=20 > response with the Response Fence flag must be sent to the=20 > initiator only after receiving acknowledgements for each of=20 > the unacknowledged StatSNs. > c) Target iSCSI layer must wait for an acknowledgement of the=20 > SCSI Response PDU that carried the response which the target=20 > SCSI layer marked with the Response Fence flag. The fence=20 > must be considered cleared after receiving the acknowledgement. > d) All further status processing for the LU is resumed only=20 > after clearing the fence. If any new responses for the I_T_L=20 > nexus are received from the SCSI layer before the fence is=20 > cleared, those Response PDUs must be held and queued at the=20 > iSCSI layer until the fence is cleared. >=20 > 3.3.3 Current List of Fenced Response Use Cases >=20 > ----No changes --- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ndaftcurx@commarts.com Fri Jan 26 01:48:35 2007 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAKt1-0005Va-My for ips-archive@lists.ietf.org; Fri, 26 Jan 2007 01:48:35 -0500 Received: from [195.24.93.98] (helo=[195.24.93.98]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HAKsy-0004ol-9v for ips-archive@lists.ietf.org; Fri, 26 Jan 2007 01:48:35 -0500 From: "details. trademark" To: ips-archive@lists.ietf.org Subject: Wall Street Alert! Date: Fri, 26 Jan 2007 08:48:25 -0200 MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_000_0004_01C74126.BDD0F820" X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcdBJr3QYkP4Kn3JRBSav4YhuhTxPw== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Message-Id: <095C405F34920C2.AD790E0716@commarts.com> X-Spam-Score: 4.2 (++++) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 ------=_NextPart_000_0004_01C74126.BDD0F820 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
<> ATTENTION DAY TRADERS AND INVESTORS. GET ON PSUD! <>

INVESTOR ALERT! DON'T MISS THIS RUN ON PSUD!!!

Watch PSUD Like a Hawk on January 26, 2007

Company: PetroSun
Sym: PSUD
Currently: $0.43 (+0.01 Close)
Friday Target: $1.50

PHOENIX, AZ--(MRKET WIRE)--Jan 11, 2007 -- PetroSun, Incorporated (Other 0TC:PSUD,PK - News) announced today that an agreement has been executed with New Standard Exploration NL of West Perth, Australia covering Exploration Permit 417 located within the Canning Basin of Western Australia. PetroSun and New Standard will form a joint venture to explore, develop and produce oil and/or gas from EP417. PetroSun is the designated Manager/Operator and will be assigned a 75% working interest in the permit for the initial consideration of A$5,000,000 through PetroSun's sole funding of exploration, permit development and drilling.

Keep a look out for additional GREAT weekly news and be sure to watch them trade like crazy on Friday January 26, 2007

------=_NextPart_000_0004_01C74126.BDD0F820-- From ips-bounces@ietf.org Fri Jan 26 03:17:24 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAMGM-0003rY-Uj; Fri, 26 Jan 2007 03:16:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAMGM-0003rT-GL for ips@ietf.org; Fri, 26 Jan 2007 03:16:46 -0500 Received: from mtagate6.de.ibm.com ([195.212.29.155]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HAMGJ-0006Gx-UQ for ips@ietf.org; Fri, 26 Jan 2007 03:16:46 -0500 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate6.de.ibm.com (8.13.8/8.13.8) with ESMTP id l0Q8GgA1184994 for ; Fri, 26 Jan 2007 08:16:42 GMT Received: from d12av02.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1607.megacenter.de.ibm.com (8.13.8/8.13.8/NCO v8.2) with ESMTP id l0Q8Ggq3561268 for ; Fri, 26 Jan 2007 09:16:42 +0100 Received: from d12av02.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l0Q8GgaN011716 for ; Fri, 26 Jan 2007 09:16:42 +0100 Received: from d12mc102.megacenter.de.ibm.com (d12mc102.megacenter.de.ibm.com [9.149.167.114]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l0Q8Gf10011707 for ; Fri, 26 Jan 2007 09:16:41 +0100 In-Reply-To: <4f179b220701251308n21ded621w385d8bfcf3d76297@mail.gmail.com> To: "Barada Mishra" MIME-Version: 1.0 Subject: Re: [Ips] iscsi: More immediate data than required data X-Mailer: Lotus Notes Release 7.0.2 September 26, 2006 From: Julian Satran Message-ID: Date: Fri, 26 Jan 2007 10:16:40 +0200 X-MIMETrack: Serialize by Router on D12MC102/12/M/IBM(Release 7.0.2HF71 | November 3, 2006) at 26/01/2007 10:16:40, Serialize complete at 26/01/2007 10:16:40 X-Spam-Score: 0.1 (/) X-Scan-Signature: 36b1f8810cb91289d885dc8ab4fc8172 Cc: ips@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0634320696==" Errors-To: ips-bounces@ietf.org This is a multipart message in MIME format. --===============0634320696== Content-Type: multipart/alternative; boundary="=_alternative 002D78A7C225726F_=" This is a multipart message in MIME format. --=_alternative 002D78A7C225726F_= Content-Type: text/plain; charset="US-ASCII" If you are talking about a discrepancy between the CDB indicated length in blocks and the total data length (including immediate) indicated by iSCSI (originated from SCSI) this is legal and the result will include a residula lenngth and an "underflow" (device needs more data than accomodated by SCSI buffer). The specific command set indicates how the blocks on the device will be filled (padded). If you are talking about Immediate data exceeeding iSCSI total data length (originated from SCSI) that is a protocol error and should be handled accordingly. The command should be rejected and dropping the session depends on the leniency of the target. Julo "Barada Mishra" 25/01/07 23:08 To ips@ietf.org cc Subject [Ips] iscsi: More immediate data than required data Hi, This question is from a iSCSI target point of view. When a target receives more immediate data than the required data, what should be the behavior? Example : Assume the target receives a write command for 2 blocks (1024 bytes). But the associated immediate data it receives is 2048. What should the target do 1. Use only 1024 bytes, ignore the rest of data and return good status 2. Return check condition (what should be the ASC/ASCQ)? 3. Drop the connection and/or session 4. Reject the PDU Or something else? Thanks Barada _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --=_alternative 002D78A7C225726F_= Content-Type: text/html; charset="US-ASCII"
If you are talking about a discrepancy between the CDB indicated length in blocks and the total data length (including immediate) indicated by iSCSI (originated from SCSI) this is legal and the result will include a residula lenngth and an "underflow" (device needs more data than accomodated by SCSI buffer). The specific command set indicates how the blocks on the device will be filled (padded).

If you are talking about Immediate data exceeeding iSCSI total data length (originated from SCSI)  that is a protocol error and should be handled accordingly.
The command should be rejected and dropping the session depends on the leniency of the target.

Julo


"Barada Mishra" <bsmishra@gmail.com>

25/01/07 23:08

To
ips@ietf.org
cc
Subject
[Ips] iscsi: More immediate data than required data





Hi,

This question is from a iSCSI target point of view.

When a target receives more immediate data than the required data, what should be the behavior?

Example :
Assume the target receives a write command for 2 blocks (1024 bytes).
But the associated immediate data it receives is 2048.

What should the target do
 1. Use only 1024 bytes, ignore the rest of data and return good status
 2. Return check condition (what should be the ASC/ASCQ)?
 3. Drop the connection and/or session
 4. Reject the PDU
Or something else?

Thanks
Barada
_______________________________________________
Ips mailing list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips
--=_alternative 002D78A7C225726F_=-- --===============0634320696== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --===============0634320696==-- From ips-bounces@ietf.org Fri Jan 26 11:17:16 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HATl2-0004un-2M; Fri, 26 Jan 2007 11:16:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HATl1-0004ui-3c for ips@ietf.org; Fri, 26 Jan 2007 11:16:55 -0500 Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HATku-00063m-Lc for ips@ietf.org; Fri, 26 Jan 2007 11:16:55 -0500 Received: from fe-amer-10.sun.com ([192.18.108.184]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l0QGGmhi027236 for ; Fri, 26 Jan 2007 09:16:48 -0700 (MST) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JCH00D01H3ZKP00@mail-amer.sun.com> (original mail from Joel.Buckley@Sun.COM) for ips@ietf.org; Fri, 26 Jan 2007 09:16:48 -0700 (MST) Received: from sun.com ([129.147.156.114]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTP id <0JCH00IBTH8024PJ@mail-amer.sun.com>; Fri, 26 Jan 2007 09:16:48 -0700 (MST) Received: from [129.150.49.249] by bedge3-mail1.central.sun.com (mshttpd); Fri, 26 Jan 2007 09:16:48 -0700 Date: Fri, 26 Jan 2007 09:16:48 -0700 From: Joel Buckley Subject: Re: [Ips] iscsi: More immediate data than required data In-reply-to: <4f179b220701251308n21ded621w385d8bfcf3d76297@mail.gmail.com> To: Barada Mishra Message-id: MIME-version: 1.0 X-Mailer: Sun Java(tm) System Messenger Express 6.2-6.01 (built Apr 3 2006) Content-type: multipart/mixed; boundary="Boundary_(ID_VdnnW2hU8bmV20ERm8/7qA)" Content-language: en X-Accept-Language: en Priority: normal References: <4f179b220701251308n21ded621w385d8bfcf3d76297@mail.gmail.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: ips@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ips-bounces@ietf.org This is a multi-part message in MIME format. --Boundary_(ID_VdnnW2hU8bmV20ERm8/7qA) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline Barada, The response depends on where 1024 vs. 2048 bytes are encoded... If SCSI WRITE(10) TransferLength is set to 2 (512 Blocks) and iSCSI SCSI Command PDU DataSegmentLength is set to 2048, then all 2048 bytes SHALL be read by iSCSI Target and only the first 1024 bytes SHALL be utilized by SCSI Target. If SCSI WRITE(10) TransferLength is set to 2 (512 Blocks) and iSCSI SCSI Command PDU DataSegmentLength is set to 1024, then all 1024 bytes SHALL be read by iSCSI Target and all1024 bytes SHALL be utilized by SCSI Target. In either case, the iSCSI Target SHALL expect the next iSCSI PDU to begin immediately after the last... So if an additional 1024 bytes of unknown data are appended to a PDU, then results are indeterminate. The unknown data may be evaluated as another iSCSI PDU or may be seen as a data corruption on the connection. If the data is seen as a data corruption, then iSCSI ERROR RECOVERY LEVEL protocols SHALL be followed. Cheers, Joel. Joel.Buckley@Sun.COM JIST Development Lead 303-272-5556, x75556 "Luck is a Planned Event." ----- Original Message ----- From: Barada Mishra Date: Thursday, January 25, 2007 2:10 pm Subject: [Ips] iscsi: More immediate data than required data To: ips@ietf.org > Hi, > > This question is from a iSCSI target point of view. > > When a target receives more immediate data than the required data, > whatshould be the behavior? > > Example : > Assume the target receives a write command for 2 blocks (1024 bytes). > But the associated immediate data it receives is 2048. > > What should the target do > 1. Use only 1024 bytes, ignore the rest of data and return good > status 2. Return check condition (what should be the ASC/ASCQ)? > 3. Drop the connection and/or session > 4. Reject the PDU > Or something else? > > Thanks > Barada > --Boundary_(ID_VdnnW2hU8bmV20ERm8/7qA) Content-type: text/x-vcard; charset=us-ascii; name=Joel.Buckley.vcf Content-transfer-encoding: 7BIT Content-disposition: attachment; filename=Joel.Buckley.vcf Content-description: Card for Joel Buckley begin:vcard n:Buckley;Joel fn:Joel W. Buckley tel;fax:303-272-4194 tel;home:720-226-9370 tel;work:303-272-5556 url:sse.sfbay/interop/jist org:Storage Group;System Test adr:;;500 Eldorado Blvd., BRM05, Room3196;Broomfield;Colorado;80021-3400;USA version:2.1 email;internet:Joel.Buckley@Sun.COM title:JIST Development Lead end:vcard --Boundary_(ID_VdnnW2hU8bmV20ERm8/7qA) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips --Boundary_(ID_VdnnW2hU8bmV20ERm8/7qA)-- From ips-bounces@ietf.org Fri Jan 26 12:25:48 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAUpN-0000Ph-PY; Fri, 26 Jan 2007 12:25:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAUpL-0000PY-Or for ips@ietf.org; Fri, 26 Jan 2007 12:25:27 -0500 Received: from chip8og50.obsmtp.com ([64.18.15.173]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HAUpK-00078k-Gr for ips@ietf.org; Fri, 26 Jan 2007 12:25:27 -0500 Received: from source ([12.110.134.31]) by chip8ob50.postini.com ([64.18.7.12]) with SMTP; Fri, 26 Jan 2007 09:22:43 PST Received: from pkoning.equallogic.com ([172.16.1.128]) by M31.equallogic.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 26 Jan 2007 12:22:18 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17850.14537.591823.678505@gargle.gargle.HOWL> Date: Fri, 26 Jan 2007 12:22:17 -0500 From: Paul Koning To: Joel.Buckley@Sun.COM Subject: Re: [Ips] iscsi: More immediate data than required data References: <4f179b220701251308n21ded621w385d8bfcf3d76297@mail.gmail.com> X-Mailer: VM 7.17 under 21.4 (patch 19) "Constant Variable" XEmacs Lucid X-OriginalArrivalTime: 26 Jan 2007 17:22:18.0910 (UTC) FILETIME=[881C1BE0:01C7416E] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: ips@ietf.org X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ips-bounces@ietf.org >>>>> "Joel" == Joel Buckley writes: Joel> Barada, The response depends on where 1024 vs. 2048 bytes are Joel> encoded... Joel> If SCSI WRITE(10) TransferLength is set to 2 (512 Blocks) and Joel> iSCSI SCSI Command PDU DataSegmentLength is set to 2048, then Joel> all 2048 bytes SHALL be read by iSCSI Target and only the first Joel> 1024 bytes SHALL be utilized by SCSI Target. I can't imagine any reason why an initiator would do such a thing, and I'd prefer to call it an error, but if SCSI requires this sort of thing to be permitted, then I guess that's how it goes. Joel> If SCSI WRITE(10) TransferLength is set to 2 (512 Blocks) and Joel> iSCSI SCSI Command PDU DataSegmentLength is set to 1024, then Joel> all 1024 bytes SHALL be read by iSCSI Target and all1024 bytes Joel> SHALL be utilized by SCSI Target. That's the normal case. Joel> In either case, the iSCSI Target SHALL expect the next iSCSI Joel> PDU to begin immediately after the last... So if an additional Joel> 1024 bytes of unknown data are appended to a PDU, then results Joel> are indeterminate. The unknown data may be evaluated as Joel> another iSCSI PDU or may be seen as a data corruption on the Joel> connection. If the data is seen as a data corruption, then Joel> iSCSI ERROR RECOVERY LEVEL protocols SHALL be followed. That's a third case. What you're describing is a case where there is junk in the middle of the iSCSI protocol data stream that isn't described by any headers, it isn't claimed to be payload. If so, it obviously will be seen as another iSCSI PDU header, with whatever consequences that implies. Obviously, such a thing cannot ever be valid -- but depending on the contents of the junk it may or may not be detected. paul _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Fri Jan 26 14:36:38 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAWrz-0003KA-Oc; Fri, 26 Jan 2007 14:36:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAWry-0003K5-LZ for ips@ietf.org; Fri, 26 Jan 2007 14:36:18 -0500 Received: from web51901.mail.yahoo.com ([206.190.48.64]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HAWrx-0001Qa-9u for ips@ietf.org; Fri, 26 Jan 2007 14:36:18 -0500 Received: (qmail 76395 invoked by uid 60001); 26 Jan 2007 19:36:15 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=KAza1VVJsszlssm+VUfsW5z69TJtcTiFOuS/XEv/lXE72w4I5GhaP3n2xOsEmKG2V12mS+2okrm6Ju7AO2cixPZQPBzGNv3aSCVQtbRKfKQFr4iblxsf66NkeHNgUkud0d0SBZgod8btR2NJchweFsTOo2bn9Z8DDS/choiYOMA=; X-YMail-OSG: BSGOvc8VM1muutFpDm6ogrAV8wxoSW_O3c4DRSear6roMfYQNAqWCTVuDywRpj912mvCVaDZihIdG6UYMEi5k6rLoez3YkK9OHp1VDvDVT08fOTGCxKR6FJjsLVMJVJ2x7oUtqeze3We7manhdN4UuN0NPbA8Q.xW5ucCe9Xxhtqzn1AQCYPN8SXTDE9 Received: from [15.235.153.104] by web51901.mail.yahoo.com via HTTP; Fri, 26 Jan 2007 11:36:14 PST X-Mailer: YahooMailRC/368.3 YahooMailWebService/0.6.132.7 Date: Fri, 26 Jan 2007 11:36:13 -0800 (PST) From: "Mallikarjun C." To: ips@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Message-ID: <672170.74474.qm@web51901.mail.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Subject: [Ips] Re: Last Call TMF resolution X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ips-bounces@ietf.org David,=0A=0Abullet g is saying:=0A"g. MUST free up the affected TTTs (and S= Tags, if applicable) and the corresponding buffers, if any, once it receive= s each associated Nop-Out acknowledgement that the initiator generated in r= esponse to each Async Message."=0A=0AIt does not assume a Nop-Out always, i= t simply implies that a Nop-Out ack is received for each Async. Don't see = any issues for legacy initiators that don't send Nop-Outs (which were never= sent Asyncs anyway per the new clarification added in bullet d). Looks al= right to me. Are you OK?=0A=0A=0ARegarding your issue with 4.1.2 (which yo= u consider as a omission), I tend to slightly differ. Note that section 4.= 1.2 is exclusively meant for all implementations - old and new. So I did n= ot want to put any wording in there that requires them to implement and sup= port FastAbort on third-party sessions as the baseline behavior (that impos= es an unfair requirement on all targets to implement unlike initiators whic= h can choose to implement the new semantics). But your comment OTOH is val= id. So I think the best way to address your comment is put in more text (s= igh...) in a new section 4.1.5. It's attached below. Take a look and let = me know if that's along the lines of what you are looking for or I'm off...= ..=0A=0AThanks.=0A=0AMallikarjun=0A=0A=0A=0A=0A----- Original Message ----= =0AFrom: "Black_David@emc.com" =0ATo: cb_mallikarjun@y= ahoo.com; ips@ietf.org=0ASent: Thursday, January 25, 2007 6:35:02 PM=0ASubj= ect: RE: Last Call TMF resolution (Was Re: [Ips] iSCSI Implementer's Guide = -WG Last Call status, 2nd try)=0A=0A=0AMallikarjun, =0A=0A> Let me respond = to your note under two separate covers.=0A> =0A> Regarding b1, good catch! = I fixed the text as below:=0A> =0A> d. MUST generate an Asynchronous Messa= ge PDU with AsyncEvent=3D5=0A(section 8.1) on:=0A> i) each connection of ea= ch third-party session to which at =0A> least one affected task is allegian= t if =0A> TaskReporting=3DFastAbort is operational on that third-party sess= ion,=0A=0AI think g. needs some related attention, as it assumes a Nop-Out= =0Athat won't happen when the AsyncEvent=3D5 message is not sent.=0A=0A> Re= garding b2, I agree with you that it should be at least a =0A> SHOULD, if n= ot a MUST (since FastAbort was already negotiated =0A> on that session). H= owever, I do not see which specific text =0A> in 4.1.2 you believe is imply= ing a MUST NOT. Need more help =0A> here. Just to be clear, I now added t= he following to =0A> initiator behavior in 4.1.3:=0A> =0A> c. MUST respond = to each Async Message PDU with AsyncEvent=3D5 =0A> as defined in section 8.= 1 (this step also applies when the =0A> initiator is receiving the Async Me= ssage in the third-party role).=0A=0AThe 4.1.2 problem is omission of text.= 4.1.2 never covers the=0Apossibility that one could use FastAbort on a th= ird-party session=0Awhen the TMF arrived on a non-FastAbort session. I int= erpret this=0Aas "MUST NOT" on the theory that this area of task management= is=0Atightly specified, and hence both 4.1.2 and 4.1.3 come with=0A"MUST N= OT do anything else" requirements. We'd be better off=0Aexplicitly explain= ing what to do.=0A=0AThanks,=0A--David=0A=0A=0A4.1.4 Affected tasks shared = across Legacy & FastAbort sessions=0AIf an iSCSI target implementation is c= apable of supporting TaskReporting=3DFastAbort functionality (section 9.1),= it may end up in a situation where some sessions have TaskReporting=3DLega= cy operational (Legacy sessions) while some other sessions have TaskReporti= ng=3DFastAbort operational (FastAbort sessions) even while accessing a shar= ed set of affected tasks (section 4.1.1).=0A=0AIf the issuing session is a = Legacy session, iSCSI target implementation is FastAbort-capable and third-= party affected session is a FastAbort session, the following behavior SHOUL= D be exhibited by the iSCSI target layer:=0Aa. Between steps c and d of tar= get behavior in section 4.1.2, send an Asynchronous Message PDU with AsyncE= vent=3D5 (section 8.1) on each connection of each third-party session to wh= ich at least one affected task is allegiant. If there are multiple affecte= d LUs, then send one Async Message PDU for each such LU on each connection = that has at least one allegiant affected task. When sent, the LUN field in= the Asynchronous Message PDU MUST be set to match the LUN for each such LU= .=0Ab. After step e of target behavior in section 4.1.2, free up the affect= ed TTTs (and STags, if applicable) and the corresponding buffers, if any, o= nce each associated Nop-Out acknowledgement is received that the third-part= y initiator generated in response to each Async Message sent in step a.=0A= =0AIf the issuing session is a FastAbort session, iSCSI target implementati= on is FastAbort-capable and third-party affected session is a Legacy sessio= n, the following behavior MUST be exhibited by the iSCSI target layer: Asyn= chronous Message PDUs MUST NOT be sent on the third-party session to prompt= the FastAbort behavior.=0A=0A=0A =0A______________________________________= ______________________________________________=0AIt's here! Your new messag= e! =0AGet new email alerts with the free Yahoo! Toolbar.=0Ahttp://tools.se= arch.yahoo.com/toolbar/features/mail/ _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From bruissheelah@nildram.net Fri Jan 26 15:34:33 2007 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAXmL-0008Ar-MX for ips-archive@lists.ietf.org; Fri, 26 Jan 2007 15:34:33 -0500 Received: from [189.171.49.200] (helo=charly) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1HAXjs-0007FP-Fm for ips-archive@lists.ietf.org; Fri, 26 Jan 2007 15:32:02 -0500 To: "irvin osmond" Date: Fri, 26 Jan 2007 13:31:59 -0700 From: "opaline neely" Sender: "opaline neely" Subject: Hi MIME-Version: 1.0 Message-ID: Content-Type: multipart/alternative; boundary="----=_NextPart_000_A0A51_01C7414E.3B186EE0" X-Mailer: Microsoft Outlook Express 6.00.2900.2527 Priority: normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Score: 3.8 (+++) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d This is a multi-part message in MIME format. ------=_NextPart_000_A0A51_01C7414E.3B186EE0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Manzilla! Size does matter! You seen this on TV! http://ghostmafers.com/ex/ breast pang ------=_NextPart_000_A0A51_01C7414E.3B186EE0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Manzilla! Size does matter! You seen this on TV!
http://ghostmafers.com/ex/
breast pang ------=_NextPart_000_A0A51_01C7414E.3B186EE0-- From ips-bounces@ietf.org Fri Jan 26 17:03:35 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAZ9v-00067F-0i; Fri, 26 Jan 2007 17:02:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAZ9t-00064q-UJ for ips@ietf.org; Fri, 26 Jan 2007 17:02:57 -0500 Received: from mexforward.lss.emc.com ([128.222.32.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HAZ9p-00076T-Hb for ips@ietf.org; Fri, 26 Jan 2007 17:02:57 -0500 Received: from mailhub.lss.emc.com (sesha.lss.emc.com [10.254.144.12]) by mexforward.lss.emc.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id l0QM2phv005278; Fri, 26 Jan 2007 17:02:51 -0500 (EST) Received: from corpussmtp3.corp.emc.com (corpussmtp3.corp.emc.com [10.254.64.53]) by mailhub.lss.emc.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id l0QM28Rt007361; Fri, 26 Jan 2007 17:02:49 -0500 (EST) From: Black_David@emc.com Received: from CORPUSMX20A.corp.emc.com ([128.221.62.13]) by corpussmtp3.corp.emc.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 26 Jan 2007 17:02:43 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ips] Re: Last Call TMF resolution Date: Fri, 26 Jan 2007 17:02:34 -0500 Message-ID: In-Reply-To: <672170.74474.qm@web51901.mail.yahoo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ips] Re: Last Call TMF resolution Thread-Index: AcdBgc1xdP4ivuVuQsigguGfMDhcVQAEeA2Q References: <672170.74474.qm@web51901.mail.yahoo.com> To: , X-OriginalArrivalTime: 26 Jan 2007 22:02:43.0608 (UTC) FILETIME=[B4694980:01C74195] X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.5.0.283055, Antispam-Data: 2007.1.26.133932 X-PerlMx-Spam: Gauge=, SPAM=2%, Reason='EMC_FROM_0+ -2, NO_REAL_NAME 0, __CP_URI_IN_BODY 0, __CT 0, __CTE 0, __CTYPE_CHARSET_QUOTED 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __IMS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.2 (/) X-Scan-Signature: 3fbd9b434023f8abfcb1532abaec7a21 Cc: X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ips-bounces@ietf.org I think I see some of where I'm confused. 4.1.2 and 4.1.3 are about what the initiator that sent the TMF does as well as the target. We need to explain what a 3rd-party initiator does, which for a 3720-only initiator is unchanged. I think your new 4.1.4 is headed towards covering this in addition to the Target behavior in a mixed FastAbort/non-FastAbort case. One crucial point that needs to be made is that a FastAbort initiator may get an AsyncEvent=3D5 message out of the blue if some other initiator, even a Legacy initiator, issues a TMF that affects the FastAbort initiator's tasks, even if the iSCSI session only contains a single TCP connection (FastAbort initiator will never get AsyncEvent=3D5 messages for its own TMFs on a single connection session). On another minor note, "Legacy" as a key value seems pejorative to me. "RFC3720" would be neutral and in fact more descriptive of what's actually going on. Thanks, --David > -----Original Message----- > From: Mallikarjun C. [mailto:cb_mallikarjun@yahoo.com]=20 > Sent: Friday, January 26, 2007 2:36 PM > To: ips@ietf.org > Subject: [Ips] Re: Last Call TMF resolution >=20 > David, >=20 > bullet g is saying: > "g. MUST free up the affected TTTs (and STags, if applicable)=20 > and the corresponding buffers, if any, once it receives each=20 > associated Nop-Out acknowledgement that the initiator=20 > generated in response to each Async Message." >=20 > It does not assume a Nop-Out always, it simply implies that a=20 > Nop-Out ack is received for each Async. Don't see any issues=20 > for legacy initiators that don't send Nop-Outs (which were=20 > never sent Asyncs anyway per the new clarification added in=20 > bullet d). Looks alright to me. Are you OK? >=20 >=20 > Regarding your issue with 4.1.2 (which you consider as a=20 > omission), I tend to slightly differ. Note that section=20 > 4.1.2 is exclusively meant for all implementations - old and=20 > new. So I did not want to put any wording in there that=20 > requires them to implement and support FastAbort on=20 > third-party sessions as the baseline behavior (that imposes=20 > an unfair requirement on all targets to implement unlike=20 > initiators which can choose to implement the new semantics). =20 > But your comment OTOH is valid. So I think the best way to=20 > address your comment is put in more text (sigh...) in a new=20 > section 4.1.5. It's attached below. Take a look and let me=20 > know if that's along the lines of what you are looking for or=20 > I'm off..... >=20 > Thanks. >=20 > Mallikarjun >=20 >=20 >=20 >=20 > ----- Original Message ---- > From: "Black_David@emc.com" > To: cb_mallikarjun@yahoo.com; ips@ietf.org > Sent: Thursday, January 25, 2007 6:35:02 PM > Subject: RE: Last Call TMF resolution (Was Re: [Ips] iSCSI=20 > Implementer's Guide -WG Last Call status, 2nd try) >=20 >=20 > Mallikarjun,=20 >=20 > > Let me respond to your note under two separate covers. > >=20 > > Regarding b1, good catch! I fixed the text as below: > >=20 > > d. MUST generate an Asynchronous Message PDU with AsyncEvent=3D5 > (section 8.1) on: > > i) each connection of each third-party session to which at=20 > > least one affected task is allegiant if=20 > > TaskReporting=3DFastAbort is operational on that third-party = session, >=20 > I think g. needs some related attention, as it assumes a Nop-Out > that won't happen when the AsyncEvent=3D5 message is not sent. >=20 > > Regarding b2, I agree with you that it should be at least a=20 > > SHOULD, if not a MUST (since FastAbort was already negotiated=20 > > on that session). However, I do not see which specific text=20 > > in 4.1.2 you believe is implying a MUST NOT. Need more help=20 > > here. Just to be clear, I now added the following to=20 > > initiator behavior in 4.1.3: > >=20 > > c. MUST respond to each Async Message PDU with AsyncEvent=3D5=20 > > as defined in section 8.1 (this step also applies when the=20 > > initiator is receiving the Async Message in the third-party role). >=20 > The 4.1.2 problem is omission of text. 4.1.2 never covers the > possibility that one could use FastAbort on a third-party session > when the TMF arrived on a non-FastAbort session. I interpret this > as "MUST NOT" on the theory that this area of task management is > tightly specified, and hence both 4.1.2 and 4.1.3 come with > "MUST NOT do anything else" requirements. We'd be better off > explicitly explaining what to do. >=20 > Thanks, > --David >=20 >=20 > 4.1.4 Affected tasks shared across Legacy & FastAbort sessions > If an iSCSI target implementation is capable of supporting=20 > TaskReporting=3DFastAbort functionality (section 9.1), it may=20 > end up in a situation where some sessions have=20 > TaskReporting=3DLegacy operational (Legacy sessions) while some=20 > other sessions have TaskReporting=3DFastAbort operational=20 > (FastAbort sessions) even while accessing a shared set of=20 > affected tasks (section 4.1.1). >=20 > If the issuing session is a Legacy session, iSCSI target=20 > implementation is FastAbort-capable and third-party affected=20 > session is a FastAbort session, the following behavior SHOULD=20 > be exhibited by the iSCSI target layer: > a. Between steps c and d of target behavior in section 4.1.2,=20 > send an Asynchronous Message PDU with AsyncEvent=3D5 (section=20 > 8.1) on each connection of each third-party session to which=20 > at least one affected task is allegiant. If there are=20 > multiple affected LUs, then send one Async Message PDU for=20 > each such LU on each connection that has at least one=20 > allegiant affected task. When sent, the LUN field in the=20 > Asynchronous Message PDU MUST be set to match the LUN for=20 > each such LU. > b. After step e of target behavior in section 4.1.2, free up=20 > the affected TTTs (and STags, if applicable) and the=20 > corresponding buffers, if any, once each associated Nop-Out=20 > acknowledgement is received that the third-party initiator=20 > generated in response to each Async Message sent in step a. >=20 > If the issuing session is a FastAbort session, iSCSI target=20 > implementation is FastAbort-capable and third-party affected=20 > session is a Legacy session, the following behavior MUST be=20 > exhibited by the iSCSI target layer: Asynchronous Message=20 > PDUs MUST NOT be sent on the third-party session to prompt=20 > the FastAbort behavior. >=20 >=20 > =20 > ______________________________________________________________ > ______________________ > It's here! Your new message! =20 > Get new email alerts with the free Yahoo! Toolbar. > http://tools.search.yahoo.com/toolbar/features/mail/ >=20 > _______________________________________________ > Ips mailing list > Ips@ietf.org > https://www1.ietf.org/mailman/listinfo/ips >=20 >=20 _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Fri Jan 26 17:13:10 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAZJb-0004Fn-EJ; Fri, 26 Jan 2007 17:12:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAZJZ-0004EY-ME for ips@ietf.org; Fri, 26 Jan 2007 17:12:57 -0500 Received: from web51911.mail.yahoo.com ([206.190.48.74]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HAZIX-0008TA-DD for ips@ietf.org; Fri, 26 Jan 2007 17:11:54 -0500 Received: (qmail 70223 invoked by uid 60001); 26 Jan 2007 22:11:46 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=FCWHl3McBiV8p++LOyA0pq7rLUaJem8GU1XRfOgoUhoAb3wgVYGGbiZ0X7peELwJwE65dECAm0xfwUAvEDi6TKNHbwL5ouy27Jojny3m2qt4pQklifzNao41RV5NZCD8TjM3cprq7V7N9WeF2bGwWk6ebGRAsScrKiJFNurSyAI=; X-YMail-OSG: lx_.9yIVM1llTBNSdIBzqg2M2iIgOwi1QVo7NpUc_ahwvDFG9Hynyr4GHC.HIuh3PUUQVRUAEIQusr5OOmNe4LZH3cDZo8WfANGyHb3kUsITtiDR96_ZPfzNzewYOaIRESoDsdzeSG2ZcuiWEXmAU3SZag-- Received: from [15.235.153.104] by web51911.mail.yahoo.com via HTTP; Fri, 26 Jan 2007 14:11:46 PST X-Mailer: YahooMailRC/368.3 YahooMailWebService/0.6.132.7 Date: Fri, 26 Jan 2007 14:11:46 -0800 (PST) From: "Mallikarjun C." To: ips@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Message-ID: <715651.68753.qm@web51911.mail.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Subject: [Ips] Re: Last Call Response Fence resolution X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ips-bounces@ietf.org David,=0A=0AOK. Didn't realize you were concerned about "flag", we may be = converging. Please take a look at the new text below.....=0A=0AMallikarjun= =0A=0A----- Original Message ----=0AFrom: "Black_David@emc.com" =0ATo: cb_mallikarjun@yahoo.com; ips@ietf.org=0ASent: Thursday, J= anuary 25, 2007 6:44:53 PM=0ASubject: RE: Last Call Response Fence resoluti= on (Was Re: [Ips] iSCSIImplementer's Guide - WG Last Call status, 2nd try)= =0A=0A=0AMallikarjun,=0A=0A> I am trying to preserve the notion of an iSCSI= -defined & =0A> iSCSI-scoped Response Fence in the text (you seem to be OK = =0A> with it). This gives us a convenient shorthand to refer to a =0A> set= of semantics. Besides, if/when T10 approves the response =0A> fence conce= pt for SAM-4, iSCSI implementers will know what to =0A> map it to for iSCSI= . As you'll see, I made it very clear in =0A> the new text that this is no= t an attempt to change SAM in =0A> this draft (which was of course never th= e intent).=0A=0AI agree in principle with the intent where "Response Fence"= is=0AiSCSI-scoped and defined "behavior." OTOH, calling it a "flag"=0Ais = a problem. I would prefer that all text anticipating=0Aaddition of a "flag= " to SAM-4 be removed, and in particular=0Athe following text:=0A=0A> the f= ollowing =0A> semantics are defined for a "Response Fence" flag if such a = =0A> flag were to qualify SCSI completion messages as they are =0A> handed = off from the SCSI protocol layer to the iSCSI layer. =0A> Note however tha= t [SAM2] does not model such a flag in its =0A> protocol interface model, s= o the "Response Fence" flag is an =0A> iSCSI-defined artifact for descripti= ve convenience of the =0A> mandatory iSCSI response ordering semantics.=0A= =0Awhich is just asking for an IETF Last Call comment or AD question=0Aabou= t why this circumlocution was used when it suffices to define=0Athe "Respon= se Fence" behavior without ever mentioning a non-=0Aexistent flag. Section= 3.3.3 doesn't need the flag - it can=0Arefer to the behavior and say what = it MUST be applied to.=0A=0AIf Rob succeeds in getting T10 to put a Respons= e Fence flag=0Ainto SAM-4, we can deal with that flag in the draft that=0Ad= eals with the impacts of SAM-3 and SAM-4 on iSCSI, which=0Awill have a numb= er of other things to deal with. Before anyone=0Agets excited about this, = I will state my view that the IETF=0Awill need to ensure that all such impa= cts are specified in a=0Afashion that is backwards compatible with RFC-3720= -only=0Aimplementations.=0A=0AThanks,=0A--David=0A-------------------------= ---------------------------=0ADavid L. Black, Senior Technologist=0AEMC Cor= poration, 176 South St., Hopkinton, MA 01748=0A+1 (508) 293-7953 = FAX: +1 (508) 293-7786=0Ablack_david@emc.com Mobile: +1 (978) 394= -7754=0A----------------------------------------------------=0A=0A=0A3.3 Mo= del Assumptions for Response Ordering=0AWhenever an iSCSI session is compos= ed of multiple connections, the Response PDUs (task responses or TMF respon= ses) originating in the target SCSI layer are distributed onto the multiple= connections by the target iSCSI layer according to iSCSI connection allegi= ance rules. This process generally may not preserve the ordering of the re= sponses by the time they are delivered to the initiator SCSI layer. Since = ordering is not expected across SCSI responses anyway, this approach works = fine in the general case. However to address the special cases where some = ordering is desired by the SCSI layer, the following "Response Fence" seman= tics are defined with respect to handling SCSI response messages as they ar= e handed off from the SCSI protocol layer to the iSCSI layer. =0A =0A3.3.1 = Model Description=0ATarget SCSI protocol layer hands off the SCSI response = messages to the target iSCSI layer by invoking the "Send Command Complete" = protocol data service ([SAM2], clause 5.4.2) and "Task Management Function = Executed" ([SAM2], clause 6.9) service. On receiving the SCSI response me= ssage, iSCSI layer exhibits the Response Fence behavior for certain SCSI re= sponse messages (section 3.3.3 describes the specific instances where the s= emantics must be realized). Whenever the Response Fence behavior is requir= ed for a SCSI response message, the target iSCSI layer MUST ensure that the= following conditions are met in delivering the response message to the ini= tiator iSCSI layer:=0A(1) Response with Response Fence MUST chronologically= be delivered after all the "preceding" responses on the I_T_L nexus, if th= e preceding responses are delivered at all, to the application client on th= e initiator. =0A(2) Response with Response Fence MUST chronologically be de= livered prior to all the "following" responses on the I_T_L nexus. =0AThe = =93preceding=94 and =93following=94 notions refer to the order of hand-off = of a response message from the target SCSI protocol layer to the target iSC= SI layer.=0A=0A3.3.2 iSCSI Semantics with the Interface Model=0AWhenever th= e TaskReporting key (section 9.1) is negotiated to ResponseFence or FastAbo= rt for an iSCSI session and the Response Fence behavior is required for a S= CSI response message, the target iSCSI layer MUST perform the actions descr= ibed in this section for that session.:=0Aa) If it is a single-connection s= ession, no special processing is required. Standard SCSI Response PDU buil= d and dispatch process happens. =0Ab) If it is a multi-connection session, = target iSCSI layer takes note of last-sent and unacknowledged StatSN on eac= h of the connections in the iSCSI session, and waits for acknowledgement (S= HOULD solicit for acknowledgement by way of a Nop-In) of each such StatSN t= o clear the fence. SCSI response with the Response Fence flag must be sent= to the initiator only after receiving acknowledgements for each of the una= cknowledged StatSNs.=0Ac) Target iSCSI layer must wait for an acknowledgeme= nt of the SCSI Response PDU that carried the response which the target SCSI= layer marked with the Response Fence flag. The fence must be considered c= leared after receiving the acknowledgement.=0Ad) All further status process= ing for the LU is resumed only after clearing the fence. If any new respon= ses for the I_T_L nexus are received from the SCSI layer before the fence i= s cleared, those Response PDUs must be held and queued at the iSCSI layer u= ntil the fence is cleared.=0A=0A3.3.3 Current List of Fenced Response Use C= ases=0A=0A--- No changes ----=0A=0A=0A =0A_________________________________= ___________________________________________________=0ABe a PS3 game guru.= =0AGet your game face on with the latest PS3 news and previews at Yahoo! Ga= mes.=0Ahttp://videogames.yahoo.com/platform?platform=3D120121 _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Fri Jan 26 17:30:22 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAZaI-0006AL-9G; Fri, 26 Jan 2007 17:30:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAZaH-0006AD-5l for ips@ietf.org; Fri, 26 Jan 2007 17:30:13 -0500 Received: from mx20.brocade.com ([66.243.153.19]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HAZaF-0003PC-RU for ips@ietf.org; Fri, 26 Jan 2007 17:30:13 -0500 Received: from discus.brocade.com ([192.168.126.240]) by mx20.brocade.com with ESMTP; 26 Jan 2007 14:30:09 -0800 X-IronPort-AV: i="4.13,244,1167638400"; d="scan'208"; a="5274236:sNHT16435118" Received: from HQ-EXCHFE-3.corp.brocade.com (hq-exchfeclus-2.brocade.com [192.168.126.212]) by discus.brocade.com (Postfix) with SMTP id B4609238399; Fri, 26 Jan 2007 14:28:21 -0800 (PST) Received: from hq-exch-1.corp.brocade.com ([10.3.8.21]) by HQ-EXCHFE-3.corp.brocade.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 26 Jan 2007 14:30:08 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ips] Re: Last Call Response Fence resolution Date: Fri, 26 Jan 2007 14:30:08 -0800 Message-ID: <6002A63FDB393D4F9ADB36DE70C4847501F8C5F4@hq-exch-1.corp.brocade.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ips] Re: Last Call Response Fence resolution thread-index: AcdBlzTtkBxI4fydSLiKQUig0Nq3FQAAGR2Q References: <715651.68753.qm@web51911.mail.yahoo.com> From: "Robert Snively" To: "Mallikarjun C." , X-OriginalArrivalTime: 26 Jan 2007 22:30:08.0935 (UTC) FILETIME=[891A4370:01C74199] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ips-bounces@ietf.org In the text below, there is one thing I am not sure I understand correctly. The text in 3.3.1, item 1 (and implicitly item 2) says that "MUST be chronologically delivered after all the preceding responses... to the application client on the initiator. Similarly in 3.3.2 item b) says "target iSCSI layer=20 takes note of last-sent and unacknowledged StatSN=20 on each of the connections in the iSCSI session, and=20 waits for acknowledgement (SHOULD solicit for=20 acknowledgement by way of a Nop-In) of each such=20 StatSN to clear the fence." Implicit in 3.3.2 is knowledge of the timing of delivery to the iSCSI layer, not necessarily to the "application client". I do not believe there is any defined time marker or pollable status available to a target that indicates when=20 delivery to the "application client" actually occurs that could be used to satisfy 3.3.1. This is the generic ordering question at the root of my continued concern about this approach. Since software constituting the application client (including kernel, OS, file system, application, etc.) must be designed to be tolerant of this ambiguity in any case, I believe we are spending a lot of effort creating an ordered case where the rare cases of misordering are already managed behavior. Bob ----- original text offered by Mallikarjun ----------------- =20 3.3.1 Model Description Target SCSI protocol layer hands off the SCSI response messages to the target iSCSI layer by invoking the "Send Command Complete" protocol data service ([SAM2], clause 5.4.2) and "Task Management Function Executed" ([SAM2], clause 6.9) service. On receiving the SCSI response message, iSCSI layer exhibits the Response Fence behavior for certain SCSI response messages (section 3.3.3 describes the specific instances where the semantics must be realized). Whenever the Response Fence behavior is required for a SCSI response message, the target iSCSI layer MUST ensure that the following conditions are met in delivering the response message to the initiator iSCSI layer: (1) Response with Response Fence MUST chronologically be delivered after all the "preceding" responses on the I_T_L nexus, if the preceding responses are delivered at all, to the application client on the initiator.=20 (2) Response with Response Fence MUST chronologically be delivered prior to all the "following" responses on the I_T_L nexus.=20 The "preceding" and "following" notions refer to the order of hand-off of a response message from the target SCSI protocol layer to the target iSCSI layer. 3.3.2 iSCSI Semantics with the Interface Model Whenever the TaskReporting key (section 9.1) is negotiated to ResponseFence or FastAbort for an iSCSI session and the Response Fence behavior is required for a SCSI response message, the target iSCSI layer MUST perform the actions described in this section for that session.: a) If it is a single-connection session, no special processing is required. Standard SCSI Response PDU build and dispatch process happens.=20 b) If it is a multi-connection session, target iSCSI layer takes note of last-sent and unacknowledged StatSN on each of the connections in the iSCSI session, and waits for acknowledgement (SHOULD solicit for acknowledgement by way of a Nop-In) of each such StatSN to clear the fence. SCSI response with the Response Fence flag must be sent to the initiator only after receiving acknowledgements for each of the unacknowledged StatSNs. c) Target iSCSI layer must wait for an acknowledgement of the SCSI Response PDU that carried the response which the target SCSI layer marked with the Response Fence flag. The fence must be considered cleared after receiving the acknowledgement. d) All further status processing for the LU is resumed only after clearing the fence. If any new responses for the I_T_L nexus are received from the SCSI layer before the fence is cleared, those Response PDUs must be held and queued at the iSCSI layer until the fence is cleared. _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Fri Jan 26 17:40:40 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAZkN-0002s5-VY; Fri, 26 Jan 2007 17:40:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAZkM-0002s0-Sg for ips@ietf.org; Fri, 26 Jan 2007 17:40:38 -0500 Received: from web51910.mail.yahoo.com ([206.190.48.73]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HAZkL-0004eo-HB for ips@ietf.org; Fri, 26 Jan 2007 17:40:38 -0500 Received: (qmail 14952 invoked by uid 60001); 26 Jan 2007 22:40:37 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=rIg+hmVMiR3lu75EoWZa2ytdxfnyKcPITqZDzoSaknmqXrgi7hqbFhM3aByhDR/4xBhSlF5RyGMtYyecGluolfqh4uYNX9EJTkp6NyOd7/hwMvRY2zRkqkGHALdb20FbVZXq+Q30l3o7Glg/nrtuJsqqQuEGX5L4iw3gzdZ1AK4=; X-YMail-OSG: 3c6EUaYVM1k1e425g8sACzTcTQvNyppZM17XpR17PM8ELjoVQHa8GXSP4Lbk80WnkOs8NBYNqFk166zWJ1hwqr0f897Zd_0tV.A87f33YjVbE.JHsUhhugFgaeq5B6SGgSN8SswKbsrheSDlO8B6Yxd4E3GCceZh0YEOOzUV.KLXiMbZIaMb.w33eTqZ Received: from [15.235.153.104] by web51910.mail.yahoo.com via HTTP; Fri, 26 Jan 2007 14:40:37 PST X-Mailer: YahooMailRC/368.3 YahooMailWebService/0.6.132.7 Date: Fri, 26 Jan 2007 14:40:36 -0800 (PST) From: "Mallikarjun C." Subject: Re: [Ips] Re: Last Call TMF resolution To: ips@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Message-ID: <48217.12619.qm@web51910.mail.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ips-bounces@ietf.org David,=0A=0ALegacy->RFC3720 change done. Latest text is attached below. = =0A=0AAFAICT, initiator behavior parenthetical text under 4.1.3 bullet-c is= what you are suggesting we clarify in 4.1.4. =0A"this step also applies wh= en the initiator is receiving the Async Message in the third-party role"=0A= =0ABut let me know if that isn't the case.=0A=0AThanks.=0A=0AMallikarjun=0A= =0A=0A----- Original Message ----=0AFrom: "Black_David@emc.com" =0ATo: cb_mallikarjun@yahoo.com; ips@ietf.org=0ASent: Friday, Jan= uary 26, 2007 2:02:34 PM=0ASubject: RE: [Ips] Re: Last Call TMF resolution= =0A=0A=0AI think I see some of where I'm confused. 4.1.2 and 4.1.3 are=0Aa= bout what the initiator that sent the TMF does as well as the=0Atarget. We= need to explain what a 3rd-party initiator does,=0Awhich for a 3720-only i= nitiator is unchanged. I think your=0Anew 4.1.4 is headed towards covering= this in addition to the=0ATarget behavior in a mixed FastAbort/non-FastAbo= rt case.=0A=0AOne crucial point that needs=0Ato be made is that a FastAbort= initiator may get an AsyncEvent=3D5=0Amessage out of the blue if some othe= r initiator, even a Legacy=0Ainitiator, issues a TMF that affects the FastA= bort initiator's=0Atasks, even if the iSCSI session only contains a single = TCP=0Aconnection (FastAbort initiator will never get AsyncEvent=3D5=0Amessa= ges for its own TMFs on a single connection session).=0A=0AOn another minor= note, "Legacy" as a key value seems pejorative=0Ato me. "RFC3720" would be= neutral and in fact more descriptive=0Aof what's actually going on.=0A=0AT= hanks,=0A--David=0A=0A4.1.3 Updated multi-task abort semantics=0AProtocol b= ehavior defined in this section MUST be implemented by all iSCSI implementa= tions complying with this document. Protocol behavior defined in this sect= ion MUST be exhibited by iSCSI implementations on an iSCSI session when the= y negotiate the TaskReporting (section 9.1) key to =93FastAbort=94 on that = session. The execution of ABORT TASK SET, CLEAR TASK SET, LOGICAL UNIT RES= ET, TARGET WARM RESET, and TARGET COLD RESET TMF Requests consists of the f= ollowing sequence of actions in the specified order on the specified party.= =0AThe initiator iSCSI layer:=0Aa. MUST NOT send any more Data-Out PDUs fo= r affected tasks on the issuing connection of the issuing iSCSI session onc= e the TMF is sent to the target.=0Ab. Should receive any responses that the= target may provide for some tasks among the affected tasks (may process th= em as usual because they are guaranteed to have chronologically originated = prior to the TMF response).=0Ac. MUST respond to each Async Message PDU wit= h AsyncEvent=3D5 as defined in section 8.1 (this step also applies when the= initiator is receiving the Async Message in the third-party role).=0Ad. Sh= ould receive the TMF Response concluding all the tasks in the set of affect= ed tasks.=0A=0AThe target iSCSI layer:=0Aa. MUST wait for all commands of t= he affected tasks to be received based on the CmdSN ordering on the issuing= session. SHOULD NOT wait for new commands on third-party affected session= s - only the instantiated tasks have to be considered for the purpose of de= termining the affected tasks. In the case of target-scoped requests (i.e. = TARGET WARM RESET and TARGET COLD RESET), all the commands that are not yet= received on the issuing session in the command stream can be considered to= have been received with no command waiting period - i.e. the entire CmdSN = space up to the CmdSN of the task management function can be "plugged".=0Ab= . MUST propagate the TMF request to and receive the response from the targe= t SCSI layer. =0Ac. MUST leave all active "affected TTTs" (i.e. active TTTs= associated with affected tasks) valid.=0Ad. MUST send an Asynchronous Mess= age PDU with AsyncEvent=3D5 (section 8.1) on:=0Ai) each connection of each = third-party session to which at least one affected task is allegiant if Tas= kReporting=3DFastAbort is operational on that third-party session, and=0Aii= ) each connection except the issuing connection of the issuing session that= has at least one allegiant affected task.=0AIf there are multiple affected= LUs (say due to a target reset), then one Async Message PDU MUST be sent f= or each such LU on each connection that has at least one allegiant affected= task. The LUN field in the Asynchronous Message PDU MUST be set to match = the LUN for each such LU.=0Ae. MUST address the Response Fence flag on the = TMF Response on issuing session as defined in 3.3.2.=0Af. MUST address the = Response Fence flag on the first post-TMF Response on third-party sessions = as defined in 3.3.2. If some tasks originate from non-iSCSI I_T_L nexuses t= hen the means by which the target ensures that all affected tasks have retu= rned their status to the initiator are defined by the specific non-iSCSI tr= ansport protocol(s).=0Ag. MUST free up the affected TTTs (and STags, if app= licable) and the corresponding buffers, if any, once it receives each assoc= iated Nop-Out acknowledgement that the initiator generated in response to e= ach Async Message. =0AImplementation note: Technically, the TMF servicing = is complete in Step.e. Data transfers corresponding to terminated tasks ma= y however still be in progress even at the end of Step.f. TMF Response MUS= T NOT be sent by the target iSCSI layer before the end of Step.e, and MAY b= e sent at the end of Step.e despite these outstanding Data transfers until = Step.g. Step.g specifies an event to free up any such resources that may h= ave been reserved to support outstanding data transfers. =0A=0A4.1.3.1 Cle= aring effects update=0A---No changes -----=0A=0A4.1.4 Affected tasks shared= across RFC3720 & FastAbort sessions=0AIf an iSCSI target implementation is= capable of supporting TaskReporting=3DFastAbort functionality (section 9.1= ), it may end up in a situation where some sessions have TaskReporting=3DRF= C3720 operational (RFC3720 sessions) while some other sessions have TaskRep= orting=3DFastAbort operational (FastAbort sessions) even while accessing a = shared set of affected tasks (section 4.1.1).=0AIf the issuing session is a= RFC3720 session, iSCSI target implementation is FastAbort-capable and thir= d-party affected session is a FastAbort session, the following behavior SHO= ULD be exhibited by the iSCSI target layer:=0Aa. Between steps c and d of t= arget behavior in section 4.1.2, send an Asynchronous Message PDU with Asyn= cEvent=3D5 (section 8.1) on each connection of each third-party session to = which at least one affected task is allegiant. If there are multiple affec= ted LUs, then send one Async Message PDU for each such LU on each connectio= n that has at least one allegiant affected task. When sent, the LUN field = in the Asynchronous Message PDU MUST be set to match the LUN for each such = LU.=0Ab. After step e of target behavior in section 4.1.2, free up the affe= cted TTTs (and STags, if applicable) and the corresponding buffers, if any,= once each associated Nop-Out acknowledgement is received that the third-pa= rty initiator generated in response to each Async Message sent in step a.= =0AIf the issuing session is a FastAbort session, iSCSI target implementati= on is FastAbort-capable and third-party affected session is a RFC3720 sessi= on, the following behavior MUST be exhibited by the iSCSI target layer: Asy= nchronous Message PDUs MUST NOT be sent on the third-party session to promp= t the FastAbort behavior.=0A=0A=0A =0A_____________________________________= _______________________________________________=0AThe fish are biting. =0AG= et more visitors on your site using Yahoo! Search Marketing.=0Ahttp://searc= hmarketing.yahoo.com/arp/sponsoredsearch_v2.php _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Fri Jan 26 17:58:33 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAa1Y-0007VT-JL; Fri, 26 Jan 2007 17:58:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAa1X-0007VN-UJ for ips@ietf.org; Fri, 26 Jan 2007 17:58:23 -0500 Received: from mexforward.lss.emc.com ([128.222.32.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HAa1W-0007a0-H8 for ips@ietf.org; Fri, 26 Jan 2007 17:58:23 -0500 Received: from mailhub.lss.emc.com (sesha.lss.emc.com [10.254.144.12]) by mexforward.lss.emc.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id l0QMwLnI023849; Fri, 26 Jan 2007 17:58:21 -0500 (EST) Received: from corpussmtp3.corp.emc.com (corpussmtp3.corp.emc.com [10.254.64.53]) by mailhub.lss.emc.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id l0QMvaZ8023484; Fri, 26 Jan 2007 17:58:19 -0500 (EST) From: Black_David@emc.com Received: from CORPUSMX20A.corp.emc.com ([128.221.62.13]) by corpussmtp3.corp.emc.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 26 Jan 2007 17:57:36 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ips] Re: Last Call Response Fence resolution Date: Fri, 26 Jan 2007 17:57:36 -0500 Message-ID: In-Reply-To: <6002A63FDB393D4F9ADB36DE70C4847501F8C5F4@hq-exch-1.corp.brocade.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ips] Re: Last Call Response Fence resolution Thread-Index: AcdBlzTtkBxI4fydSLiKQUig0Nq3FQAAGR2QAACxumA= References: <715651.68753.qm@web51911.mail.yahoo.com> <6002A63FDB393D4F9ADB36DE70C4847501F8C5F4@hq-exch-1.corp.brocade.com> To: , X-OriginalArrivalTime: 26 Jan 2007 22:57:36.0738 (UTC) FILETIME=[5F450C20:01C7419D] X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.5.0.283055, Antispam-Data: 2007.1.26.143933 X-PerlMx-Spam: Gauge=, SPAM=0%, Reason='EMC_BODY_1+ -3, EMC_FROM_0+ -2, NO_REAL_NAME 0, __C230066_P2 0, __C230066_P5 0, __CT 0, __CTE 0, __CTYPE_CHARSET_QUOTED 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __IMS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.2 (/) X-Scan-Signature: 8f374d0786b25a451ef87d82c076f593 Cc: X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ips-bounces@ietf.org Bob, > Implicit in 3.3.2 is knowledge of the timing of delivery > to the iSCSI layer, not necessarily to the "application > client". I do not believe there is any defined time marker > or pollable status available to a target that indicates when=20 > delivery to the "application client" actually occurs that > could be used to satisfy 3.3.1. This is the > generic ordering question at the root of my continued > concern about this approach. For 3.3.2, I don't think that's not correct, at least not to the degree you've stretched it. What's going on is an assumption that any local delivery event of interest will have occurred well before the round trip from initiator to target (acknowledge status) and back (target does something as a consequence of that acknowledgement). Based on that assumption, the target's record of acknowledged status is being used to drive the sequencing. If one is in a situation where the assumption is false (e.g., app client is a low priority user process for which the OS does not maintain an ordered event queue, allowing event reordering over periods of time on the order of an iSCSI round trip), then I would actually recommend that multi-connection iSCSI sessions not be used, because the corresponding reordering of commands is going to cause target-side holes in the CmdSN sequence. I also believe the example I used is indicative of an OS shortcoming, and is not at all typical. For typical situations, I believe the assumption holds, the fence property is useful, and the "pollable status" that drives everything is the target's tracking of the acknowledged StatSN's. iSCSI doesn't use time markers. Thanks, --David ---------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- > -----Original Message----- > From: Robert Snively [mailto:rsnively@Brocade.COM]=20 > Sent: Friday, January 26, 2007 5:30 PM > To: Mallikarjun C.; ips@ietf.org > Subject: RE: [Ips] Re: Last Call Response Fence resolution >=20 > In the text below, there is one thing I am not sure > I understand correctly. The text in 3.3.1, item 1 (and > implicitly item 2) says that "MUST be chronologically > delivered after all the preceding responses... to the > application client on the initiator. >=20 > Similarly in 3.3.2 item b) says "target iSCSI layer=20 > takes note of last-sent and unacknowledged StatSN=20 > on each of the connections in the iSCSI session, and=20 > waits for acknowledgement (SHOULD solicit for=20 > acknowledgement by way of a Nop-In) of each such=20 > StatSN to clear the fence." >=20 > Implicit in 3.3.2 is knowledge of the timing of delivery > to the iSCSI layer, not necessarily to the "application > client". I do not believe there is any defined time marker > or pollable status available to a target that indicates when=20 > delivery to the "application client" actually occurs that > could be used to satisfy 3.3.1. This is the > generic ordering question at the root of my continued > concern about this approach. >=20 > Since software constituting the application client (including > kernel, OS, file system, application, etc.) must be designed > to be tolerant of this ambiguity in any case, I believe we > are spending a lot of effort creating an ordered case where > the rare cases of misordering are already managed behavior. >=20 > Bob >=20 > ----- original text offered by Mallikarjun ----------------- > =20 > 3.3.1 Model Description > Target SCSI protocol layer hands off the SCSI response messages to the > target iSCSI layer by invoking the "Send Command Complete"=20 > protocol data > service ([SAM2], clause 5.4.2) and "Task Management Function Executed" > ([SAM2], clause 6.9) service. On receiving the SCSI=20 > response message, > iSCSI layer exhibits the Response Fence behavior for certain SCSI > response messages (section 3.3.3 describes the specific=20 > instances where > the semantics must be realized). Whenever the Response Fence behavior > is required for a SCSI response message, the target iSCSI layer MUST > ensure that the following conditions are met in delivering=20 > the response > message to the initiator iSCSI layer: > (1) Response with Response Fence MUST chronologically be=20 > delivered after > all the "preceding" responses on the I_T_L nexus, if the preceding > responses are delivered at all, to the application client on the > initiator.=20 > (2) Response with Response Fence MUST chronologically be=20 > delivered prior > to all the "following" responses on the I_T_L nexus.=20 > The "preceding" and "following" notions refer to the order of hand-off > of a response message from the target SCSI protocol layer to=20 > the target > iSCSI layer. >=20 > 3.3.2 iSCSI Semantics with the Interface Model > Whenever the TaskReporting key (section 9.1) is negotiated to > ResponseFence or FastAbort for an iSCSI session and the Response Fence > behavior is required for a SCSI response message, the target=20 > iSCSI layer > MUST perform the actions described in this section for that session.: > a) If it is a single-connection session, no special processing is > required. Standard SCSI Response PDU build and dispatch process > happens.=20 > b) If it is a multi-connection session, target iSCSI layer=20 > takes note of > last-sent and unacknowledged StatSN on each of the connections in the > iSCSI session, and waits for acknowledgement (SHOULD solicit for > acknowledgement by way of a Nop-In) of each such StatSN to clear the > fence. SCSI response with the Response Fence flag must be sent to the > initiator only after receiving acknowledgements for each of the > unacknowledged StatSNs. > c) Target iSCSI layer must wait for an acknowledgement of the SCSI > Response PDU that carried the response which the target SCSI layer > marked with the Response Fence flag. The fence must be considered > cleared after receiving the acknowledgement. > d) All further status processing for the LU is resumed only after > clearing the fence. If any new responses for the I_T_L nexus are > received from the SCSI layer before the fence is cleared,=20 > those Response > PDUs must be held and queued at the iSCSI layer until the fence is > cleared. >=20 > _______________________________________________ > Ips mailing list > Ips@ietf.org > https://www1.ietf.org/mailman/listinfo/ips >=20 >=20 _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Fri Jan 26 18:06:26 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAa91-0003Gh-LF; Fri, 26 Jan 2007 18:06:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAa8z-0003GT-T0 for ips@ietf.org; Fri, 26 Jan 2007 18:06:05 -0500 Received: from web51909.mail.yahoo.com ([206.190.48.72]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HAa8y-0000EC-Ic for ips@ietf.org; Fri, 26 Jan 2007 18:06:05 -0500 Received: (qmail 69603 invoked by uid 60001); 26 Jan 2007 23:06:04 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=MsGG7DSwJoLurZJTJm1Y0iqLvSovM1FGKG/mA86ar+bPdvYBw6GaoYYubplhE9t5AkAGEpiC4LxINkeqp+Nb7yhfV9kEjNkicRQDhO2iCZr8kCre5qPhh3HUVIkYWkquxgbhC0WLvqHTdaadxhlKd+0fMVIi8rWFReBLolmvJhY= ; Message-ID: <20070126230604.69601.qmail@web51909.mail.yahoo.com> X-YMail-OSG: 0ApTIugVM1m_doWIDc4Bl5R.KoOYlChI0041sm9BamzC2y3p5IwuhJoObcyAY3gQaA-- Received: from [15.235.153.104] by web51909.mail.yahoo.com via HTTP; Fri, 26 Jan 2007 15:06:04 PST X-Mailer: YahooMailRC/368.3 YahooMailWebService/0.6.132.7 Date: Fri, 26 Jan 2007 15:06:04 -0800 (PST) From: "Mallikarjun C." Subject: Re: [Ips] Re: Last Call Response Fence resolution To: ips@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ips-bounces@ietf.org Bob,=0A=0AGood feedback. I will change "application client" to "initiator = iSCSI layer". It was an oversight from the days of generic early text.=0A= =0AUnderstood that there may be other software/firmware layers above iSCSI = with their own ordering considerations. Obviously, they are beyond the sco= pe of this draft. The intent behind the text in this draft is to specify t= he proper iSCSI semantics that will facilitate building a well-behaved appl= ication client with predictable ordering, but not to demand that all initia= tor layers change. This is essentially continuing the ordering philosophy = of RFC 3720 multi-connection sessions.=0A=0AMallikarjun=0A=0A=0A----- Origi= nal Message ----=0AFrom: Robert Snively =0ATo: Mallik= arjun C. ; ips@ietf.org=0ASent: Friday, January 2= 6, 2007 2:30:08 PM=0ASubject: RE: [Ips] Re: Last Call Response Fence resolu= tion=0A=0A=0AIn the text below, there is one thing I am not sure=0AI unders= tand correctly. The text in 3.3.1, item 1 (and=0Aimplicitly item 2) says t= hat "MUST be chronologically=0Adelivered after all the preceding responses.= .. to the=0Aapplication client on the initiator.=0A=0ASimilarly in 3.3.2 it= em b) says "target iSCSI layer =0Atakes note of last-sent and unacknowledge= d StatSN =0Aon each of the connections in the iSCSI session, and =0Awaits f= or acknowledgement (SHOULD solicit for =0Aacknowledgement by way of a Nop-I= n) of each such =0AStatSN to clear the fence."=0A=0AImplicit in 3.3.2 is kn= owledge of the timing of delivery=0Ato the iSCSI layer, not necessarily to = the "application=0Aclient". I do not believe there is any defined time mar= ker=0Aor pollable status available to a target that indicates when =0Adeliv= ery to the "application client" actually occurs that=0Acould be used to sat= isfy 3.3.1. This is the=0Ageneric ordering question at the root of my cont= inued=0Aconcern about this approach.=0A=0ASince software constituting the a= pplication client (including=0Akernel, OS, file system, application, etc.) = must be designed=0Ato be tolerant of this ambiguity in any case, I believe = we=0Aare spending a lot of effort creating an ordered case where=0Athe rare= cases of misordering are already managed behavior.=0A=0ABob=0A=0A----- or= iginal text offered by Mallikarjun -----------------=0A=0A3.3.1 Model Desc= ription=0ATarget SCSI protocol layer hands off the SCSI response messages t= o the=0Atarget iSCSI layer by invoking the "Send Command Complete" protocol= data=0Aservice ([SAM2], clause 5.4.2) and "Task Management Function Execut= ed"=0A([SAM2], clause 6.9) service. On receiving the SCSI response messag= e,=0AiSCSI layer exhibits the Response Fence behavior for certain SCSI=0Are= sponse messages (section 3.3.3 describes the specific instances where=0Athe= semantics must be realized). Whenever the Response Fence behavior=0Ais re= quired for a SCSI response message, the target iSCSI layer MUST=0Aensure th= at the following conditions are met in delivering the response=0Amessage to= the initiator iSCSI layer:=0A(1) Response with Response Fence MUST chronol= ogically be delivered after=0Aall the "preceding" responses on the I_T_L ne= xus, if the preceding=0Aresponses are delivered at all, to the application = client on the=0Ainitiator. =0A(2) Response with Response Fence MUST chronol= ogically be delivered prior=0Ato all the "following" responses on the I_T_L= nexus. =0AThe "preceding" and "following" notions refer to the order of ha= nd-off=0Aof a response message from the target SCSI protocol layer to the t= arget=0AiSCSI layer.=0A=0A3.3.2 iSCSI Semantics with the Interface Model=0A= Whenever the TaskReporting key (section 9.1) is negotiated to=0AResponseFen= ce or FastAbort for an iSCSI session and the Response Fence=0Abehavior is r= equired for a SCSI response message, the target iSCSI layer=0AMUST perform = the actions described in this section for that session.:=0Aa) If it is a si= ngle-connection session, no special processing is=0Arequired. Standard SCS= I Response PDU build and dispatch process=0Ahappens. =0Ab) If it is a multi= -connection session, target iSCSI layer takes note of=0Alast-sent and unack= nowledged StatSN on each of the connections in the=0AiSCSI session, and wai= ts for acknowledgement (SHOULD solicit for=0Aacknowledgement by way of a No= p-In) of each such StatSN to clear the=0Afence. SCSI response with the Res= ponse Fence flag must be sent to the=0Ainitiator only after receiving ackno= wledgements for each of the=0Aunacknowledged StatSNs.=0Ac) Target iSCSI lay= er must wait for an acknowledgement of the SCSI=0AResponse PDU that carried= the response which the target SCSI layer=0Amarked with the Response Fence = flag. The fence must be considered=0Acleared after receiving the acknowled= gement.=0Ad) All further status processing for the LU is resumed only after= =0Aclearing the fence. If any new responses for the I_T_L nexus are=0Arece= ived from the SCSI layer before the fence is cleared, those Response=0APDUs= must be held and queued at the iSCSI layer until the fence is=0Acleared.= =0A=0A=0A =0A______________________________________________________________= ______________________=0ABored stiff? Loosen up... =0ADownload and play hun= dreds of games for free on Yahoo! Games.=0Ahttp://games.yahoo.com/games/fro= nt _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From mkippsylzm@imprentablanca.com Fri Jan 26 18:40:23 2007 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAagB-0005Bu-71 for ips-archive@lists.ietf.org; Fri, 26 Jan 2007 18:40:23 -0500 Received: from e181008091.adsl.alicedsl.de ([85.181.8.91]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HAag9-0006Dk-FZ for ips-archive@lists.ietf.org; Fri, 26 Jan 2007 18:40:23 -0500 Reply-To: "Alice Sheffield" From: "Alice" Message-ID: <2473023017.583613649876@imprentablanca.com> Date: Fri, 26 Jan 2007 17:41:26 -0600 To: Subject: Adobe Acrobat 8.0 ready to download MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Spam-Score: 4.2 (++++) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Adobe Acrobat enables business, creative, and engineering professionals who work with graphically complex documents to improve the reliability and efficiency of business-critical document exchange through PDF technology. Adobe Acrobat 8.0 Professional has the following features in addition to the features found in the standard version: Create PDF documents with one-button ease from AutoCAD, Microsoft Visio, and Microsoft Project (Windows only); Preserve document layers in technical drawings in Visio and AutoCAD, and object data in Visio (Windows only); Permanently delete sensitive information, including specific text or illustrations, with redaction tools; Create fillable PDF forms from scanned paper, existing PDF documents, Microsoft Word documents, or Excel spreadsheets; Automatically recognize form fields on static PDF documents and convert them to interactive fields that can be filled electronically by anyone using free Adobe Reader versions 7 or 8; Enable Adobe Reader (versions 7 or 8) users to participate in reviews with complete commenting and markup tools, including sticky notes, highlighter, lines, shapes, and stamps; Enable Adobe Reader (versions 7 or 8) users to fill and save PDF forms locally for offline use, and to digitally sign PDF documents. Adobe Acrobat 8.0 Professional Retail Price $449.00 Our Price $79.95 You save $369.05 http://superintorio.org Please note, that there will be more special offers available for our constant customers. Every effort has been made to ensure the accuracy of all information contained herein. DS Team makes no warranty expressed or implied with respect to accuracy of the information, including price, product editorials or product specifications. Product and manufacturer names are used only for the purpose of identification. We appreciate your cooperation with us and we'll be glad to see you as our clients in the future. From ips-bounces@ietf.org Fri Jan 26 20:57:08 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAco3-0002kx-EZ; Fri, 26 Jan 2007 20:56:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAco1-0002kR-PA for ips@ietf.org; Fri, 26 Jan 2007 20:56:37 -0500 Received: from mexforward.lss.emc.com ([128.222.32.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HAco0-00030a-9u for ips@ietf.org; Fri, 26 Jan 2007 20:56:37 -0500 Received: from mailhub.lss.emc.com (nagas.lss.emc.com [10.254.144.11]) by mexforward.lss.emc.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id l0R1uZN5023261; Fri, 26 Jan 2007 20:56:36 -0500 (EST) Received: from corpussmtp4.corp.emc.com (corpussmtp4.corp.emc.com [10.254.64.54]) by mailhub.lss.emc.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id l0R1uXVw019542; Fri, 26 Jan 2007 20:56:33 -0500 (EST) From: Black_David@emc.com Received: from CORPUSMX20A.corp.emc.com ([128.221.62.13]) by corpussmtp4.corp.emc.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 26 Jan 2007 20:56:33 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ips] Re: Last Call Response Fence resolution Date: Fri, 26 Jan 2007 20:56:32 -0500 Message-ID: In-Reply-To: <715651.68753.qm@web51911.mail.yahoo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ips] Re: Last Call Response Fence resolution Thread-Index: AcdBlzlXpSRzN8kCR/2/mSeMeCiFegAHxC6g References: <715651.68753.qm@web51911.mail.yahoo.com> To: , X-OriginalArrivalTime: 27 Jan 2007 01:56:33.0463 (UTC) FILETIME=[5EDB4470:01C741B6] X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.5.0.283055, Antispam-Data: 2007.1.26.174433 X-PerlMx-Spam: Gauge=, SPAM=0%, Reason='EMC_BODY_1+ -3, EMC_FROM_0+ -2, NO_REAL_NAME 0, __C230066_P5 0, __CP_URI_IN_BODY 0, __CT 0, __CTE 0, __CTYPE_CHARSET_QUOTED 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __IMS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.2 (/) X-Scan-Signature: 7e439b86d3292ef5adf93b694a43a576 Cc: X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ips-bounces@ietf.org I think that text is ok, as the remaining SAM2 references serve as justification for talking about the interface between SCSI and iSCSI. Thanks, --David > -----Original Message----- > From: Mallikarjun C. [mailto:cb_mallikarjun@yahoo.com]=20 > Sent: Friday, January 26, 2007 5:12 PM > To: ips@ietf.org > Subject: [Ips] Re: Last Call Response Fence resolution >=20 > David, >=20 > OK. Didn't realize you were concerned about "flag", we may=20 > be converging. Please take a look at the new text below..... >=20 > Mallikarjun >=20 > ----- Original Message ---- > From: "Black_David@emc.com" > To: cb_mallikarjun@yahoo.com; ips@ietf.org > Sent: Thursday, January 25, 2007 6:44:53 PM > Subject: RE: Last Call Response Fence resolution (Was Re:=20 > [Ips] iSCSIImplementer's Guide - WG Last Call status, 2nd try) >=20 >=20 > Mallikarjun, >=20 > > I am trying to preserve the notion of an iSCSI-defined &=20 > > iSCSI-scoped Response Fence in the text (you seem to be OK=20 > > with it). This gives us a convenient shorthand to refer to a=20 > > set of semantics. Besides, if/when T10 approves the response=20 > > fence concept for SAM-4, iSCSI implementers will know what to=20 > > map it to for iSCSI. As you'll see, I made it very clear in=20 > > the new text that this is not an attempt to change SAM in=20 > > this draft (which was of course never the intent). >=20 > I agree in principle with the intent where "Response Fence" is > iSCSI-scoped and defined "behavior." OTOH, calling it a "flag" > is a problem. I would prefer that all text anticipating > addition of a "flag" to SAM-4 be removed, and in particular > the following text: >=20 > > the following=20 > > semantics are defined for a "Response Fence" flag if such a=20 > > flag were to qualify SCSI completion messages as they are=20 > > handed off from the SCSI protocol layer to the iSCSI layer. =20 > > Note however that [SAM2] does not model such a flag in its=20 > > protocol interface model, so the "Response Fence" flag is an=20 > > iSCSI-defined artifact for descriptive convenience of the=20 > > mandatory iSCSI response ordering semantics. >=20 > which is just asking for an IETF Last Call comment or AD question > about why this circumlocution was used when it suffices to define > the "Response Fence" behavior without ever mentioning a non- > existent flag. Section 3.3.3 doesn't need the flag - it can > refer to the behavior and say what it MUST be applied to. >=20 > If Rob succeeds in getting T10 to put a Response Fence flag > into SAM-4, we can deal with that flag in the draft that > deals with the impacts of SAM-3 and SAM-4 on iSCSI, which > will have a number of other things to deal with. Before anyone > gets excited about this, I will state my view that the IETF > will need to ensure that all such impacts are specified in a > fashion that is backwards compatible with RFC-3720-only > implementations. >=20 > Thanks, > --David > ---------------------------------------------------- > David L. Black, Senior Technologist > EMC Corporation, 176 South St., Hopkinton, MA 01748 > +1 (508) 293-7953 FAX: +1 (508) 293-7786 > black_david@emc.com Mobile: +1 (978) 394-7754 > ---------------------------------------------------- >=20 >=20 > 3.3 Model Assumptions for Response Ordering > Whenever an iSCSI session is composed of multiple=20 > connections, the Response PDUs (task responses or TMF=20 > responses) originating in the target SCSI layer are=20 > distributed onto the multiple connections by the target iSCSI=20 > layer according to iSCSI connection allegiance rules. This=20 > process generally may not preserve the ordering of the=20 > responses by the time they are delivered to the initiator=20 > SCSI layer. Since ordering is not expected across SCSI=20 > responses anyway, this approach works fine in the general=20 > case. However to address the special cases where some=20 > ordering is desired by the SCSI layer, the following=20 > "Response Fence" semantics are defined with respect to=20 > handling SCSI response messages as they are handed off from=20 > the SCSI protocol layer to the iSCSI layer.=20 > =20 > 3.3.1 Model Description > Target SCSI protocol layer hands off the SCSI response=20 > messages to the target iSCSI layer by invoking the "Send=20 > Command Complete" protocol data service ([SAM2], clause=20 > 5.4.2) and "Task Management Function Executed" ([SAM2],=20 > clause 6.9) service. On receiving the SCSI response=20 > message, iSCSI layer exhibits the Response Fence behavior for=20 > certain SCSI response messages (section 3.3.3 describes the=20 > specific instances where the semantics must be realized). =20 > Whenever the Response Fence behavior is required for a SCSI=20 > response message, the target iSCSI layer MUST ensure that the=20 > following conditions are met in delivering the response=20 > message to the initiator iSCSI layer: > (1) Response with Response Fence MUST chronologically be=20 > delivered after all the "preceding" responses on the I_T_L=20 > nexus, if the preceding responses are delivered at all, to=20 > the application client on the initiator.=20 > (2) Response with Response Fence MUST chronologically be=20 > delivered prior to all the "following" responses on the I_T_L nexus.=20 > The "preceding" and "following" notions refer to the order of=20 > hand-off of a response message from the target SCSI protocol=20 > layer to the target iSCSI layer. >=20 > 3.3.2 iSCSI Semantics with the Interface Model > Whenever the TaskReporting key (section 9.1) is negotiated to=20 > ResponseFence or FastAbort for an iSCSI session and the=20 > Response Fence behavior is required for a SCSI response=20 > message, the target iSCSI layer MUST perform the actions=20 > described in this section for that session.: > a) If it is a single-connection session, no special=20 > processing is required. Standard SCSI Response PDU build and=20 > dispatch process happens.=20 > b) If it is a multi-connection session, target iSCSI layer=20 > takes note of last-sent and unacknowledged StatSN on each of=20 > the connections in the iSCSI session, and waits for=20 > acknowledgement (SHOULD solicit for acknowledgement by way of=20 > a Nop-In) of each such StatSN to clear the fence. SCSI=20 > response with the Response Fence flag must be sent to the=20 > initiator only after receiving acknowledgements for each of=20 > the unacknowledged StatSNs. > c) Target iSCSI layer must wait for an acknowledgement of the=20 > SCSI Response PDU that carried the response which the target=20 > SCSI layer marked with the Response Fence flag. The fence=20 > must be considered cleared after receiving the acknowledgement. > d) All further status processing for the LU is resumed only=20 > after clearing the fence. If any new responses for the I_T_L=20 > nexus are received from the SCSI layer before the fence is=20 > cleared, those Response PDUs must be held and queued at the=20 > iSCSI layer until the fence is cleared. >=20 > 3.3.3 Current List of Fenced Response Use Cases >=20 > --- No changes ---- >=20 >=20 > =20 > ______________________________________________________________ > ______________________ > Be a PS3 game guru. > Get your game face on with the latest PS3 news and previews=20 > at Yahoo! Games. > http://videogames.yahoo.com/platform?platform=3D120121 >=20 > _______________________________________________ > Ips mailing list > Ips@ietf.org > https://www1.ietf.org/mailman/listinfo/ips >=20 >=20 _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From ips-bounces@ietf.org Fri Jan 26 21:14:13 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAd4c-0004Ap-HE; Fri, 26 Jan 2007 21:13:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAd4b-0004Aj-Ai for ips@ietf.org; Fri, 26 Jan 2007 21:13:45 -0500 Received: from mexforward.lss.emc.com ([128.222.32.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HAd4a-0006hW-Sv for ips@ietf.org; Fri, 26 Jan 2007 21:13:45 -0500 Received: from mailhub.lss.emc.com (nagas.lss.emc.com [10.254.144.11]) by mexforward.lss.emc.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id l0R2Dgt3010372; Fri, 26 Jan 2007 21:13:42 -0500 (EST) Received: from corpussmtp3.corp.emc.com (corpussmtp3.corp.emc.com [10.254.64.53]) by mailhub.lss.emc.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id l0R2DesV023504; Fri, 26 Jan 2007 21:13:40 -0500 (EST) From: Black_David@emc.com Received: from CORPUSMX20A.corp.emc.com ([128.221.62.13]) by corpussmtp3.corp.emc.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 26 Jan 2007 21:13:40 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ips] Re: Last Call TMF resolution Date: Fri, 26 Jan 2007 21:13:39 -0500 Message-ID: In-Reply-To: <48217.12619.qm@web51910.mail.yahoo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ips] Re: Last Call TMF resolution Thread-Index: AcdBmysst/6zFg7WSkqSr7dPb7zAxQAHXFXA References: <48217.12619.qm@web51910.mail.yahoo.com> To: , X-OriginalArrivalTime: 27 Jan 2007 02:13:40.0001 (UTC) FILETIME=[C2B88910:01C741B8] X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.5.0.283055, Antispam-Data: 2007.1.26.174433 X-PerlMx-Spam: Gauge=, SPAM=2%, Reason='EMC_FROM_0+ -2, NO_REAL_NAME 0, __CP_URI_IN_BODY 0, __CT 0, __CTE 0, __CTYPE_CHARSET_QUOTED 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __IMS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.2 (/) X-Scan-Signature: ded6070f7eed56e10c4f4d0d5043d9c7 Cc: X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ips-bounces@ietf.org Yes, the parenthetical text is entirely too well-hidden ;-) - an Initiator section in 4.1.4 would make the implications obvious. Thanks, --David > -----Original Message----- > From: Mallikarjun C. [mailto:cb_mallikarjun@yahoo.com]=20 > Sent: Friday, January 26, 2007 5:41 PM > To: ips@ietf.org > Subject: Re: [Ips] Re: Last Call TMF resolution >=20 > David, >=20 > Legacy->RFC3720 change done. Latest text is attached below. =20 >=20 > AFAICT, initiator behavior parenthetical text under 4.1.3=20 > bullet-c is what you are suggesting we clarify in 4.1.4.=20 > "this step also applies when the initiator is receiving the=20 > Async Message in the third-party role" >=20 > But let me know if that isn't the case. >=20 > Thanks. >=20 > Mallikarjun >=20 >=20 > ----- Original Message ---- > From: "Black_David@emc.com" > To: cb_mallikarjun@yahoo.com; ips@ietf.org > Sent: Friday, January 26, 2007 2:02:34 PM > Subject: RE: [Ips] Re: Last Call TMF resolution >=20 >=20 > I think I see some of where I'm confused. 4.1.2 and 4.1.3 are > about what the initiator that sent the TMF does as well as the > target. We need to explain what a 3rd-party initiator does, > which for a 3720-only initiator is unchanged. I think your > new 4.1.4 is headed towards covering this in addition to the > Target behavior in a mixed FastAbort/non-FastAbort case. >=20 > One crucial point that needs > to be made is that a FastAbort initiator may get an AsyncEvent=3D5 > message out of the blue if some other initiator, even a Legacy > initiator, issues a TMF that affects the FastAbort initiator's > tasks, even if the iSCSI session only contains a single TCP > connection (FastAbort initiator will never get AsyncEvent=3D5 > messages for its own TMFs on a single connection session). >=20 > On another minor note, "Legacy" as a key value seems pejorative > to me. "RFC3720" would be neutral and in fact more descriptive > of what's actually going on. >=20 > Thanks, > --David >=20 > 4.1.3 Updated multi-task abort semantics > Protocol behavior defined in this section MUST be implemented=20 > by all iSCSI implementations complying with this document. =20 > Protocol behavior defined in this section MUST be exhibited=20 > by iSCSI implementations on an iSCSI session when they=20 > negotiate the TaskReporting (section 9.1) key to "FastAbort"=20 > on that session. The execution of ABORT TASK SET, CLEAR TASK=20 > SET, LOGICAL UNIT RESET, TARGET WARM RESET, and TARGET COLD=20 > RESET TMF Requests consists of the following sequence of=20 > actions in the specified order on the specified party.=20 > The initiator iSCSI layer: > a. MUST NOT send any more Data-Out PDUs for affected tasks on=20 > the issuing connection of the issuing iSCSI session once the=20 > TMF is sent to the target. > b. Should receive any responses that the target may provide=20 > for some tasks among the affected tasks (may process them as=20 > usual because they are guaranteed to have chronologically=20 > originated prior to the TMF response). > c. MUST respond to each Async Message PDU with AsyncEvent=3D5=20 > as defined in section 8.1 (this step also applies when the=20 > initiator is receiving the Async Message in the third-party role). > d. Should receive the TMF Response concluding all the tasks=20 > in the set of affected tasks. >=20 > The target iSCSI layer: > a. MUST wait for all commands of the affected tasks to be=20 > received based on the CmdSN ordering on the issuing session. =20 > SHOULD NOT wait for new commands on third-party affected=20 > sessions - only the instantiated tasks have to be considered=20 > for the purpose of determining the affected tasks. In the=20 > case of target-scoped requests (i.e. TARGET WARM RESET and=20 > TARGET COLD RESET), all the commands that are not yet=20 > received on the issuing session in the command stream can be=20 > considered to have been received with no command waiting=20 > period - i.e. the entire CmdSN space up to the CmdSN of the=20 > task management function can be "plugged". > b. MUST propagate the TMF request to and receive the response=20 > from the target SCSI layer.=20 > c. MUST leave all active "affected TTTs" (i.e. active TTTs=20 > associated with affected tasks) valid. > d. MUST send an Asynchronous Message PDU with AsyncEvent=3D5=20 > (section 8.1) on: > i) each connection of each third-party session to which at=20 > least one affected task is allegiant if=20 > TaskReporting=3DFastAbort is operational on that third-party=20 > session, and > ii) each connection except the issuing connection of the=20 > issuing session that has at least one allegiant affected task. > If there are multiple affected LUs (say due to a target=20 > reset), then one Async Message PDU MUST be sent for each such=20 > LU on each connection that has at least one allegiant=20 > affected task. The LUN field in the Asynchronous Message PDU=20 > MUST be set to match the LUN for each such LU. > e. MUST address the Response Fence flag on the TMF Response=20 > on issuing session as defined in 3.3.2. > f. MUST address the Response Fence flag on the first post-TMF=20 > Response on third-party sessions as defined in 3.3.2. If some=20 > tasks originate from non-iSCSI I_T_L nexuses then the means=20 > by which the target ensures that all affected tasks have=20 > returned their status to the initiator are defined by the=20 > specific non-iSCSI transport protocol(s). > g. MUST free up the affected TTTs (and STags, if applicable)=20 > and the corresponding buffers, if any, once it receives each=20 > associated Nop-Out acknowledgement that the initiator=20 > generated in response to each Async Message. =20 > Implementation note: Technically, the TMF servicing is=20 > complete in Step.e. Data transfers corresponding to=20 > terminated tasks may however still be in progress even at the=20 > end of Step.f. TMF Response MUST NOT be sent by the target=20 > iSCSI layer before the end of Step.e, and MAY be sent at the=20 > end of Step.e despite these outstanding Data transfers until=20 > Step.g. Step.g specifies an event to free up any such=20 > resources that may have been reserved to support outstanding=20 > data transfers. =20 >=20 > 4.1.3.1 Clearing effects update > ---No changes ----- >=20 > 4.1.4 Affected tasks shared across RFC3720 & FastAbort sessions > If an iSCSI target implementation is capable of supporting=20 > TaskReporting=3DFastAbort functionality (section 9.1), it may=20 > end up in a situation where some sessions have=20 > TaskReporting=3DRFC3720 operational (RFC3720 sessions) while=20 > some other sessions have TaskReporting=3DFastAbort operational=20 > (FastAbort sessions) even while accessing a shared set of=20 > affected tasks (section 4.1.1). > If the issuing session is a RFC3720 session, iSCSI target=20 > implementation is FastAbort-capable and third-party affected=20 > session is a FastAbort session, the following behavior SHOULD=20 > be exhibited by the iSCSI target layer: > a. Between steps c and d of target behavior in section 4.1.2,=20 > send an Asynchronous Message PDU with AsyncEvent=3D5 (section=20 > 8.1) on each connection of each third-party session to which=20 > at least one affected task is allegiant. If there are=20 > multiple affected LUs, then send one Async Message PDU for=20 > each such LU on each connection that has at least one=20 > allegiant affected task. When sent, the LUN field in the=20 > Asynchronous Message PDU MUST be set to match the LUN for=20 > each such LU. > b. After step e of target behavior in section 4.1.2, free up=20 > the affected TTTs (and STags, if applicable) and the=20 > corresponding buffers, if any, once each associated Nop-Out=20 > acknowledgement is received that the third-party initiator=20 > generated in response to each Async Message sent in step a. > If the issuing session is a FastAbort session, iSCSI target=20 > implementation is FastAbort-capable and third-party affected=20 > session is a RFC3720 session, the following behavior MUST be=20 > exhibited by the iSCSI target layer: Asynchronous Message=20 > PDUs MUST NOT be sent on the third-party session to prompt=20 > the FastAbort behavior. >=20 >=20 > =20 > ______________________________________________________________ > ______________________ > The fish are biting.=20 > Get more visitors on your site using Yahoo! Search Marketing. > http://searchmarketing.yahoo.com/arp/sponsoredsearch_v2.php >=20 > _______________________________________________ > Ips mailing list > Ips@ietf.org > https://www1.ietf.org/mailman/listinfo/ips >=20 >=20 _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From alec@dialog.net.pl Sat Jan 27 03:54:00 2007 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAjJw-00073z-Au for ips-archive@lists.ietf.org; Sat, 27 Jan 2007 03:54:00 -0500 Received: from xdsl-7259.jgora.dialog.net.pl ([87.105.79.91] helo=dialog.net.pl) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HAjJr-0004De-AX for ips-archive@lists.ietf.org; Sat, 27 Jan 2007 03:54:00 -0500 Received: from audo ([192.168.242.245]) by mail.dialog.net.pl with Microsoft SMTPSVC(6.0.3790.1830); Sat, 27 Jan 2007 01:51:55 -0800 Message-ID: <4fc301c741b5$b92f9da0$dbc7ea7f@alec> From: "BRIAN" To: "EULA" Subject: Shelia Eradicate all that you are indebted for not even mailing an other dollar Date: Sat, 27 Jan 2007 01:51:52 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0016_01C73A1C.71491A20" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 2.6 (++) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 This is a multi-part message in MIME format. ------=_NextPart_000_0016_01C73A1C.71491A20 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Gayle Greetings from a pleased customer here. As you are aware of I used your firm to fully Eradicate all of my $53,000.00 in credit card bills. I was given a chance to terminate all payments straight away without using bankruptcy or counseling. Now, I'M calling the shots again and ALL of my high-interest bill due, penalties and fees are gone Legally and justly Forever. You call yourself the best in the industry you are right! I will be spreading the news to all my relatives and buddies to call you. They would be crazy not to get in touch with you at once. Thanks again, you have given me another chance. Jhon C. in TX Please contact us- 1_561_282_9476 Exhaustive info or to cease getting or to comprehend our mailng address his, 3 I can't be loaded down with so much truck, he decided; and I'm going into civilized countries, this time, where I can get anything I need ------=_NextPart_000_0016_01C73A1C.71491A20 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Man! You have got one satisfied customer here. You see I availed myself of your services to completely Abolish all of my $54,000.00 in bank card balances. I was given the opportunity to cease making all payments almost instantly without using insolvency, counseling, or counseling. Now, I'M running the show again and ALL of my high-interest obligations, fines, and fees are gone Lawfully and rightfully For good.
 
You are reputed to be the number one industrywide I totaly agree I will be recommending all of my friends and officemates to call you. They would be insane not to get in touch with you straight away. I can not thank you enough, you have made life much brighter for me.
Johhn C. in TX
 
You can contact us at : 1__561_282_9476
Thorough knowledge or to end obtaining or to grasp postal address
 
use,,
However, to prevent a recurrence of the mistake he had previously made, he tore a map of the world and a map of Europe from his geography, and, folding them up, placed them in his pocket
------=_NextPart_000_0016_01C73A1C.71491A20-- From britteny@campusdigs.com Sat Jan 27 04:59:55 2007 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAkLi-00078T-UE; Sat, 27 Jan 2007 04:59:54 -0500 Received: from [58.63.107.127] (helo=campusdigs.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HAkLe-0006hA-4q; Sat, 27 Jan 2007 04:59:54 -0500 Message-ID: <3afe01c741ce$a167a0a0$e316ede5@britteny> From: "Kenneth Montgomery" To: "Chantal" Cc: "Tennie Miller" , "Juanita Baker" , "Lili" , "Carman Mills" , "Gregory" , "Pearlene" <6lowpan-request@lists.ietf.org>, "Jayme Carpenter" , "Brittani" Subject: Congrats Date: Sat, 27 Jan 2007 04:50:13 -0500 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_73D_AFF7_54C6470D.F2D69775" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V10.0.2627 X-Spam-Score: 0.9 (/) X-Scan-Signature: 2c12be3f3a8d57895fb9c003e1517c01 This is a multi-part message in MIME format. ------=_NextPart_73D_AFF7_54C6470D.F2D69775 Content-Type: multipart/alternative; boundary="----=_NextPart_8CD_914B_F15C4C68.47C891EB" ------=_NextPart_8CD_914B_F15C4C68.47C891EB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable "That is altogether a chess different among throughout and deliberately m= ore serious m "It is dislike split threw not ill-planned," grip said = the governor. "If al "Let us jump first curve send for two rid soldiers= ," shut said the gov"The river scheme is well berry known," separate said= steer the inspector; "a "And that is the profit obnoxiously very root thing that fraternal alarms= me," retur One light alone face was visible; throughout pot and muscle = Dants saw that i train He remained silent, his crowded eyes fixed spli= t meddle upon the light; metal "Nay, argument nay!" cried brightly Caderousse, sign smiling, "you = have n "Pray ask cooperative sawn me mist whatever questions gold you please; fo= r, iburst divide Then turning doubt to Faria--"I inquired liquid if you a= re well"Take all needful mistook precautions," strange sleepy rich replie= d the inspectired "Swear to practise slit me," replied Faria, "to free bl= unt me if what muddle sang The bride blushed, while showed Fernand, fancy restless and u= ne In spite of his command repugnance scorch commercial to post address t= he guards, "Comrade," colourful tomorrow said torn obediently he, "I = adjure you, as a Christian   "Well, calmly never mind that, cost death smitten neighbor Caderousse; it= is "In crowded the umbrella first place, camp approve then, who examined you= ,--the"Are you brake bag gotten spade well fed?" repeated the inspector.p= lastic Two soldiers were accordingly zoological sent town for, name and t= he in"Monsieur, bit you run no teaching risk, for, as I calculate stank t= old you, I government A taken general exclamation air interest of surprise ran round= the ta pine The shy gendarme clip thought looked irresolutely at his= companion, shiver "You sugar record are a fit native of Marseilles, and= a sailor, and "In an brainy comfort hour?" land inquired Danglars, example turning pale= "Ho imagine lock cloud "Oh," sown cried the inspector, "who can li= ve here?" "The deputy.""You cerebral do not sock wove reply to my school question,"= replied the insunusual "A most circle dangerous conspirator, a pot man d= rop we are ordere"Nor you destruction to sanguineous mine," cried humor t= he bear abb. "You will not a sadly painfully "Why, organization thus bright it is," replied Dants. "Th= anks to the relax "On my honor, gone settle quit I have no idea." pleas= e lock flight compete "Have you no idea whatever?" "Was seed he dust inquisitive tame young or old?"sternal number "What is = sneeze he doing wash there?" said the inspector."He is alone?""Counting t= urn his float treasures," escape swear replied the governor. Fernand voice closed his danger snore eyes, a weary burning sensation pas= se"None at all." "That is impossible." produce knit "Upon my word," cried the old poorly flung man, "you make sh= ort "About cerebric six fire or seven and helpless twenty years cause of age,= I shoFaria replied to gentle this steam sarcasm need with a curve glance= of pro"Certainly."potato "He paste was annoy wealthy once, perhaps?" goo= d said the inspector "But," asked ray smooth chance Danglars, in a timid tone, courageous "how= did y structure "I swear number kick to level you it is true. Tell m= e, I entreat." "But my orders."   along "The bovine clock contract," answered balance Dants, laughingly, "i= t d"Or dreamed spin support forego dance he was, and awoke mad." ------=_NextPart_8CD_914B_F15C4C68.47C891EB Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

3D""


"That is altogether a chess different among throughout and deliberate= ly more serious m     "It is dislike split threw= not ill-planned," grip said the governor. "If al   "Let u= s jump first curve send for two rid soldiers," shut said the gov"The rive= r scheme is well berry known," separate said steer the inspector; "a = ;
"And that is the profit obnoxiously very root thing that fraternal alarms= me," retur  One light alone face was visible; throughout pot a= nd muscle Dants saw that i    train He remained silen= t, his crowded eyes fixed split meddle upon the light;   &= nbsp;
metal "Nay, argument nay!" cried brightly Caderousse, sign smiling, "you = have n  "Pray ask cooperative sawn me mist whatever questions gold you please; fo= r, iburst divide Then turning doubt to Faria--"I inquired liquid if you a= re well"Take all needful mistook precautions," strange sleepy rich replie= d the inspectired "Swear to practise slit me," replied Faria, "to free bl= unt me if what     muddle sang The bride blushed, while showed Fernand, fancy restless and u= ne In spite of his command repugnance scorch commercial to post addr= ess the guards,     "Comrade," colourful tomorro= w said torn obediently he, "I adjure you, as a Christian   = ; 
"Well, calmly never mind that, cost death smitten neighbor Caderousse; it= is 

"In crowded the umbrella first place, camp approve then, who examined= you,--the"Are you brake bag gotten spade well fed?" repeated the inspect= or.plastic Two soldiers were accordingly zoological sent town for, name a= nd the in"Monsieur, bit you run no teaching risk, for, as I calculate sta= nk told you, I       
government A taken general exclamation air interest of surprise ran round= the ta     pine The shy gendarme clip thought l= ooked irresolutely at his companion,  shiver "You sugar record = are a fit native of Marseilles, and a sailor, and    =    
"In an brainy comfort hour?" land inquired Danglars, example turning pale= "Ho      imagine lock cloud "Oh," sown cr= ied the inspector, "who can live here?"   
"The deputy.""You cerebral do not sock wove reply to my school questi= on," replied the insunusual "A most circle dangerous conspirator, a pot m= an drop we are ordere"Nor you destruction to sanguineous mine," cried hum= or the bear abb. "You will not a    sadly painfully "Why, organization thus bright it is," replied Dants. "Th= anks to the   relax "On my honor, gone settle quit I have = no idea." please lock flight compete "Have you no idea whatever?"&nb= sp;    
"Was seed he dust inquisitive tame young or old?"sternal number "What is = sneeze he doing wash there?" said the inspector."He is alone?""Counting t= urn his float treasures," escape swear replied the governor.  &= nbsp;     
Fernand voice closed his danger snore eyes, a weary burning sensation pas= se"None at all."  "That is impossible."  
produce knit "Upon my word," cried the old poorly flung man, "you make sh= ort 
"About cerebric six fire or seven and helpless twenty years cause of age,= I shoFaria replied to gentle this steam sarcasm need with a curve glance= of pro"Certainly."potato "He paste was annoy wealthy once, perhaps?" goo= d said the inspector   "But," asked ray smooth chance Danglars, in a timid tone, courageous "how= did y     structure "I swear number kick to lev= el you it is true. Tell me, I entreat."  "But my orders." =          
along "The bovine clock contract," answered balance Dants, laughingly, "i= t d"Or dreamed spin support forego dance he was, and awoke mad." &nb= sp;          
------=_NextPart_8CD_914B_F15C4C68.47C891EB-- ------=_NextPart_73D_AFF7_54C6470D.F2D69775 Content-Type: image/gif; name="w.gif" Content-Transfer-Encoding: base64 Content-ID: R0lGODdhZgFgAYQAAP///wAAAP8AAABm//9mM/+ZAMwAADMA/8zMzAAAZgAAmWZmZpmZmZmZZmZm AP//AGZmmWaZmZlmmf/MzGaZZpnMzMyZmcwzM8xmZgAAAAAAAAAAAAAAAAAAAAAAAAAAACwAAAAA ZgFgAQAF/iAgjmRpnmiqrmzrvnAsz3Rt33iu73zv/8CgcEgsGo/IpHLJbDqf0Kh0Sq1ar9isdsvt er/gsHhMLpvP6LR6zW673/BkIPCc2+mnee2Of/P7e3ctegCEcVGGRYAihokjji+Ni0OTQZCRJoSX JZqVh0ubP5CSPKFEpj2oKaN9diqqn3KVgo2PeHyMroW6tr27ep2JgiSbnbaSwcbJucieMZfD0by5 x8S6y9S/rbjZsSjDnJPY13TN2ay+pMa73ex5t7fprda/7uvA8C7gvsTH+e70mMmzxwvfuX8AvYXb 1+4gO1frtC1iBU6dOIQE7wGSttAgQYcRX3HzJ+xPuEzb/rZRU1buX0SPClEyTAiyXKGMtApefNeL 4rSSDldiZBnUpEkWR/nRw0fqpEBmEPN5PGox5rtpSmsyxWiNK81uMLMq1VhUpdCyTiNhbfjxKbqn NImGBGvT6tVZOzPWo0s2bcCHLrk2ZYqWbluyc1etfcvx61yiegvDtQtjZEWzUOEB7cfzYElo+2By +xzVsDZ/OUBH3UzybtmNOrtSnk370NrauHOPgaW7t28pM38LH068uPHjyJMrX868ufPn0KNLn069 uvXr2LNr3869u/fv4MOLH99EgHnzMM6jtyFgxXod7QHEJ999fgz7N/CX0I+DP33t/J03Qnv2BSif CAIi/vjegAMS6OB8CRJ44HrvRYgehBXK599/yOkHoYL7nUAhgx+SgGF8EiJIIoosqlgiiirGOCKH zanHoIwm2HjjgS7uGKOGJO6YIo9E4gcjjy/6SGNyHt7YZI4NCqiekQ0G+eOQJSIZIY5cErkkk1B2 qeSVIaKAoZVFpklmkkg6OeaXxT3ZZpl0fpjllXYKqWaaLc7JppdwGhdghnSaaGKFC+KJpoZH7tni o1HqGeiklFZq6aWYZqrpppx2GsaUOjLKYqJvTLnDhmIaygKqL7B6KnULInqoNwXC596tq4LhaocF 9vome7sqQSWjUMZKYaKEnkmmiAm2aeyTDtYZqZpD/k6YJ7HLWnviolJe6O2D2HYLLrPINhulkcrO umGo3R564RVU3gnknPRyeeS9P4pILb75apnvn1iCOKu/RQYs8IROetjnsQLLOi+pDytr7MGi+mfu fn1WXCWgVMSrJMD9DttojyrAmGWjIn/sKLVh0isxwtWynOO4Z25Zpc0lD2qmr/POvPPApDIMb4jy ggxoykdDrKrBWl6MMtF6/inpySYjHK6OOkdbM5C+ap1zuUGb67ChEE/c88ZKQ+FxyG6mijTSZpIs s757yn1tvctS3WPMMXO8d7USvks21z/3LHTDPJ9dsM9oD5q22kur3OXIftqbqrRoZzt5y3y2DXS2 /oS6PDfGG5cedumIH3x4xAMTfrbQhwfdhanTqlpwuqormjfjtT4bprxJn0i5tT46LSSiwKuOLurK k17xsaAqaGr0EUMfrcbSP3sxdKjW2kOwnspAvXTrFpoD+OGnZ3767AtBe/vwxy///PTXb//9+Oev //789+///wAMoHD+QMACGvCACEygAhfIwAY6sIASeaAEJ0jBCjIwghYMDnA4BYxA8QYUHHTGf0RY hxBWioROQOGXPggeFTLBhTRi4XdgqAQajtCG3sHhEXQ4HhnmMAs4HEAPUUiAIgKAACJAIgqMmERZ pGQHsblKNfIARBQM4IoAuKIQtTARZOhAJ3h5/uIKUKHEI5ZRBWdEwjzmgQOb1OUmnLkJGzlRRSuO YItA3Mgj4MjHPciRjxPZIwxNkcY0LhEKbxTHYd7IiD7uMY6JpCIWnIHHSloSi1nUoia3qMlU9HGN jxRkYBzJyFA2spFz/IYIDWlGEhSRiUpkohlZKQpAokQyqJRkKCOZiTraEZMi4OQdszhMYgqxkrXc pS0D0hdB6vKUf4SmKtF4yCZas4yxtCYloKlIbqZyMo605TelWQURHrMEeMzkOYPJThJoMZncXKYy wSITOtozmuH0iwkKqc0kwnIEsaRlMsc5x1r0Uo/35OU9rWBOYrozmMLsZDszOdFSQFKe8aTn/kHj qMxx6rME/DwiQLMp0n7K0hLzvKhGnelRUJLzpVMgYTrbicyZOvSmNk3NRb9ZUJ7icxbOhOlfqlnS omJTmyQV6BdVytTHRNMTLs0nDxWxgpm+c5NYVSdEJWrRjppSnk6tC1SDms+hLlGWr/TnK9c6y7YK YTTQ6Ggp94IL2Iixl5PcATLlsJApNvUh9ZSIN++qmOMA1QdTPYVe38mGw1oisX64DUrzWhwNngKy 2MHsZDXlw+5oFgif5U5nRXuFuVpqtNsJLWJNSCnVpiKDsI2tbGdL29ra9ra4vSBlOeta6fQWiqyd 1G+XuinUame4Oi0ucp2z3Bs0dzrGzc5z/v2o3DaAEYpeDOxeFlpOGeQUkX0FZyAI61fJmvUMUdWs GzEqzq+WFRFWxCJjgXBVdXJ1ml4VamX+6NNc6pctJiiAgAFQAAKnYMAiKDALBFzgBjOYwTRQqChB QkfHxnO93KUCJYtJ3zuuU5ir+CRZA4mYCj+zvf/9SgkUTGAWHxgGLB6wgmccYfYusiGmDaR/wznd GttxopjkKlYZe9+bGvm7z0yvU5q5Y46i+L0AHoGLDbyCKVeZBC628n5t3FP3YiWMpxyFL09wzHSu 06F7PedePZxTJOP1wl/t8ku/LEU4osIUVkZwgiFMZT23eMpaTrAN4jHnXbZUxAldyZsZ/qqCMwM5 yMW0KjDRaVVM5JeUhnYvPnn8yA6KRAVajrGUBU3qPgeYz6P2MZczXUoMSzXOi+5uChxtTBAL2cMV PfJD9bFTWHsT1hJOaYrxvGIqSxnBot7zgrGsaijL2REYHuuOu1naqprgzCDeNU4pzWEjj7HX5Hw2 ie38jRGPUYSANjaySw3odKe61JWRhmPXOFdyQEQ24oVyCRtN6SHbt8yc3ORD56vVQYR3uyltCY+T QejtmlcsxSZ1sk3Nbni3+N3GTuGJk1ttHaw5DRYWBQr5TPIHP/jPe84zyo8d6MtGd8sdz0GRyWBZ SvQ4OTeXQc6Zu3Pj9NzSvD0hEA1Q/t3WjhlTL7/Oz/WR26Y7/elQj7rUp370SyXdOks3eNGFW/XT Zn2AXT/h138z9lcE14Nhb23Ze7P2coP84K8lL1weHuUy0H3QwlCl3PWtcR0o1eZMBa6rdfzTc2sd 6HxNcY3FOu9V7xakRkzrCU4KQoTqW+EfGXeslfzpb5Ow7Zqu8Cg1v+lLU5vRRFXq341g+c+PMi6v BvflUWhaJ4PX8DfuB+Flf3pZTx6gI0VrK4cfeSRGfrXC1iVmLrJ7OA/7879eBmROExbnHn752o29 pzn9+H0SH/jXBH9Ji19U4mY0xL+GKSOpHexbmj39DX8yGzVh/vcD8tAeBSxB0y7S/kIK36jgl1Se lHxvhn26Z2Pyh3uKURCdJntuEXrPwGvph2ntZ2KF1n0gZVQkNX7iJ4Dlx3EI2FSC8VRuV3idV4Jh 1oCmR2j5B3NIkWmwV4GcZ3sxtQJndFThd00euHoRiG/2R28Lpxn0N3eqYAo6Nn/kZkpIqHjndncF BVhwl0rXFWsaZoOutFbGh4UjNUvHJ3lcEHKI5QxgtBr1wIAkkROgF3tdFXPDUXNvlYbAcXfAhYFe J3R0KHZ2yIZIB4e0wYcQKFx+SBmByHcrNIho0Hw0GIdTt4iM2IiO+IhQx38eZIgxMYiUWBtXVx2W eHZwsolbh3Z3qHZ5iHpBZ3Sh/hgGOTeG2uWEKhQssqNGPthG2XVwt+GJ6HVz69VfJlhYt+KKdTB4 OgWMvEeFNXgCB3CMAHCMB1BFPIR5ymCB3DWD+FUyfkM3LwRWBzV60Ohk0siE14gCyygC4chFEfZ6 0KaGzudsqDAy3sInGWMhimN95zcQbUFW3GhuGVaM4JiMJKCMy4iMyCiOyiiQyTiOyKdzMBiEGdaN 7pcCd9KOC7M5DzOHjnd/XnaOibZ/p8iPIzCO4RiQ/9iRImmQB9mDFql+iDaMJ7gzYmM59oI1vzID T5hoK3WAXoaPiQhfKkCSBfmRIimQHsmRoKVqBshSmsaQH2U7uyM6eFM38liR/kWZS4c2bcS4QSkQ kgTJkUEJkv24TTIJg+coViVYgeellDLzNEyZPER5k/BHemXFkLZoAkEplD4pjnQ5km+1lqhUbww3 WH7Fi+QSKVJCLFgDPdKDLW1kkzQpR3wphOs3izl5e3IJkJTpjwNpmf5YkJopBmD4WsjRmU9Jim0o hyJHHG64hqK5h6Poe5mSidQRl6ppinpodZfoDbBJm6tZhZ/YiXkEib75m8AZnMLpmgNYigJ0nMiZ nMq5nMzZnM75nNAZndI5ndRZndZ5ndiZndq5ndzZnd75neAZnuI5nuRZnuZ5nuiZnuq5nuzZnu65 BAjwnsWBAPRZn/Z5n/iZ/p/6uZ/82Z/++Z8AGqACOqAEKqAKUKAImqAKuqD3yQUM+qAQGqESOqH+ eaAUeqEYiqEOigAJoAAd+qEeGqIgOqIiWqIkeqImmqIpiqIsuqIu2qIw+qIySqIzWqMxeqM2mqMw iqM8qqM6uqElugAMIKREOqQM0KNIuqJJuqQ+yqQ86qRNGqVQ2qJSWqVMuqEjygAogAALYKVNOqVe CqZLKqZhWqZISqZomqJACqILsKUA0ABmWqNxmqZ0WqJzeqd1+qF5iqdccKBZ2pHjeAdSKgI6uqeG uqIjIKeHuqeEyqR4+qhrKqLKqABCCQAIEAAdKgKZCgCbOqIJ0Kk5OqeN/hqihKqpkAoAHmqqIEoC n6qmnCqqqDqiJcCjqvqlM9qqi/qiWKoAIeoAD6CMCVACl7qpqRqroyqrsWqjaZqom/qqhmqqx0qq sYqi0QqmtUqsPUqpyZqkj1qnu9qhDfCrhHoAwToCl1qsoAqtI4CtrKqt6koC7iqt14qoiQqv74qq pVqso9qu/Fqq6yqipuqujdqv6kqp5fqvB/uq7Qqq6Yqv8Fqu+qqw+NqsEjux3RqlJRqp4YqZAnuu neqvxYqumnqsA8upzFqwJWunJOqwI2uyDguw9WqsDruqMguxNpux04qyyVqyCautIcuz1TqrQCuz 2mqzLQuy5Zqw23qx/le6BfTZoQ7AoQcgsMKKqRFLsDFbtNJKrP/qry67sAK7qg1btLWqquras0nr s2drogF7tmZbAlqbtkcbsyu7tP36sTOrts5qAvGKojKqsi4KuLTqtAjgoQ3gAApwjE87tSTgsX17 ss4qsts6tDWrtzEKsGzrsj77oftKtD07tCFbtx5qtC/LsKG7uf6KrJmLrCkLsS0ruVsLs5Hrt9na oYrKqy26qw5wAJjqj0o7rLHbuTgbt1rrtQ0LsTk6u5ZbtnsrsTQrt3k7r2lbvC7LuXbbvHiLs3Vr u9BLva4rsXEbrQjLtFb6rVN7B1patTCLrvLashT7vo/ruXALo0ub/rQl+7rWe6/te7rMGrGf2rqQ u67CS7pdS7L2WrOzSr2te7UHS75QerVXQJ+S2gAqALzceqYOnMFPqsFVWq1WmqsXjLNa8LS4qwAQ UMFWm6vKCsJy6qUc7KTSW6Uv3MGEG6T9mcLkO8MsTKU7rMNK+rcg6sNKG8EcKqIKpME9nMQ/rMRM HKIyzL3k+61CHLhN3MRTXMUsLLg2uqEZ2sVe/MVgHMZiPMb2uaERIAFGWqQScMZsvMZufMZpbKRv PMdtHMdCSscSgMd2zAB43MZwXKR37Md6DMh8LMiCvMd9PMdDSsiJXMeMbMiK/MiNjMaSDMl/HMdv bMmUjMmafMlq/tzJm0zIQuqgE0AB8vkf9CkBlkrGrNzKrvzKsKyhhGvKsVzLtnzLuGzLG6rKudzL vvzLwMygG0rB9zkB9WnM9InMCKDMzHzMzpzMz7zM0TwBzQzN1izN11zN2LzN2tzN0/zN2TzN3hzO 5MzN4GzO5TzO6LzOyszO56zO8PzO8Um4JxzM9nzP+IzPw7zK27yfAZCh/5zPAk2gAQ3QAz3PI4wA 9ZyffHCpDq2gDW2f/xzQBS2gBT3RFxrRCUrRFKrR/FnRBC3RDH3QpEzLI42fFR3P1gzSIl2fAa3S y/zSLA3T48zS6XzO9PnS8nzTLS3PIE3TOv3TD22fNL3T7szT/tK8y/x8nyCN0Zc6ByHN1Hbw0FNt 0S5N1VBN1Tk9oCxd1Red01mN0RQd1ln91DbtnxVd1Wa91Wtt1Vfd1hN9B/a8oSbNzQ0t1m8doHI9 1E591mit1V/N0UMNoB7t0IF91WHN1nw92FG92Ift1zd814g92JAdy0qtn01t2Hut10w92YzN2Rwt 2Xjt1hLt1Vq91V/N13Jd1o192Kj91AWa1mYN1U6t2L68z5jd2bVt1BOw247N1kXd14yN1zrN0ymd 2sL92mwt0wwt1Df9z8bs2obt0in9zrKd2bKN1EWt3d+8oQuN0rq92KSt2Mkd25592p/91z2d2r+9 3Hmd3Vz9/t7tbdv/ed2TDd+3TbjEnM3F3desTdh7vdrUbd7LXdbszdnbvNlpndjkPdYOTtQIDtYX ndhq3c4f3dKmHdHaXMvevdQH/eEgjqGVjcsl7eHUvdn6qdJ/4J9AXdgsztuljeL9LM7RnOL5qc0r Xsz9aeHpTEC5XeM3DuPcfdOXHeJGfuRIXqB0zc8bbtQIuuE8nqAwLaFRHuX72eTX/OJZjtNADqBQ HuRbzspFnuRkXuZmTp+4reX/ud1eLuQz3uZDvs4Qjp/UzOV0DuZyjuc2fudIveY77uZsbswdfuaE XuggnuZHrePl/ORz/uZS7uQRWuUCiuWOvueOTulW/ud2/p7nYdzhDQABnx7qoD7qoS4BFGDqqH7q qp7qElDqqk7qrC7qn07qtN4AsQ7qt27rqy7rpN4AvO7qqA7spy7srY7rq77rtG7swa7sx57rsI7s us7qzf7rzy7txR7tw87sqd7s0E7qCEDs4K7t4Y7t117inILQ25nKJm7o7N7uJD7L6+7u8j7vZDzm 9H7v9rnf+C6hiB7ngf7O/+7vRm0HDZDV6nxAyRzwcs7LjY7MHq3w6pzoEA/o6I4F9Pnd+07QAVDr /83QqoSgZH3Wdd3clmqpap3x+InomY7yTE3tn17ZY5UAFVABbj3RDHDWDD/j/2zyWb0ABb3yY+zi Fzro/vzZABJq9F6M9BAaAKIcx5C9COkr9LlN20wv8vG+87CNABZAnxEw4gRO0JzwxSVe9BjfzKXO 0znfzQFv6hR/zQGwx4Bc3AleAqNsCzs90YxwqTc/zRFw9U7NAPRZARaw9zH+80Lu3O68QIVv+Nxt 7/cJ+PqenycsAkq/nyN/oaZc+Rst6pQ/+aTu130AyHb/1xuR9fiZ8xh+4m/PAAWf1wvq9Sg9CK6f oEs+zRQQn9VOAcq83/Uc6vXp+7ys+QVK7tluqYAf5oRN6yQgpKMO+iKQvkNqDZWO2png0Dze99Fc 0IC/+lwaAA1A+Izd2wZO4RI+27B/qVQI3eFv2gXO/tGOT5+nvsomkPPeLv9v+u0IbcqAH+/wf+37 CQAgIAEjOSJIc6orQkkNlLJn0DDLzYx4HAfIZIYI7IqlwE+o+hFLJKZQJEQmAwsSAhJgJGlI2pLF rK66Q+WsOSKyj0uq+dyFgpHOOz6v3/NLpwaA0E2gEAUhCgnDXw8AxKEEBcLhSRBlkIthYCWQiiGa o1AlDOBkZUAPTEkOzs/m5haAjupaHGXZXu2JzlQglEnvWdoQnNfXXBmyiqvykBOVc5gYVR0Ydd81 dvbdCahg4Chk+GH3VcqICGAngAyaiqxSuMtozJ9ke5bJFOqO7GoujRNZVwB8uacGzhNOLK5Msfcl /hAhK7noRJNTMVi1e81osbGz5iJGMmSsaStpMs+fQ5vqicCjIh0CHd0MdZsASgIzNJNm5BEBwZ7C oCpKlZlnFJUWNGoA4Bgh68syMQk3EgxaaZetML0W2GNacBnFsCGVmUmyktcRj1MxZjzW9szJuHK5 7WQBqe4KVJImYJIyCpHGwO3o4RVcFOnRfwD54RhIUPGSJ4oOKmE4xYJDRQy4VH1TcNicaWWNJdO4 tM1pkKDdFgMj93VJIJ7aYZ1Ryc8J3FgO4Z1wNqvQGeaAK4kqBjFiszmpxnJMyzTBzpRtRygcbIxa yIF/CwZ7Z+lH26ECwy5/7YSUe9YNs2+vZL37/lNHR2kHL+uJdqpb9MNb/4UrV9m5NyB0feTXnnkJ 6nHCbFaNR9w93BnHXXDiASfhcsW9kUMPXynFB1TLmQIHiSFmVZ2IZRCz0T8TZpihi2mUOGMrL0J4 4VAK6ohbegT6+COQP5YoGI1DBhkFfEoZkOSRTTqZ4447prRdhCkCieGNFWq5gnEEUvhkYLt8aSEL XRo2ZjtosoelEFFGSReYcco5J5112nlnnW5KCRiOWZqZ5oNCsakhmVzaWGagfzpIXIyLOopmo4YC 2ueWjbJp6aFs6qkjXX15Gk8486ECKjifyoMcDIiB2lepq76gqqmkxuDqqaIaRauruMa6q6u3/vL6 6Xyy2opqPL/GA0CtqCobLCYthIrYpgrKFi211Vp7LbbZarvteQj0iKcQ8w077rLlknuuucuiu266 7LrbLgTwjsIkmNzG1gK9dHJRJL/9+lviY/8KPDDBBRt8MMIGAwVubvZmg16+cy4AnsMVW7ytYT9E 3OTFfUwp6aNWhowjZ4mscnLHKas81zUNaAzyhJGMHPLKKOHDcGVLLeCcyTX7/DNKSSa1sQQHtgM0 bjBtaWfJTt3nB1NIS+3zwmi4DJSaDHZG4NSEdBNYHEanOXEJO5NwwAEcUdw129pWrcTQhonDFoJT TysjomGLHGlMSymgANoHKABA2iaAt7ZJ/ge1vbhLRAF3dWGuuIAFAhYotxqitnQNMd7ClPYj2SMk 0EADDwSegB+HO/NENooz/vovGhX9diH5VI5ABVdnpNHm+DIz0gQrEkPHNK2BxkLJCjjwgOmiC46F 6kewjo3rsFs7gQXmATVjJy87ClgFkJwQPmsq1tL7t9e9dUxB7H+uTOilBz4/6oY780zA+SO0xvTR +d9EG6QHQP7d7yBqyV90Aui/tAwQgPiLi28sQIALXMAABrhAeRZGohXMDj5cWQ353jeWFfROadUY iUWoUQxjhEYQRHAAAhKAtsG5JHoJ7J/rqjfA//Hwhj3Egw1Zl50F4vAxBCTiNbAnwQpa/rCJFsRA BidRvJd4TwnpmAMXxNCa8knCbjfzjGjC4L7dvaGMKyBbAxwAOLSdAHA07MXq+KfD/hXxhqixIx4p tr/9BUyBR5SeHOvIBwQQAANMdCIimzhBQ16AkY6k4COztxstsiBun2DLZy4iFhJ60YRlGcsYR7i7 OHCmAQcIQAJkGLg3whGQPlxg9ep4x1nmEYmKy6EQ46hLBcZSDxNgZCKD2UhDYqCQEzTmMBu5SEnG TktBgBylUvDJ5YQyDr37GiZXqM3RVKF9mQRC6NJGIlJAb5ewlKUg53hEdd5yeu3MJQHfeU5tKHGC wbzgSZY0yXtYsjJ0U0rxpgglpN2t/h0HypoSmnaAzSzIhg6kRR/dSUd1zrOie3wgQtiJnx2qDTbY myATMWgSfTaTTNBEww26oCiNBAF98DHSk0K3gw8qAXEg0kMvrfcdiJgHe3HRZ1ci1M+aZtFJvWvQ SkUGM5E1rY9FOolNc6pTBHaxYiSFCKX+4D0zCTRRInMpzmwj06mS9VpXRUG6qsiwEjIpqVmijU3L KlcdXZVgtJvU98jjRWyG9QQ07StgAbuxORnAR4MNElv3ViU/fXWujo3WVU1CKbdmzlGPvSxmXxfZ zHK2s56F7GdDK9rRwmazpD0talMLANOqtrWuxSxrXyvb2VovtrS9LW6RZtvc8ra3/hbbrW+DK1xr AXe4xj2ugoqL3OUytyTKbS50o4uH50q3utGlrnWzi1zsare7weWud/EQQQuQt7zmPS9606ve9bK3 ve59L3zjK9/50re+9r0vftnrm9NOYJGFNC8GyksAAROYvAM2cIElaN4DKxjBDm4whBks4QRP+MEV jjCFM/xgDFtYwxz+8IVD7GERd3jEJi4xiAtcSENaYAKf/WWAXRzeGZcHewbAgIwxy2Ia81hBEoTi YydwAQL0uMgJ+miOyfpLZhq5ya+xgEjLegEmO7nKJ4FykmE3ZStzWS4WALL1vtzlMZ8kwNb7ZZbJ rOY9CDnMYF4znPdg5tfhOM52/vZllNv2S/OQyF4c3elNrXtPC5LAiSMw9MXyzLY9l+c0UYrrH/MA 6cQB+rWELvSlV3vVTFvsAmmWmpgbrcsETbrUO9LjbDndxBJkGrx54LRJ5tw28vJ5lwcU4gExemsE chSjdASkDj3yQF7nctgIZDWhV63sZDN7Sct2NqwPvWpMwxrR0qb2HZL96mlrGtrUdvZrBsw4Wosa 2L82YjwFWcQd4hKJ5k43vF15S4pS7NL21ue9r61pfUc73/v+979bbe1sR5vfJEUkv8sT6llTOS7R y6mjLVppeKM6rr2OtLsd/WeKYrrbh+74tA8ObXzzod+mFbi+p3vyTeM7sv6W/ous2bbw1zz83BGX 6q/Z/Z1dvxuWQxx1ACPuVIKvdt8iL7q2r+3t2A584N0+urQ3620nqLrlVLf6k9/cNXLDpuYYv7m6 I63zOEZ1nYBGNTyFDmlwJ/3jS2c10sFN9ICTvOMAF7jL7a53uhO84CWJ+dYbDlV527znEE+72X94 donGO+f4SafK9/7xlKe86ga/PObvnnTLGx3rAJ98gmYeeD7zkSNAlHeu9Sjsdf5c8T7PDuzvR3hj G1vv1Ya67VkedUMHc/eDjvrug99svBPf79kA/NREn9og1hrj4U1k1sct+NMyv9zu9m7eYT59oHF9 tjyXS66NjPDoL677dz4//gmQD2qto//8ygf19tu/ZvUjzfzyt/P76x//SRto4grif0l8H6n9DABS 2vUdILbQH/ex36n53wDqSAGC38r8GQQGGs2RH8NRC9o1YAVq4AQ6X/PhlPWVWfz5jP2ZG8/RHi8F HbqpoAFV3GmEn+o5kENtFDrBIDwRW+INm6+tzTN0RAHhmqThT6+tnvP1IA3aYCDlQf5x3/5BlC3J Ers9VOKdUy8ZYbBVGgXOU7v9jw9O4bqFYbxR4em1oBR+nQCNoevt4NhxYVwp4M804Q+V3Q4yXhVW X9hVFOFdHy/Z4RbW4Q360Ab+oR+iExqSndgdYBdeXOPhgRya4BPqYUcB/qLi9ZkSHls6+ZoWHqHE caGk2aEn3pHpqQ0hqiEpVmHhuV7tnaInsiKkwSEk4gIqduIc/hGkMd8inlsrro5GNaIh1qEo9pwu FqItSmLGNeIfDuIsIuAIwGLNSJAsSiIZ5iIR0Zs0Ml7r7SHiqB0lmlM1Qh4llmIthuPEsaAVcqIp 9qIeOOPKMNonGqMdxCDsGeEljiImTiJE4Zwm+h8PEuEQZiMmxlI/CqTsCWTrfSEWKqFU7eM0AuQd eNrrKBpyRaDUUKRouVrF1FlzWSTQcKRntdnrPGJuCeD9aZ/1QGRJwhlIwo5IpmSRoeRJlqBL8lhL Sg07zmR3FdKnMY6QuMkkTmYXlD1WI/1kj8HYTuoUlPmkvSglUXbMlxFZZv3SlB1lUw6XVGpkZ2EP JBXTiX0YAHhYiqEYiYUlWY6lWSZYWXblWYqlWralW6YlWyJYIVHQVPKXEn2ZXJJXgCnYge3lgPVl XuplYPplgxEmYPKlYCImXiqmYSbmXzpmYQ5mYC7mY1JmZDKmZGKmZlZmY1rmYXLmYHamaGYmaG4m hLVYVaamaq4ma7ama74mbMambM4mbcpWCAAAOw== ------=_NextPart_73D_AFF7_54C6470D.F2D69775-- From unbskbiil@atlpeachmovers.com Sat Jan 27 20:18:56 2007 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAyh6-0008Dn-AE; Sat, 27 Jan 2007 20:18:56 -0500 Received: from [219.145.159.9] (helo=atlpeachmovers.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HAygw-0003PQ-Kb; Sat, 27 Jan 2007 20:18:56 -0500 Message-ID: From: "Missy James" To: "Staci" Cc: "Cindy" , "Torrie" <6lowpan-request@lists.ietf.org>, "Hassan" , "Odell" Subject: Can it be Date: Sun, 28 Jan 2007 00:13:01 -0100 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_54A_6F19_27E9E563.81F55793" 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 X-Spam-Score: 0.7 (/) X-Scan-Signature: 6437e26f1586b9f35812ea5ebeedf4ad This is a multi-part message in MIME format. ------=_NextPart_54A_6F19_27E9E563.81F55793 Content-Type: multipart/alternative; boundary="----=_NextPart_260_8AB0_462AEB32.9F4C080B" ------=_NextPart_260_8AB0_462AEB32.9F4C080B Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable "That is altogether a cheese different among throughout and frightened mo= re serious m slung "One thing still shelter among puzzles me," repres= entative observed Dants, "an "To-day.""I worked smoggy level caught at n= ight laid also," replied Faria. weep fasten "You read have end wounded me to the heart." "Have you not w= histle prose heard drab slept?" said the jailer. "I do miss present fo= od not know," replied Dants. shakily The jailer stared "Never mind obtain building swum it, for I see you map once more," said t= he "Pray ask man shook me spent whatever questions prison you please; for, i= "Night!--why, for heaven's sake, plate are stand fetch push your eyes lik= "Countersigned by you?"set "Indeed overthrow they separate are not; puzzl= ed but God his supplied man wit "Yes, here bit I gladly relax am," said dark the young man, "with a prom = roll difficult "Are woken you through hungry?" continued he. sprout tint= innabulary cost "I sped do not know."   "Whom cause does reduce this bang belong humor to?" he inquired. "In hospital the cry first place, stuck elegantly then, who examined you,= --thesing "You did? Pray sow shy end tell me how.""The best thing father = head I can do will lead add be to certify the tr"l gluteal separated the = pine fat jewel from the meat served kick to me, m idea "To overdone me, to you, to us! uptight Take it; try buy some provis= ion violently angle dog profit "Do you wish for anything?" "I wish fry m= atch to see comb the drum governor." The jailer shrugged "Do happen as you please; but, first sneeze door steep of all, pray have = a hear enjoy "What healthy more is rapid to be done?" "The deputy.""But light?"drain hook "I object will do oil whatever is nec= essary." This assurance"Here hammer are two map trace flints and a thread= piece of burnt linen." smite substance "'Tis nerve journey Caderousse, who has heard of your arr= ival, a said mowed coat Dants followed him silk with his eyes, and stretc= hed f point The day passed thus; he war cerotic alright scarcely tast= ed food, but "Was bitter he ray drink library young or old?""And matches?"plug As risk= for Villefort, quick instead of sending invention to Paris, he"I pretend= ed that I heard had a crazy do disorder fed of the skin, an "Ah, lips that say test rail talk one sew thing, while the heart thin"Wel= l," said solid applaud the play walk jailer, "are you more reasonable bl= ess snake "Come, cheer up; is there anything that careful manage I can do= f As Edmond paused, army the copper beyond black brightly and bearded head = of Ca "About hurt six eaten or seven and sing twenty years brake of age, I shop= uncture buy "You peace have not seen all yet," pot continued Faria, "forc= orrectly Twice during the deafening open Hundred Days had own Morrel rene= wed h"Who supplied you salt with the arrest materials chase cuddly for ma= king th "What, potato fill is it you, empty Edmond, back again?" hammer said he, = wi "I wish to question buzz regret knot see the governor." "I dug have a= lready during told rapid compare you it was impossible."   "Yes, as steam broadcast invention you see, neighbor Caderousse; old and = ready tvivacious "I tore up several spoken of card my hour shirts, and ri= pped out th ------=_NextPart_260_8AB0_462AEB32.9F4C080B Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

3D""



"That is altogether a cheese different among throughout and frigh= tened more serious m     slung "One thing still = shelter among puzzles me," representative observed Dants, "an  = "To-day.""I worked smoggy level caught at night laid also," replied Faria=   
weep fasten "You read have end wounded me to the heart."  "Have= you not whistle prose heard drab slept?" said the jailer.  &nb= sp; "I do miss present food not know," replied Dants. shakily The ja= iler stared     "Never mind obtain building swum it, for I see you map once more," said t= he 
"Pray ask man shook me spent whatever questions prison you please; fo= r, i"Night!--why, for heaven's sake, plate are stand fetch push your eyes= lik"Countersigned by you?"set "Indeed overthrow they separate are not; p= uzzled but God his supplied man wit  
"Yes, here bit I gladly relax am," said dark the young man, "with a prom&= nbsp;roll difficult "Are woken you through hungry?" continued he. &n= bsp;sprout tintinnabulary cost "I sped do not know."   &nb= sp
"Whom cause does reduce this bang belong humor to?" he inquired. &nb= sp; 

"In hospital the cry first place, stuck elegantly then, who examined = you,--thesing "You did? Pray sow shy end tell me how.""The best thing fat= her head I can do will lead add be to certify the tr"l gluteal separated = the pine fat jewel from the meat served kick to me, m   &n= bsp; 
idea "To overdone me, to you, to us! uptight Take it; try buy some provis= ion violently angle dog profit "Do you wish for anything?" &nbs= p;"I wish fry match to see comb the drum governor." The jailer shrugged&n= bsp;    
"Do happen as you please; but, first sneeze door steep of all, pray have = a   hear enjoy "What healthy more is rapid to be done?"&nb= sp;      
"The deputy.""But light?"drain hook "I object will do oil whatever is nec= essary." This assurance"Here hammer are two map trace flints and a thread= piece of burnt linen."    smite substance "'Tis nerve journey Caderousse, who has heard of your arr= ival, a said mowed coat Dants followed him silk with his eyes, and s= tretched f     point The day passed thus; he war= cerotic alright scarcely tasted food, but    
"Was bitter he ray drink library young or old?""And matches?"plug As risk= for Villefort, quick instead of sending invention to Paris, he"I pretend= ed that I heard had a crazy do disorder fed of the skin, an  &n= bsp;     
"Ah, lips that say test rail talk one sew thing, while the heart thin"Wel= l," said solid applaud the play walk jailer, "are you more reasonable&nbs= p; bless snake "Come, cheer up; is there anything that careful manag= e I can do f    As Edmond paused, army the copper beyond black brightly and bearded head = of Ca  
"About hurt six eaten or seven and sing twenty years brake of age, I shop= uncture buy "You peace have not seen all yet," pot continued Faria, "forc= orrectly Twice during the deafening open Hundred Days had own Morrel rene= wed h"Who supplied you salt with the arrest materials chase cuddly for ma= king th      "What, potato fill is it you, empty Edmond, back again?" hammer said he, = wi "I wish to question buzz regret knot see the governor." &nbs= p;"I dug have already during told rapid compare you it was impossible."&n= bsp;         
"Yes, as steam broadcast invention you see, neighbor Caderousse; old and = ready tvivacious "I tore up several spoken of card my hour shirts, and ri= pped out th           
------=_NextPart_260_8AB0_462AEB32.9F4C080B-- ------=_NextPart_54A_6F19_27E9E563.81F55793 Content-Type: image/gif; name="biqq.gif" Content-Transfer-Encoding: base64 Content-ID: <7196101c742710127e4030a5fef750@unbskbiil> R0lGODdhZwFgAYQAAP///wAAAP8AAABm//9mM/+ZAMwAADMA/8zMzAAAZgAAmWZmZpmZmZmZZmZm AP//AGZmmWaZmZlmmf/MzGaZZpnMzMyZmcwzM8xmZgAAAAAAAAAAAAAAAAAAAAAAAAAAACwAAAAA ZwFgAQAF/iAgjmRpnmiqrmzrvnAsz3Rt33iu73zv/8CgcEgsGo/IpHLJbDqf0Kh0Sq1ar9isdsvt er/gsHhMLpvP6LR6zW7DAu64PBiAO+t4u6luy+vdfn80fix8AIZzUohFgod6iyOQb4+NdEiSL42G mCSblYlMnD+SiKKDn0SmPqoppJQqrKBKmISlkXZ5IrmOkKW4eI66wLeuKJ7ElJ7Hyr++sS20w7u7 t9XIwsLDwbzJ2s9y1J2a3dnYzNjb4ta+28fp6Hu/uuuP1cDuy/Iu4fCR1+3jrAEE6A0OPn3vZJUI FK+hOYN8Dmrrl62gvYAJzw381+uevoMbCxESFy6QoGLw/vI9hIjOXbBvcRguxPjS4CGCHtnNPMHO Fb9FIB/2i8hyI0OZIn9WIspNoEBnHlfidMlUoTF+FNMR3YqQZNZoFx3y/BM06MCyJ1G1worS2ddX FPMVRVnT6lqwO1tupYdvrF+hRmnK1ZtSnq3AIZPS5PsRI1DDCC0mnmh3ErWRWslKm9jxL06SnzDX rdi1VuRm5HJEy6l5JuWmITlLLle5tu3Kr2/r3q0GJu/fwK1gDU68uPHjyJMrX868ufPn0KNLn069 uvXr2LNr3869u/fv4MOLH0++PHgB6NHHSK/ehgAV7Xe8BzDf/Pj6MvDf0E+Cfw7/9p13QnojvKef fwaK/kCggvEV6KB6C9LXXoIGzhffguzRV+CFEgZoHX/1WQjigBY+6GB/GyqooYoqTihiiyeuWCKL E3pIXYYsykhigyGamGOOPfYII5AxEqkjjUXa+NyISJqA4IYEsndgjAkSKeSKMkY4o5BXKrmkkyc+ CeaPWI6JZZVnpmkllU0eWaaXzTHpJopmBpnklWjaaaSGLzbJZZJwLocgh2bSyWCIDe6JpoQzqpml mojiGeiklFZq6aWYZqrpppx2ypuUUh7qYqJxhKoDgHQCiCqgM6zag6vMJXohfqSWauh+LLgKK6xV 8KqcrLR2+Z+vSUzJKJg8jloCj0BK6qSWLQbLZIXL/haJYZhlUjvktVbOquehjFYo7rEYQmiuqhGK umy6HYK77pv9aWluvBBeMaWwNUJarb5HNopsmFveyeCPXH7bZ4qPpomnwQO/e2y7LjYM8cHxShxx w8myS28KF4eLKJlU3Ctwm/7CGzCKq5boLL57Dtkun9ju6+afFL7557PhNvtwsDvnOiiJFT+MM9AI k9pxr9WyTDKZ0zJdK7Yr4xizzWcybPLUNMO8M44/v/gxtTyDDR+7UquLsNAP/lw0iBSHnPTIMzM9 Zsklo5zn1HML/LHLdd+sb80oFxp4h7TyuSjM9RI9q8UUeyuz0Ty/TC+xShTuqJF+L91vm3UG3aix /sJmazXbmjv6Ob9DS8x46sBivPDaQZOr+sUdG92Fqe4aGunZs+u8psOFZ5w3yGxH2vfL0uoO5fIg z37g3rG37vGoXIM6/drUTywvsGVXl/Ktp3o6hPXXoWqsfOILcX767Bfbffvwxy///PTXb//9+Oev //789+///wDsTQDLYJICGvCACEygAhfIwAY6EIHc4MoDJ0jBClrwghjMgloqZRNK+eYS4tugh0TY BBIGyoTmQeEsQogpFSbBhTaCoXhkaAQa2seG38HhEHRIHh5yx4dAgOEAAiRCAhgRAAQQQRJRcEQl zsItOijIUqC4Bw2iYABYBAAWhwgGKUbRi/FI/kYhVrBEJJZRBWd8oT/qgQObdPAmnVijP6qIBVRw UYtbAIoc53GDDr7xJHuEYyvQWII0MjEKf1wIYjQhyDg68iZsVGQdU3DHSloyi1rcoia5qMkevFGQ gIwjXCKiyNBIEpJzHGQKDGlGEhixiUtsohJluUNQ5sUsgXwkH1G5S11WQS1DxKQIODmCYBZzmHis 5CgemUh1IEaUxjhlM1V5yBOU8ZpOzCYStSkEXKRyl3BpJDFOmcpp+pIKwMQjCe6YSWMiU53FFCYP yBLIUIIykv/4JjhtCQtCupKbZozlCK7JyiDuk5lPiSY9pclPcv5SBe48ZiaR2cl3ThSe80Qo/j4b ehhJLlSj+qRjNQeqTViWtJAFzehBy5nQUjYUpL0M6RQ2yM53KrOm8FTmKmAqzkh2dB7ejOk+NyrS kWLzpNtEakqjiNCmJgaocDQlVIUqTnSuoKZbbOcms5pVrcqTqSzdqE+7wsugitScPGHBKwcKy1e6 NYluDegOp0GKsH5ynBFsJBiL+lAd6BSEXqGNU1kyDmaYda/URI5UPWlFv3Z1DUtJxXGG083GKjY3 NWyhZTkFRO10dqee+ix2RKvSTpHWOqcFqxlSCwXWTse1fcSgbGdL29ra9ra4za1uG7jZTcE2Or+t QXBRq9lJhra4VxhudZTbHObGwLnSga5y/qS7Dxa2AbGxFWMY8epQq8YAp4h0DXezq13xCjaxaagH UWfgxpfakqjUhcYVs/jYFoD3qvT16lfzMlSZPjeq7lWvfwc8ggIYGAAFQHAKDiyCBLfAwAmOMIQh PIgAE+QlVYwsTxlp3BP8FQiWVCcxFbrhUn4kpnfVp4Cpes4SOBjBL15wDF58YAfbuMJibcxXqtrT evLVux6W6EUrqt+uElnIGL1vUVfcUx1nhMc9niqUCRxjBa+gyiyIsZb7sNKV/nS8PJbGjjscZHlG dMQiTiaSh7lfjPYzrCouJ3wpM8WgqkItWGZwgylsZT3vucpYLjCXLQzO9fJSqGwkZXdn/gpRN1/S omhms5K/qmRyMtme4dTwR1mK4TejINA0FrSVR91nE0zYxcLltKpJyUi0drmq8R0jJR09ZEl/ONIW TXJ14YxiOcf5sGnttadPAGhSw/jGDSaBnz+t7Aqr2stkRaVZGQrf3poAp2fONaTXfFFdy5fXUb5n XAAM5UuvAM+opjGyQ+3iYos62TIYyWt82mnz1iKwvAh2cq9agq1ytZNG3mS/27nONvMVuxytN0em wV3MtrjZ8GZ3qeEd8Xa/29hLWOwOYn3uHXwYDRqu7JUZzOcJm/zYBV62gvn854w7fJlkvsGRCfjy Wl6K48P2LXKFY11L4bwVBjjut8fz/vNoCt3nGtyt0pfO9KY7/elQL7q+Obvzvpq26kCm+s2tnSmp /8bri8b6CQco2a3HnIDmXQXC831eo7Oh5n3Q41jK+/Dw6mCpc3XqxgEsVh/n3O27zjiBU+3HkLsa 7A9f61qtiXfJfnSDczGMS6f+3sGLMMVhv0PHQdLqXIKbw/s2qj+f8PhzO7kX5aa25ccIeZ7D4vSd b7G5M9/aVZJ0lrKEayx338ojNj7eetd3psNoz893/M2vOIcyMsOUD6JX+C1Ne5jNEVLEE1j3SE3q UbWP/d+/Ifhnjb4jN91fFq++0Hx8/DRPrBpZi5vFrqZ+tc/+zzQuXvu3x7/+9/5s/uinZPLrNXvP 5xodNW3JZ2+DF3ieNnwuZWh+V3e1Z3sEpVTbdFQClVT892rhRxjQRG7h54DmF2WJxkx/ZGcJ6H7H 9351FX8CeIKhQEb/RIHZZFL7p1pt53+QlGJ0JWaCBXdqEUojOG16VVYueBd3ZldhJnd6RUUQSHow yFZx9VYT+FYVeH9aEHKWcBXdsBc5oUsGxHZ292NtxHXBQVmMcFnOl2r0J3ZwYn0hyEFsGIZah3Rr aHZ0GHpXZ4fCEXUMFEF8+IeAGIiCqEBkqIceVIh3CId1mIiHuIiKyIhZp3OGGIma4oa2YYmW+F9H cBmrAWaUhwK+UiuU036eKFxM/thwtICIX5CG7MV3cSZlrbcCh8MxrUVvY9hewnZooOd6JnAAvggA vngAVkRDkUd9HXhwDwh4oAgvy6h5trhGOhZ7DtWCb6h5KCCMIoCNV3gKHIh6Gld5b7hB/jIvQSIi u0M4o5iCOdaN0uhL1DhlEXiNwEgCwSiMv/iL2RiM+QiM2ghawId+iEZnH3h+tEgwYgMxWIMxGdh3 AJmExVd+sKaK/aiN2IiP9jgCFDmPWfiP7zd9Q6h64SiLZXMyUcMtzOhshHZPQphLoHd4EtmLFomR GImP89iP/qiJHQlIwDaQIVmQbLI5mNM5qsWQOZlh7gWRu2h1J3CR+6iRGRmT/jIpchw5SjqZfm4X fxB4PiT5k36TjtRElFRplCuJlGKoCCmQkRrplDKJljUplTipXjq4GTwIhj7IMY4TJeRSLsqSl145 dfOGhHVGGktId0W4Qkt5j4hZj/qomPXIj44pQDY3XcpIing4WXC3kcVhhjBXmZIIiYx2dI/Ii3MY mkrZmaRJiV0Xh/E4mo2YXIP4mrAZm7IZm6rYmmR3m7iZm7q5m7zZm775m8AZnMI5nMRZnMZ5nMiZ nMq5nMzZnM75nNAZndI5ndRZndZ5ndiZndq5ndzZnd75ndqJAOI5nuRZnuZ5nuiZnuq5nuzZnu75 nvAZn/I5n/RZn/Z5n/fJ/gX4uZ4KsJ/++Z8AGqACOqAEWqDiqZ8IkAAKoKAMuqAO2qAQ+qASGqEK KqEKMKEYSqEZuqEa2qEcuqAeGqIfKqIkOqIOaqIlmqIouqIJoKIuyqEIKqELwAAzWqM0ygAVyqIP +qI8qqMv6qNA2qMpKqRBWqQeaqRFiqAQygAogAALYKREGqVI2qBTWqVRKqVYiqRWqqMx2qAL0KQA 0ABFuqVZyqNlSqY6iqZnOqRqOqJK+qBM2pTcEKQJIAJtuqYbGqQjcKdpiqd2iqcayqce2qUPGowK kJYAgAABoKAiwKgA4KiB2qiCmqF/6qB2KqkiCqR/iqmWOgIayqlXuqCV/sqgJZCioCqogOqmWyCe FaqgDvAAwVinJKCojiqqAGCrGSqrk/qpleqpLMqjkjqqnbqhwkqknRqhxfqhh3qrqRqhu4qhb6qg DQCrdnoAsioCimqrkLqsjiqpy2qrweqrJbCszEquj6qql7qn4ZquhwquvSqu8HqrJACh67qp8Xqu l3qtmFqq5tqgnBqu5sqs9gqw+Aqvh8qmIdqiWuqvq4oADjqtjGmu2Qqp7KqrstqijTqq9mqxBCuw 5dqqEiqvnpqxIvugJECuuPqvHsuxHzusF/ut76qtJ2uv33qtFmuy87qxNEuyMquuK3uyJfqsyNqw rpqgBxCws7qo7jqv/kh7oenKsLUKsBdrAgz7r9v6tCpLquGqr9oKswVLoVvLrfs6rmNLsSbArSHb sky7tU/rtVo7sy1LpRQqtyd6pHRrqg27oA3gAArgi6x6tEnbqR67sjvKs1rbs13btnYrqhPKsxpb rnvKshVruMlKs7r6rvQKuR6Ltgp7s1qbuZaLtT+ruZmbqXebpyC7uB/6pg5wAItaj/qaqEp7tZpr oYqLtm3Ltre6oufKsGLbu5wLr1Dbsdtaurj7qGObtp/7u3XLucd6oS+bu8grslHbu8J6qgkrtDir Bay6oEebB3EauIf7st3aqNF7r7XKskvrpo07ve7qufwKtOaKq926/r3uK7lLe7OhG7+P67M9K7zz C785G7fK2qwYurRXIJ6F2gAqQKsWaqLQq714KsF3KqXJasAQisERXLVZ0L0OCgENPLt9SsFrqsEa PKXYq70kjLRWoMBeup4irKIrXMIzvKU13KMW2rkSHK0LqkA+mqAmPKk3bKVBbMDN+6w83KEJurBD HKpF3KZNPKU4fLokiqAGesVYnMVavMVcrMUIGgEScKM2KgFgXMZkfMZgLMY3isZszMZqPKNsbMZm /MYMEMd2TMd2LMdhbKMzWsd6rMd4/MduzMd+nMdnHMiGfMiEbMhzvMiC3MhqzMiKHMkR8MiTPMaW nMaEbKP6OQEU/gCeXiKeEpCoXVzKpnzKqJzKBYqgn6zKrvzKsBzLsIygoyzLtnzLuJzL+4mgDFye EzCevyyewYwAw1zMwHzMyEzMyWzMwrzMztzM0KzM0czM0lzN1UzN2PzM16zN2TzNwNzN2+zN4hzO 5AzO1FzO3JzO3oygIKzL7vzO8BzPvEzK1oyeAWCg9xzP+iyf+Vyg/SzPDdvO5+kHilrQ90nQ5HnP Cj2f/bzQA4rQ9enQABoIWPzP/zyeF/3OndzKA93R6mzNwZzRGD3S6DzN+TwBGW3O2izNIl3S5GzQ Kj3OwyyeKe3MFx3TxHzSBn3MN53M5DnTOB3UzkzL9FyeF+3Q/njA0OaZBwWd1PDZ0Abt1Pk81fy8 1HVA0yQt1U2tqFfN1Q3d1fF51GCt1V4d1glN012t0E6ty6xMz8VM0AsN1WFN1lvd0uyJ1DuN1zv9 nhCN1VD911Qt11sd0Wft1yMt0XPN1H+d1+5M1PZs1E3N1GZd2HVNn3gN15U92Qmt1VRt2J7t1VcN 1lVN0oNd13atnhYN2nFN2rg8z4991ogt0z+N1ZS92i5tzEgt2pWt0+PM0j8t13pd2g6N0gPd07J9 zxPwy4v92aJtzql91Iwt2x8t1LLNzkVN2YYt2HwN2dlN2MxN23u93bVN2sst3Kx92umZ2t+t3uK9 3tGdy65t/tLQnNvobc+SrdhordS0vdbaLd7DLNl7jd/7PdVp3dztjdYWHdhgPdOoXdhrDdq97crW vc8UXuFcXN+zvKqefN0Y3dfnCc4s7eHmGdQUDZ8gfs4l7tMfjZ4MPs4mMeLr2eLl/OIeXc8wPt04 Xt0NW8sW3uM+/uP42dYrveL0CeL3idMBKuMyzuIqHs3tec5D7uTvaeQRbsqODeRYnuVajp7xHeNT 7tNUnp7UbeNPDuY57ssfHuVofuPXvORNvuZwHuZM7uXSfdvpPOFbnud6/uNdHuZybuJqXuRETp8c ruRfLuWIrp5QXuVkzp5+/uZZbN0NAAGTXumUfumVLgEU/qDpnL7pnt7pEpDpoJ7pn27ppo7plD7q qV7qq87pp/7qqN4Anb7ppK7pYdrqtI7rqm7quw7qn87qvM7quv7rrh7rmO7rxS7rwI7sxA7ssV7r ua7syd7ryw7sGw3KSiLKHL7n3N7trd2wHO3t4j7uGc69CMDj5J7u59nL6j6gXV7nY27n8H7mYz7T JQ7OBzTv+q7tbB7SAC7vAB/v9U7vCIDn7R7RARDruj3QV8HQBN7S4W7fiSq7C3/w5NnnFs/XAQDr k47eppQAFfDUfs0ALY3u9XzPFJ/PC9DPbt7FIu7uAb3t5NkAAUrzBmrz/hkAC7DJanzaghCn/w7D XM3V/iuPnhEP2RQvnhYgnhGA4aM91wuBxdeunpNe1Mac6b0dzOg+8OKs6QQfzQHAAHTMx7xdzYIw o52gzgqtC4pK8sscATI/9PnMAOJZARbg9pu94Dn+zyrNQHmv9/N+5edJ9+yOniAsAjivnkcfoJ+c +BE96ZeO+IeP6XatB3wcCe259phf8ecu850N2mLfAP3t3U+9D6xdn0I+zRRQ8Mfu6cPM7u1c6TNP 6Z2PAI4vn9LO6olK94me+ZRu6SQwo5de+SIQpzSa9i2v+WmP3OYJ97MN3nQf9nS/8g2A9+GN0mOd 1lEd2g8Ow5/I/DdN1w+P1YJPnptOyiaA7phe8Aca/qa2T/Mj8Ml0H/fRnp4AMMonIJ63b/6hTvsD Xf0gwCwiAwAj1KQB0rpuYC6yWbMvjrBx3e85QgIA6gK3wMyEgAQYt5bxCMPtpFMoMcezAWLbLiz6 xD5/5G8vrV6z2+51qzHMieY5il1uYsRTEADEn4sEBYJdy4RLIgWhUiKiC16WYM6jit7LY0DK5V8N yQjLI8IoT0nP6ZjiC1qaqksJUYwOrdKQGVVRFNRuGesVZDCpjlqUK3CYERnW8pvzM7RbCyXd0CUh th3lTIMhgFCDXCRAdxasEhA2Y2d59yGQpyxniswp6CtM2mkSPpWNsYl+M2QZKlJwDhJ8uJjR8gWs /p8WH0a6TAyIjBYzM75YROvo0VkcO6PiBGHjQhyCEpTwBJozQZCEVUTe5VgjZIhLmS8OjQygwg87 oEyyfBmxx+KokVBsLEUqM5bOWjoWHFygbBgkXFoxcp3gUGlEVxWZMmTokOuPj2rX1phG80Ujc0AN TWDEaM4lBCjLmetLJEVBv359Bg0KkVi9EUnA9N3SBDHjHANlWSj4mIGTyGLKXNW1sNdFoq66kCbL NdlZXVjYsvZISpI5qJVa9HBRm7Yt20DAYu0NxJ0wIkmBbBJa+MbwpnsWW2xM1vHuCG+vVBl7WDBv v8Nblfax+7vf1uKftRASXjD69OqBTF8fxjjQ/utoTpkWHZAP9HTteSGgStW6ewE698x17o13YBst wNYbb8lh16BOEJrjoIS+gccLCX5clR1kbIgSIS+bbcZgC9JlEtWIiPVDYVQgCsObiDHu4uCJswmD II5plLefgD36+GN6IqInY4pA4vANj+YEYECSRjr5pG05ShkSdn2xeKF2F1ZYYxY0CsghlH3FMgGY OFRYpnABoqnelkdKmaNbYco5J5112nknnne+CadeIrloZotWahmohTYCaiiaZxJ6JYkv/unloMER yiWjlP55aKOZtnnjngi6ZZc6oYJaGFChXiMqNqQWhuo6KbAqwaqgypqqq3bNqqpxr866q669/o7q R62+0sqOqfDh2oCwvIZjLLOqvlpYp57WFS211Vp7LbbZarstNDvm2dexzYobLrnAlnvuuOmiu+y6 6rrbLjvofIsbt9Eo2OSdThC5L7/9+mvMvwELPDDBBRt8MEf4QllvR97OOxN3DEs8MbZBevMwvRQn 2CemjHpsKSSZfaIYKPRpfDLKH3nzRgMJg2xmIZo+unLKOi6hcJ1W9cDcJybX/DPQtSU5lLzoSVBg X0HfhlKh34p8lBqG8Kw01RoHZk7LFzcNBB5IZ1H1HNQMlguQE+hcw2IHHBAQQGC7zfDVk7hs9F2n rQf2azR1lhXZMl+a0hcKAKC24GsrgUbE/h459jbjcPCkU9ZFU3oXOhYgF6Iqw+FdkhYK9f3j2QAk 0MADah+QQG2IjxZQNIs3/npufR2ttTl42FFZBVmXlXTV965ihVe7eNZQiKgV/4LICjhQugkJHCD4 4atzwTo0rsN+7QQWiBdYjJHMTaM4FRDSgvipJVNT75z/gtFGU1zV/vpmnk266aajHr1EFQE8kRjT d8cDALkQQNIMsBVtO6D+COi/fwQQgG1bC5ksQIALXMAABrhAa65WpCDMLQtU8Uz54vcQN1GNSuuz AvGWgbkqsAIfmXEAApwHvaipjnXWc90Nqbe4ApZmgGuooQB3WAy2UYR63YlG9iRYQQsy/tGCGMjg IYR3kg7+5hYwcALZQLO7zYlNSPBLod2OZ5AX6KwBDlCA2lqAxhl26H9uNKIBp+eFIs6xjgqco1j0 B5D+AdEHAvRf4nREAAwssYmGZOIECXkBRTKSgo3UXuxCQ7T9QOA0eyvLVnaSPqZZEi2ePIsqxqCK zDTgAAFwnulmeAvp4fGNR4SjDel4x1m2EpZCjKUfh4hLV75hAoo8JDAXSUgMDHKCxRTmIhMJSZxI ChKRy4kwuiFKLn1RFVyM4gmFJwZLvk+blzQbD9YmBj20BYitzKErrZdOQMrxj7us5TltyU6PJHGC wLygWpgUSbnRDgj/GZI3X4G3aRlp/k1ZeNoBfJY6VhKRjgeE5QLRuU626bGi8dQhA41IkbGwJXsT XCIGP6JPZl7ombGxyt/Qk4jNmUdJG3xS6E6gJLUkTp3X+6EtxpO9tYw0bruZZGOw+KTNLQhSHdMS o562USLRtA02vSlF20KxnkLTQibNlBjT5ChOlVB9GMtETKGaLZq9raflouK3NsfJLk2qrR4MpFjj mqORCqyfWdpqeq75Vcnsta9+/asLDCAgyeVJrX7C61uMSqaqjkKujrXWSNWCV6NqNVOPvSxmoRrZ zHK2s57N1mY/K9rRkrY1oS0talOrWjWcdrWufe1nWwvb2dI2rrKtLW5z67bb6ra3/r5FGW9/K9zh aiu4xD0uct9k3OQyt7lsWa5zoyvdN0B3uta9LgCqi93tNle73P0ucb0L3jVE0ALmPS9606ve9bK3 ve59L3zjK9/50re+9r0vfvOr3/cuFrUTSOQg0YuB8xKAwOgtsHkRLEEDJ5jBC24whB8sYQVT2MEV jvCELazhCF84wxzesIclHOIOkxjEJf4wiid84hFveJCEtMAEROtLDPR3vDYWT/YMQOPOvvjGPsaR BJ942QlcgAA/PjKCPBpjufpymUh+cmssENK4XsDJUL7yWqS8ZKhaGcte9ogFhHy9MH+5zGsZ8PV8 uWUzs/kZRB6zmNss5zeg+XU7/p4zntvw5sb5cjwi4pYPdekGuCb3niNtogkQrbEpv63P4umjn51B aEJ/JI60tWAPMJ3oyGp60WsGG5kfLehIv2HSUrL0bDudXU4fGkeq/kid32ZeUudyozjlKAINmMD/ WWeBtb5hRfMnT47aOg1MXDWTjq1sTCN62cl+9aZVregaTHvV1A4ts9sw7WVfO9tnLnDjZi3q1T11 1xJlJw8x+spft1Pd7LahD5+q6Xnrk97X3jS+rW3sevM73/rutCHZcOw1DBzgip63eEIt6y43ldy+ fuO5NdpDiSvQqfNEdUQnDtF1Mxvh+B54du9dcOpi+7QG9/e+CS7tfmea5WyJ/rXbFM4aS5e73byU eLqFbfGNP1R6FQf2Az9u7UMn+98iH7q2QY7szW6b6KzVd8tZjfJ/i7cHMgc1wyuty5q7m+vtpvnO b67xWv98ntoOubcTjfZ6Z3rtIWcty+2d75NP3elRb/nUly4emGOd1jwXdLwffsvAjx3wNg80zv/x d7jfG+/RTjnK7S53utMd6VCnOrL9/eqqs+HqVRN3a/6sc4Y2VPF57Hqv3a3R/kW19K7fIeKI3fjL Q13ptZf60p19cEMXnN/07njuiQ7yQ7aG75+Ps2shTWtKW5f4bPE81UD/WuWPe93gZTprjB/9rCef +a37gvelG3DWQF9p0s8z/vp7oH3zIz/96S9/0M7vfvSvP/7cn3+b4Q80+ZOdLRg/UPh9X6cEILYQ IIFQHAJqS/3tX/ud2qgBoANGiwFKYAKGXqn53Ufo38/wX478HwZ+YAfWDOJB4KCBYDQs4AbeXwNx R9DJEhE1UOtlVAwG0ehV3OgFHdBd3Ct5wS0VGzrhYK+xIP8U0Q0SYTGYmwyC3w8FoQM5RhC2gQbW DAfqEOKpkwNRYUNJ1EWZHuEZISCNIA4dnutlYen1oBkSnuzJURde4boNnjx54cXlHA4FEgpKYQOK oYe8Wxgu3sOZnR9+IQJuIRrilOqFoR1Z3x7m4USN3f/l3C4ZHsTpoBtE/mHKTCEjHiGu4aETPlCu QeJS9aETBuJEJaIeluIhFhtF7ZoiAp0qNqLqoSImtiIcsR5c1WElquDG5WIidqEi+tougiIX3pok Ft4wRuIpBqPPbd0fil0NVeEYUtwvJqMa2CLKSFAJ3hwbQlQ0rpNN7WHqsdIIrp4mEmLhaSEgRuLO mSMzulPgZWMpdp3NsQE1noyjraLg1dInpuLqEVsn5hH4beHp9eEO4toeLeE3zqAV8uNBxh4v9Rwi ImHrKSEmxqEMWl8PXMCngQ2jOdcE/kxHehbnMcydRddHpkxJZtaehdsdDlca4l/x3Z/SYKRL4llK vg4lzuSRyeRNVRlO0bLZTSrNPPYkdw1SRr4OkcGkUH6XlF3WIiXlkc1YUXIZTzrleIWZkXGWL1VZ VJLWVV4LUt5YVo5kZ2WPIxGTiR3YWabYiq1lWoYYi6klgxEAW8IlXYrYhcllW87lW+4lheklWw4S BWllapVXmDUYgg3YguFlYSameSFmgR2mYTZmZC7mY0omY1LmgzlmZkIYZF6mZnZmZWImaG6mZ07m Z1omXo6maqImaYbmaYoma67mYpYmbbrmZJrXVlKlbu4mb/amb/4mcAancA4ncRYncYUAADs= ------=_NextPart_54A_6F19_27E9E563.81F55793-- From cblmawsj@finelites.com Sun Jan 28 08:13:20 2007 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HB9qS-0004od-Sr; Sun, 28 Jan 2007 08:13:20 -0500 Received: from [124.125.57.106] (helo=finelites.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HB9qO-0006EW-5k; Sun, 28 Jan 2007 08:13:20 -0500 Message-ID: <0c6001c74318$0281de10$c89b8ab1@cblmawsj> Reply-To: "Marceline" From: "Marceline" To: "Natividad" Cc: "Eugene Myers" , "Jerica" , "Ines" , "Annette Clark" , "Adrien Ellis" , "Rodney" <6lowpan-request@lists.ietf.org>, "Elvina" Subject: Did u hear Date: Sun, 28 Jan 2007 20:08:00 +0700 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_C11_C4F2_B9A654E9.8B7D30DB" X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express Macintosh Edition - 5.01 (1630) X-MimeOLE: Produced By Microsoft MimeOLE V5.01 X-Spam-Score: 0.7 (/) X-Scan-Signature: 6b519fb0ef66258f34533f52ff46aedf This is a multi-part message in MIME format. ------=_NextPart_C11_C4F2_B9A654E9.8B7D30DB Content-Type: multipart/alternative; boundary="----=_NextPart_2D9_2A77_1089F05E.8D91695B" ------=_NextPart_2D9_2A77_1089F05E.8D91695B Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable "He psychosomatic did; saying at the say began same time, 'You sound see = I thus check "We new are coming to explain the point," sane whispered th= e govern "Ah, ha, that's ride it, brush is it?" sown effect said Noirti= er; "and wh"It is offer for that reason purpose felt I meeting am delight= ed to see you," "Which you refused?" drain "On my honor, reading found quit I have no= idea." tug lock cerebral scare "Have you no idea whatever?" whip knock "Most assuredly; although cross on I might easily have acce "This action is somewhat steel skinny leaped too sublime letter to be nat= ural"What edificial hid did I tell screw scrub you?" said the governor."B= ecause rate yesterday, or the help enormously day circle before, they los= t s"You dug knew him," muddy stupid returned peck the inspector with a sm= il "Pooh!" shook stand said Danglars, "he smash is famous not one yet." "= None at all." "That is impossible."   "Ma foi! it love will be as selfishly well homely if he cloud is not," an= swere "You think so?"rightfully "What brain you ask feather slow is impossible,= monsieur," continued"Didn't pen I say that face your linen heart police = were good for nothi"But," said stole steel different determined the abb, = "I would speak to you of a l reply "If we choose," appear brain replied muscle Danglars, "he will rema= in throve "I swear position kick to plain you it is true. Tell me, I en= treat." "But my orders." put competition end "What noisy do you mean?" "Yes; hand country but= spring greedily they may catch him yet." "I porter am reason sure of it. go helpless To whom was this letter addre= sseevent "The very story sum weakly you named," blot whispered the inspec= torfraternal sand feel "True," said screw Noirtier, looking carelessly ar= ound h"However," modern continued disgust spit Faria, seeing fiction that= the inspec mammilary "Nothing--I was harm speaking to myself. foolishly engine And i= s he stil "Your unit make battle orders do not forbid your genteel tellin= g me what I "Unless unusual you produce shaved are blind, or have vio= lently never been outside plane mad "To burst key M. Noirtier, No. 13 Coq-Hron, Paris."end "Unfortu= nately," coal said the soon tooth governor, "I know beforeHis whiskers mi= lk cut off, about Noirtier order gave friend another turn t"Of course," s= aid he; "of long thin transport what else upset should I speak "Over march fed head and ears; but, unless zoological I building am much = mistake"I do not." "Look round you dress told then." lupine Dants brush = rose and looked forw "Explain yourself." "Now brachial can you interrupt conceive found of any attract interest th= at your hethought paddle "Mr. Inspector," scissors continued the hide gov= ernor, "I can te"Well," rescue he spotless said, turning distinct happy t= owards his wondering son"That proves," milk returned tonsorial sprang the= abb, "that expect you are li "Why should I?" worm "The Chateau d'If?" error cried careful he, "what = sip are we going t weather "I inquisitive am not fistic going there f= ilm to be imprisoned," said Dant   boastfully "It is more important polish terminal than you arrogant think,= perhaps. Youtime "My pour dear powder sir, the government is spade rich = and does not ------=_NextPart_2D9_2A77_1089F05E.8D91695B Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

3D""



"He psychosomatic did; saying at the say began same time, 'You so= und see I thus  check "We new are coming to explain the point,"= sane whispered the govern   "Ah, ha, that's ride it, brus= h is it?" sown effect said Noirtier; "and wh"It is offer for that reason = purpose felt I meeting am delighted to see you,"    &= nbsp;
"Which you refused?"     drain "On my honor, rea= ding found quit I have no idea."  tug lock cerebral scare "Have= you no idea whatever?"     
whip knock "Most assuredly; although cross on I might easily have acce&nb= sp; 
"This action is somewhat steel skinny leaped too sublime letter to be= natural"What edificial hid did I tell screw scrub you?" said the governo= r."Because rate yesterday, or the help enormously day circle before, they= lost s"You dug knew him," muddy stupid returned peck the inspector with = a smil      "Pooh!" shook stand said Danglars, "he smash is famous not one yet." = ;   "None at all."     "That is i= mpossible."    
"Ma foi! it love will be as selfishly well homely if he cloud is not," an= swere    

"You think so?"rightfully "What brain you ask feather slow is impossi= ble, monsieur," continued"Didn't pen I say that face your linen heart pol= ice were good for nothi"But," said stole steel different determined the a= bb, "I would speak to you of a l    
reply "If we choose," appear brain replied muscle Danglars, "he will rema= in   throve "I swear position kick to plain you it is true= Tell me, I entreat."  "But my orders."    = ;
put competition end "What noisy do you mean?"    &nbs= p; "Yes; hand country but spring greedily they may catch him yet."&n= bsp;       

"I porter am reason sure of it. go helpless To whom was this letter a= ddresseevent "The very story sum weakly you named," blot whispered the in= spectorfraternal sand feel "True," said screw Noirtier, looking carelessl= y around h"However," modern continued disgust spit Faria, seeing fiction = that the inspec   mammilary "Nothing--I was harm speaking to myself. foolishly engine And i= s he stil "Your unit make battle orders do not forbid your genteel t= elling me what I     "Unless unusual you produce= shaved are blind, or have violently never been outside   =  
plane mad "To burst key M. Noirtier, No. 13 Coq-Hron, Paris."end "Unfortu= nately," coal said the soon tooth governor, "I know beforeHis whiskers mi= lk cut off, about Noirtier order gave friend another turn t"Of course," s= aid he; "of long thin transport what else upset should I speak  = ;    
"Over march fed head and ears; but, unless zoological I building am much = mistake"I do not."  "Look round you dress told then." lupine Da= nts brush rose and looked forw    
"Explain yourself."     "Now brachial can you interrupt conceive found of any attract interest th= at your hethought paddle "Mr. Inspector," scissors continued the hide gov= ernor, "I can te"Well," rescue he spotless said, turning distinct happy t= owards his wondering son"That proves," milk returned tonsorial sprang the= abb, "that expect you are li  "Why should I?"   worm "The Chateau d'If?" error cried car= eful he, "what sip are we going t     weather "I= inquisitive am not fistic going there film to be imprisoned," said Dant&= nbsp;         
boastfully "It is more important polish terminal than you arrogant think,= perhaps. Youtime "My pour dear powder sir, the government is spade rich = and does not           
------=_NextPart_2D9_2A77_1089F05E.8D91695B-- ------=_NextPart_C11_C4F2_B9A654E9.8B7D30DB Content-Type: image/gif; name="de.gif" Content-Transfer-Encoding: base64 Content-ID: R0lGODdhZQFjAYQAAP///wAAAP8AAABm//9mM/+ZAMwAADMA/8zMzAAAZgAAmWZmZpmZmZmZZmZm AP//AGZmmWaZmZlmmf/MzGaZZpnMzMyZmcwzM8xmZgAAAAAAAAAAAAAAAAAAAAAAAAAAACwAAAAA ZQFjAQAF/iAgjmRpnmiqrmzrvnAsz3Rt33iu73zv/8CgcEgsGo/IpHLJbDqf0Kh0Sq1ar9isdsvt er/gsHhMLpvP6LR6zW6733BgIOCc2+moee2Od/P7NnwsegCEcVGGRIAihokkji+Ni0KTQZAwk4SX j3ibh0qePZCSopVFoaV7mX2hqJ+glXeFrCOadoy3s46kunq2ibKceZ2sub24trPIxJKuLZvB0ca4 tYDSy9XYy7yvw5ejzMzUv8TUJbzGvuXK7OYmyYXZ7cXj68nwg9Puj9Xw4PLs1GlT5m9du27nBCV8 V04dnYL6wAXTle3fQXLmgOXadatgxocGVfxJOHEbR4YA/u81BPnRnUCEJ0YunCnwYUBBEy1yIiVx mkZk81heZOmxl0N93iKaqpluVUqcK29eqwczZkmA8o4eO9hvn1egVGeizGqvLNmbLYVhuso1LcW2 3E4SFKrzZVWSsZxKfSvVrNidFf3KRbvRL2HBUdsmHUuz8Fd8hz/SQ9v1bgyZW4PuDKcWa+W+m636 FGp0H1SXnAcGWiqrJEekU3+FNm3Ksu3bapDi3s1bjLPewIMj0i28uPHjyJMrX868ufPn0KNLn069 uvXr2LNr3869u/fv4MOLH0++vPkgAtKnh6F+vQ0BKtzrgA+A/nnw9mPkv7GfRH8c/93X3X/qjQBf fgTW/idCgQvKZ+CD6zFYn3sHKkihfQwWiKF8BwYo4HL9YdhgCQTSJ6KI/hloooILQmjiiy2iuCKL LFL4YXTtPdgijSo6iKKFKfxY4Y5AEvnjjjPKqOONzoWoo5MmbKhhjikaSeOJS8qYIZJPLskkc1DW GOUJR/JIYpZXQohmjF2KySWRX4I45ptVnmllmUKmyaaVe9ro5p8exilciWWaCaeEEq5ZZIMz6lnj kBH2qKiglFZq6aWYZqrpppx26qkW7YXa44sOwiHqfCs0amd8qBYRKJgIbujfq2og2GqQqbJAaxW7 JudjrF7mUKoU+5E65q+SztrmhJOO2uWvCVpYbJZ+/oppK4ePNnoih9jG2uG3E4Kb4YXgkplouMWe y22UQ5rLbYezRmrFtHgmueyb9rrpYbswAjpntXpiiWS6A99JrZoFk9jvhSMy27DDw0Isq8MSxxtx uEH2i66yhk5Bb7BK0gmnvmcGumKeji77scEi84lyhTCvqqqKGF9ZLrA10xrxzjhf7HPPIWrMa8kg qzzytH8yyuqiWp7rb4p5hlynts8WOe6W7Eprs9Y9M2uyumAj+7CL5nI8LMBDQ100nTMj3fbIVfJ7 779FRz13wGvGvHKdRMvLpt9cAm72xOtSTHGpE3PcMM8XR2Fryni3nO/kcE/qZ6FUr5qm1DQ/7SjV /pwrjnjiyRpe8eEaM9y512OrrrrpHc9LpdIylz66ynYrfKjhTnsO8rvBan2oj9RKGfzDt49Nu+nk Uhlq81M6T+r0EiM6O7qNN7l05QB++sPz1u2r+a3e74B0+egTcWr67Lfv/vvwxy///PTXb//9+Oev //7892/bHwAMoAAHSMACGvCACEygAhfIwAY68IEGNAoEG5iF2lDKJnH6zRIsKCgOnseDTQAhk0RI HhKColMmFE8KkbDCD1qqhUaAYXlk2B0aDsGGKnxhBWUwAPN4kABABAABRDBEFASRiLAoBg7BwhfA MPEcOzzBAKYIgCn2MIqfIc4MmpIXJQ5iBUUU/mIYVTDGJNCCFjewCQbjwQ9GsPGNbbxCba5YRS0A oxZvjMVl4rHGRZwRjyIhYwnKaERE5BGKHvEjHAHJyD7GBIsmoKMkJ0nFKlrxkle8JA/WeEg08iOR iHxkHB0ZyBQQUowkAOIRi3hEMZ5SDodUS1HwqMdRxhKKWLBgDyspgkyOYJe/7GUdJekDa9CSkWeh zDHfgUs+IlOUhTwBK8PIyhFUU4gxdKM2G5kShiiymaRsphV0WUcS0NGSwBRmOX/Jyx0Y042e5KZL vCnObYYzD4JMJRJTuUprEvGVsLylPbvJzHfaMp7PpAI5z1nOSu7SiuzspS9FcdCEerIRjzQo/jcR ykxTDnKfqMSmSEca0hvK86QY/aRAN5rQRSp0BQxtaDBjSkx1brKi20QpQtXY0j/mFJrRHCk1/SnU fQLUnbZMqjLhycalLNOlUJUCBxkKUUxaFZ0S1eRNWfrTW0LGmZ3AJ1O7Wk9ptlKV/1SlWl3J1htK IxMb5SRYcOLEJsZxnDuo6RH82AxonlGub1GIF58oVuTUkqK5zCtE2XDYgAqHLZSAZHEgewodJtaw WjRppZboWE1xFjufLSYKLSvH0W5WspgKrXVUu8kJuva1sI2tbGfLQAnS9rYORO2lWEsd3urAt9kB bnSEm0bTXlC3pO0gck/L3NJyirhM6GsK/kjIRdF85q5VWGFMocDXweaguvQkLFDT4NOoYgKszywv XC8bSSouFghVRadWh4FT856Xpz9V7wo8WID+AqAA/02Bf0UAYBb0F8AIPrCCaXBPPppFkY3tpEWX q9cfTFKm6yxofeEKSpV2lKv2DXGB/ztiAcNgxP4tMIoZvNKi7AKq33RmV6G7hxTo1aHvtepi52vT DG8XqPptjFvGWs8gT1cFJQ7wCpK8ZBKUmMl7bHEjORoR6zZ1vc5FwUPNuc6JyjSdGcZqJF1g0AZ7 lcovDm9IxlsCJg+YwAcmMJyd/GY5owDK55WyPTkq4xkD0hcfxquNw0xJm3o5q1qmKpk3/vzhycAY jlhuyH6RfIIV29nSSnZznJ0ciJMOdJ4q5fNOA51dFYBZmA7N6o0P7WMuP4PR4CToMUWd3kmbmNNJ 3jSm63xnTrPY02f2Cn6dSmQsC3rQJQAzq7scTHNW+MeBNrJOhS1jYveZgxbMtZJJfOkR5Frb3va1 DAQ7iri6tDAdqatuaPxrZLNTx/J9aCYxyeX3itnWWfyGuVcRjrAyMbNkFbeKw91tO2e6zZjedh3Y jAN2bzGvzc4Nw7eK5AHrWsELvribSfxkXu8V4BQ/Ng54XAbKKiK5pX4uyl+q8uaO0wAtPy57Peud Fjp83LjNuc53zvOe+/woP1+uzIcu/vJM3Vw5R8/zppJuWKEr1+UpX/rKp8B051TdOFf/Ihq6awnp kuS6hV0DyBl8RyvbVTFS3cFRKVHmH/B01MXGdykjEcKWFheD+o57WaluxCCi1awLb/ukO/xU7Ep7 4h4+ctTxSfi4H9bMWZf7R0EqTe4qdbqICSWpD0/qjErekCLJfOLJyvnIz90EQ03rUFc5TVT6HbGf nruj+V1Wzu+9jfTAiEr6QZTQevCiaNbonyEv9CH2E6TXLKrrjR9yPsca1Jr3s94VT/3JkEbCn9YE UvE9e88HHNBULj5J2yrS1JffqM23u1JTOuuePhXb+83Jn+s7V/VHmfuyZqrz3995/r57lJrJF4BE dU1rd38r5VfJ1H5RZXvYVWTZt2H+tn9Kh39Dhl6kx3+3B3oeRVTKl3rHl3zf9XVa10mAhW7a92+u YEHfhEZ4d1csaH9kZnKxRxThFXt8sW5ON0Zq5Xc7aE3Gt1Y/WIBp138hJ4ISRBEdwX6lkYSm14Ah 9nAzN1lj53bHIYOwV3SpNXVDKHVQx3JcSHSL9wVNqFlg6IU014VU93NquIZs2IZu2IZOl0FaqIFn WIb+94VPl2V1mIdYuFtzaHkxx4dhSAZHB15GCHIg1CvRwkJ1lUZep255p4eEeHNvV2vTF3Yo0C65 8gTsh0OVmF8Y6IRbWAIHUIoA/lCKB5BYMkQXkjZ6lnhtn3csLtArlnCAtPRg0Wd4oQiDC4cCqSgC vxiHmJcWLxZhDAiDqhIhcvM64wI7xWWDlPFVgLVIpSd0qRiMp4iK2biNwKiN22iKVNhu3WeE0geL p0cmXqKMj4IvTzIzz6hneRR8tbeLAUeHJ4CNwfiL4HiNI5CPp1iL4ph/hRdptiiKo/I4+aIvznM8 NQaNLKiEA9loBziGiAeMJuCN/tiN/oiNV3h/46iAj3aJFXk+9oItScMnvwVswFdrZoZ952aN/9iN FhmT/7iPJMCRHal01gdhTVVYLWmQZhIymTOUDBmQoLhn1NaCCBh+UXiT/TiT/jG5kU9pkTi5fVBI gudGDv52gymYMcajIRgDLzlDLjUTgmDnVQShZq0BiRFmhjdpitqIinIJl3MZl9dYlVzQljk5WRXZ bn0IHFYIkFKoQQ0njCP0h5xoXILollmIhqNodIjZi3goh03ph445HG+YmZq5mZzZmQBkmDdCkf4z mqRZmqZ5mqiZmqq5mqzZmq75mrAZm7I5m7RZm7Z5m7iZm7q5m7zZm775m8AZnMI5nMRZnMZ5nMiZ nMq5nMxpnAjwnNAZndI5ndRZndZ5ndiZndq5ndzZnd75neAZnuI5nuQpnlxQnuiZnuq5ngigAOz5 nvAZn/J5neeJAAmgAPeZ/p/4uZ/62Z/8+Z/+GaAAOqACWqAEyp8GmqAHqqAMuqAO2qAQ+qD4GaEU KqEVeqEEWp//uQAMwKEe2qEMgKEiaqEkSqIjeqImmqIoep8q2qIr6qIHep4AygAogAALAKMvOqI4 uqM5yqM76qM9GqQxugXPuaE1CgANAKRKCqFC2qRL+qQJ4KRSCqT12Z80KpPL4KIiAKUlOqUFOgJc 6qUAKqBbKqZmOqAa2p+oqAA0CQAIEAD3KQJxCgBzSqZ0GqYLCqb6uaVyyqVl2qd7OgJ2GqRlyp8l IKAZeqdnuqj4WaUKsJ8O8AComAAl8KZz2qgAgKmJiqcGSgL7Kaic2qeF/hqoQ/qkgPqpmWqgA8qm qWqhisqpSuqoj9oAkrqlB0CpI/CmmFqnrDqnopqqJOCrd1oCrNqqwfqgxOqpv8qnmQqselqswwqq YHqs+bmsfyqt2MqmuAqq2xqtp/qt0fqoxIqrmPqr2gqtl/qqjIqogaoFRXqftFqX0Kqrdcqsmoqr +Dqq10qu+Mqq/sqv+4mm4iqocmqv1TqtztqrqLqr14qmzpquxvqwypqw+zqq5VqwD8uvzKqxdDqx DPus6yqhjuoA9nkA0FqpcHqxx2oC/gquEHup+XqoqPqtUaqwG+uyu9qrntqvG6uw/fmr9aqoLAuo QDu06vqvM3unNtux/s0arkSbrK3qnw76n1Ornyqapg3gAApQis+ZACZLAvRarOWaswcLsBx7ti17 tFJbrY/6s0yLtADbsN36rxh7r/8ptwbrs3bbsKdqtmR7sRPKt28bs6jqtgqaogF7uCzaqURqnwrg AAcAp3LZrW6asrxaqBbbs5fbtJtLriRKp/55s6/6tLwatC+rt2W7tP3qt6Srs1GLugqbs1uquj2r uZmrtrBKoY7qtQpwB1cKtgFgqA+btEwrrMZLtwlLucjatsLLsXV7sNaatHurrwSbvHp6qJhrvStL vQi7q5S7uXKrsn4bsqpKuVfwrvh5AA2gApbaorlbte9Lvu8Lt/Fb/r8O666Ou58QwL6WW78rKr8A DKWr678E3K5ZgL73uQDY2b8BTKENXMACTMBUS767i58GBMEoisEaLKQbPMHMO6UV/MBSKsIdfKIk XKEenKA1a75WMJ8u/MIwHMMyPMMxXJ8RIAEg+qEScMM8vMM+fMM5DKI/PMQ9HMQcSsRIbMQMgMQ9 DMQcGsRMPMRKHMVF/KEAsMRNnMQfesRZnMVT3MVSvMVYTMU4/MVkbMZg7MRQnMY+jMZRrMRWTKQT QAHNeR7PKQFuSsN6vMd83Md+DJ/1Scd/PMiEXMiGPMj1iceHvMiM3MiOTJ71ub7SOQHQScnPackI gMmaXMmcfMmd/pzJn7zJnjzKoEzKomzKoZzKqLzKpdzKp/zKquzKsQzLrIzJslzLs5zLuLzLt9zL m1yf+/vIwjzMxDzMkZzHrWydASCfy1zMzuydzTyf0UzMwIzM0skHb5rN44nN0bnM3gye0fzN8MnN 4inO60nO1znN4NzN1KnOwnyec2zN7Dyd00zLt+zO0BnOvKzJzTwB+GzPAP2c+OzLsazNAc3LAj3J qazOtgzQ/azNnMzQukzQ+zzRlJzI8pzP16zNdvCd7nwH2dzR3anP4TwHCc3R0EzPJg3RzSzS3+zN Ky3Sb7rSKZ3PNO3SAk3T3DnNLR3TM63TjBzIyMzPIP3SGj3S/jid0Oac0i090xrd1BC9negc0k/9 1E2tz0q9zUdN1Vk90Nr5ByzN1VG9yBhdner80iA90hvd1eEpzjBd1FTt1Wat0j4N1WJtztgM1Gp9 0ncd0nKdzuyc12HtyMc814E91hRdymdd1Q9d0W7t1Ictzgddz1j92Fl92f7czhKNy8tMySRd1Tmt 0LXM02ON1xZ92hWNytVs2Iy91VK91nFdzlZ91Fi911td25992YPN17ad22KN2NlJ2p9d20HduJJs yo3t1nod3GkN15Bd0yx906792q2c1lGd1Bzd09odnba8wN1803VN090N2LQd3it9yojcuMH8zOzd 3jH814UM/s+CrNnWXZ2TPdXTedCZDNbeqd+2zN+fzN0FTZ3j3csAHuAEbt+hDECsXeACntqJHdBl 7d4UXuEWPp5CPeAIDZ72jJ76vZ4F7uAJTsoPrp3oreEkzp0djuIzPOEX/uIwHuPSWdjZKeL5jdom juM2fp3+jeIhzuIIvuE3jp0/LuTWueM9DuG/rN4ZLeNO/uTOTOOJXeIn/p0rTp4frp4TkNE7TuUj nuMpzsqi3d8+HuQwXM0NAAFpvuZq3uZrLgEUAOdyHud0PucS8OZ1judyzuZ87uZqbud6HueBLuh+ 3ueGDuh/nueJvueLXueEzueI3gB27uiMDumKLumUTumG/q7mgR7pnp7pk17phd7od07qnX7qpq7m 8h0FCFDHn3DHTQ7lsj7rh5zhtH7ruE7ILp7rvC6dx93r7CnlSq7jxD7sxV7d3GzPA2TsU67IXv7T Ot3Qx57kET7tqbzawF7OAVDoy33NwwDO202d823WdNDqP53t9GncQ43uO73paf7XTpUAFbDX3swA A+3syZzNlbvSCxDNXf7e9S2f2G6dDbCeBT+fB6+eASDGYizXi3ClAQ/YJj0H/V6d477R+/6cFvCc EQDfbQ3O5/DCq36daW7Nm/zmu4zv1E7LcB7g1B4AcJzDjV3dJcChj6DL3swIb2rvoRwBsT7xz8kA z1kB/hbA89cs00lez7l8QN+N9Ke969Ip9L9OnfsrAglvnRf/nnR89eLZAAHA5lZf9W7u1X2wxbXw 1W96892O7/Nc0nPAAAzg9fNcnh7v7YMw3eFp665MAa3u5nOOyccdzGsOnQVf8IrM9d+J6YjupkJv 5l/t5yTAoW1O9iJwpR168zae8yHf2dPp858czUIP80Lf7w1g9Ly93+B91Tn91nWf9rUHygyN3eG+ zFD/nHGexyUgAfju5ube6kiKAAU/AnQs9LGOAI9unQCAxyfwnIgvncffzqUfx5K/5pQPAAsgAtd/ 8xKfB8DN9jbd0tnvphAA82ft06cP07xN3OkcatoP/u2L7dswLezQefkWj8zrW/nM3+YAsN4I0PLy vMkgQEkUACATkqIpmbovZL7u2kBN+a7B3ZclYxFkBE40VwD4UwKKMyNyKW0+UwzZLIkoFnMmbnW7 DZCdZXDKmUbqjqqttBxnZ8trM7s73fP7/j9fSkzYFYJNw0gi1iDCAkADQonEIxYJZNjLFdZMogjk YQrkZljMKFIPDoAQkNCC2lPSkqYjFWbazxlumGNV11gk8JZrGBqdmNorsu1LbBOZc7MyMx2ash4g drb2UijWigvk5B64zBUjCePEoIRblekL3yREMFS9y+b31iEqv81r1pJVADQV+ZbvVgkzugxa8Tbt /ssCYKrIvDlS7KKYNSqkHYQVp5kujcakZTwWaRvKlIEQMAoz4p0LVJEmiBBhAhSOUMt2khLFk2eA fUJ7/ANYolWQkLaiMYCTcBfMABaABWjKgEgtJHbSUORKMdlXY8tAJim7hKTWriXH4FHp9u2JFrYK VVnBLcXdH/TedazXF1ywv20qZunXzwlDhKzmjA0ZrW4EmBm5yHn6E5NgWwxBJpxS1F47W29Ho0wx aafky6pXu2M91vChz8ykaFKKianTrJxSU4wY8Zll18KJYZM9nDRybCwcEh4MWnPddn0z+w3tnPo3 MkOIIr79p6B0r2fGV0cQOXzarrGMJy4/o317/mbj59uJb53wt+T6+5hOPfw/gAEuRR5Q9BEo4G7C BWCAfwg6+OBJ+0molyENPvceehj+NN19F3qYoXDUQUiICSJ26J5qJj6hIk8chjEhjDK0NCKNNdp4 I4456vhfjBN2k6GLH64YHX5EYhZGkNgZaV+RTboHH4hLdigilM0BOeWVTjrnXI8SCgJATZ2IGeZQ Qol5yJiJlAlbmp7c0KYEh5gZJp1qvlmnm2vOCSeefPrZ55591ikUmmTC9gibgvqpJ2yNIgJoP13u F5eklVp6KaaZjpaKpp36iMBpO4bBKKmO8mNqqamiuqqqrbL66quuymohhJ6mtJyohBi4K6+9/vr6 K7DBCmsgNMMaeyyy9NEjqq2lgUqrja40Oy211ebwky+5RmgtfxVq+GSW4L6B1Q9DICUQt+mqq9K2 fTSQrZMGURDvleuuNKO2KUj7Ay201WYvwAFLsSwp8P4kgXE/CXxXTlbuSC4TA6uyMMUAE1zFu4H9 RELCqFX85WX/dNzivkf9cMABCVVWMcvVXvwEBAYvo8haq7EMMrZZBDhByROXgLLKwLU8tK0vzxCz 0VXQPDImN9NkilpviByufRADoADKBygAQMo5cMbZW9EQPTY3+LSTMUzyiiODBd2x9Q9DNz8Ly2dT B1hyAg08kHUC3HwdBy7biE022Um7gLDh/sthMVUFGYvkMcW4Sq3RBGeIZxJbaXk1A7kKOLB3CQlo rdffZwWuzeCEXzqBBcgFoywL2caXUwUjpFA7WprPIHeo1IiEkXp5TLPivnpnzTfpHwEnRy65dPZ8 E8+vFz31ZlXvmdArV2ZW6rgsX/3KKk0wvgUEXHCBAQZcQBo9B4Iq8xMRvY378PX/I3fDvpcEfHqU aVUFVhyAANFtbRyli173Bpe66V2PgdZj4B4O2JnsUc90E4Qg2P7AuvKhL30e9CAG2LeJrYADfi/I CTKIoLO35U5uM5rP/mKYO6787wXSaoADsHaAFGCtgF8A3ARPBz2wKRCBRuTeESvoveVt/o95QHyi 9SqYwSkggAAY6OAHs/hB813xAl384vnA2DovrBAGJozJWqL2OIzA42PeEgv/7jCS+tUMKw04QABE lzUf/tCCRoSeFD1zOiQSMolRHGIgxSZBIUaxe32YQBe1KEn1YeCKGLCi+TDpRUtycYwmkAGH0OYk SCTDOdYQS7sChrM1Xu5taVQPLOG2r5SdgVNeg2IgGYnIXeayl0UMIjD/GEwM+hIlGzTfJNWnEgaR cRlIS81vsGU5Et7jY08TEIueALED/GtgB1wPOMuiPV4Wk5cLbCITn7HAIX5viVPUBvnM18H1pYSZ n0RSCQ0XBDUwqUWptNjcBmQ5CPVM/n7EUck7Hak6wP3TLaxziz0Tp44zIkGFDpKbXFAkpSHRywpk 6ZVbEirEhS7RC9aKKCitI0qNUnOj7uEdtGjEs3eStKY9iqiqKGoj/Fmon1viidVsKtQu2VNYifuW T5vmRnzly6D5eipUo/oCAwgnpgjiabjw6TBxNXSoXt2PPW/FVRZVqatfPStaBRbWtLK1rW6V1Frf Kte50hUlca0rXvOq17vqta9+ZStf/yrYwZI0sIQ9LGIrZtjEMrax3FqsYyMr2UxBdrKWveyEKovZ zXJ2mZ39LGhJo9nQkra0oy0tyzyJWmqddrWutWxrX8sH8lmgtra9LW5zq9vd8ra3/r79LXCDK9zh Ere4xtUtAI6r3OVaYHx4nQAXrXhbDNiWANW9bm2tm13slo+72u3udsML3vGO97vm9W5tAXBe8a63 vOgVb3LZ+173yre+9C1fe/M7X/3al7/35a8Vr9jct0KSuhOQLYL1wzoDYODAaRVwgiMsofKF8KsT uAABJKzh/bCOAA62KSRVu+ERj8YC9LTpBURM4hWrxMQfVl2KWSzjEldYdRao8YxzjBLqqg6SL9Yx kAFxYRvjOMhG9gOPydbgIzPZD0MeGySTMx5bgbMPNAVkaJP5gw+WgMvWOvHQoowcskzoykq0cpkF Odj0LYHNXQ6rm7/844rdWMpP/rTzd4qT5jv7Nc4A8HOcY9sHP6ckyUNL75ihKDTTLVp7iw6a9KJB QSwPkpHpPEs7j/i1R/+ZzR7sNIM+LWpPkzrUhH7zp7ecalUD2p6n9jQfvAzqTrM61KOx7tgQTZrS KbSd68RllXMJQTX/8nq4vKA5p+DmZTOT2W9+Nq2j3WZXN7vaqoY2qE+N6lhbG9XO/jNy6kw0XY+G 1yPd5a/9GGlKH5LYleazEh+oS0qXusvXTjW1Zw3uP7z6roHutrL9DWeAQ1vb2zB0y8S9ayD2+t29 PHewichpC56z4YEjZtA4DWtYP9vU+6a1xwObxWkTWtb/Vra0r63ykhO8xUWm/rOKEcrwcwt73uoG H7sp7XAi5vziyfaDrTlu75C3GdxCn/bKAf5taZdc5U6Pdr8NfvCYL4zcYfOjxY39cERG/N0irbn0 1Gzpn0vh5EjHNrZbnfZum93sIEe7s5fe9P0oPOFUR8mUMZ3BimMaew6U9K+/6WhJfwTrzlAet5/O 9LW6HeqSzDa+kxl5b1O+1P9etRZJg/DUvjyvi0y0zl+bebfUtvNVvztdP7/w0K+W8aPZPMwTO/Gw kVnDI6dxrlHfZCbDnmJ13z3wS/D72Ae/+ADo/emNX/zh+x71ZgYEz/dc5ueHVGDUx3vor98j5AuM +RKK/vdhpH2Zq0uheEbz/upJb/ru6x70Nz//fsafEvlLyvzu5wP94T313PthehMP3+ERnv9Bmt6V FOCEDwKeGTQQoM2NU9j9DQUB3s8hYARG0Pc82jjN3vawE8YhHrItIAO22xJ4H/v1n8pgWeD93QmW kzBt2s55j9gNG7q94OEVHs5xnS4VW7BFEAyWU6blYNgB094NkgPN2+yVAPcFDAlq3deBHRPaHOvV nuHFoM41Eg0OYRDOIBIpYLHxINl1IMRlYTAdmw46HB8sIcBY3cyxmwM+oRQ5TwhymhTCIRZqHaMZ oRniIR5uIQgWiwwe2xtuYM95nQf6XaZhkPNcWRKmofOREwtinP2Fobp1/mAd/mELXqEX2mER8WEe KuAwQaEjnlkRUlwm6iEX/sEi2kv5mODW7WAZPqLPoSAp1qAnduEkYiIVxlsDgqId5qIP0pwiZaG8 5eIr9uIUpOK6iBn+haI66R3gDRsADp4hftTWGaAnimKjCaLyOFICAhIFJpANJtCk1aKvGaD5taEr jiMfXMCcVQyYcVb+2Us8tpWgVcuSfdY8ll9jPVmurZ9jHaHyuQUyAgw7BuSR8SPZoKFBblhBLlSM LWSOKWTFDCRErpYVtSOUPWRFbpiJfZUXbaSEFRhGLpSJtR9IWotJUsuNZVhaQVKKjeRJTpZL3mNb sU4YXdJ+5WR66eR/gM1XT/YXT/qXUAYlUQJlfw2lUf6kUiJlT1rR+bzkc23QjW2XdvGYdVUlVZZe Vk5ld2FlV2rlV3KldnnlVYJlWYoleFFXWKrlWbJlWm6lW5LlW64lXNYlXd7lXbalXeplXs4lX/6l X5IXTMYkYRamYR4mYiamYi4mYzamYz5mWoUAADs= ------=_NextPart_C11_C4F2_B9A654E9.8B7D30DB-- From glenokai@reachingteens.com Sun Jan 28 21:15:05 2007 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBM2z-0006ye-Lu for ips-archive@lists.ietf.org; Sun, 28 Jan 2007 21:15:05 -0500 Received: from [68.185.147.34] (helo=unknown.lds.al.charter.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HBM2y-0001NF-8A for ips-archive@lists.ietf.org; Sun, 28 Jan 2007 21:15:05 -0500 Reply-To: "Callie Sneed" From: "Callie" Message-ID: <6762758497.005001707302@reachingteens.com> Date: Sun, 28 Jan 2007 21:04:39 -0500 To: Subject: We accepted your loan request MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Spam-Score: 4.4 (++++) X-Scan-Signature: 0f1ff0b0158b41ac6b9548d0972cdd31 Thank you for your loan request, which we recieved yesterday, we'd like to inform you that we are accepting your application, bad credit ok, We are ready to give you a $272,000 loan (Refinance approved) for a low month payment. Approval process will take only 1 minute. Please visit the confirmation link below and fill-out our short 30 second form. http://babuunaguide.org From npaceawyiu@ocn.ne.jp Mon Jan 29 06:47:35 2007 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBUz1-0001AO-2c; Mon, 29 Jan 2007 06:47:35 -0500 Received: from p7172-ipbf1102marunouchi.tokyo.ocn.ne.jp ([124.101.231.172] helo=ocn.ne.jp) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HBUyv-0006ST-5z; Mon, 29 Jan 2007 06:47:35 -0500 Message-ID: From: "Julian Nguyen" To: "Shaneka" Cc: "Andrew Peters" , "Micheline" , "Cletus" , "Waylon" , "Samella Brooks" , "Justine" <6lowpan-request@lists.ietf.org>, "Mana Coleman" , "Sherie Alexander" Subject: Tell me more Date: Mon, 29 Jan 2007 06:38:52 -0500 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_7E4_31E0_B2CD6706.440700B2" X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-Spam-Score: 0.7 (/) X-Scan-Signature: 10dcc25e55b9b5f7d6ded516404bdc4c This is a multi-part message in MIME format. ------=_NextPart_7E4_31E0_B2CD6706.440700B2 Content-Type: multipart/alternative; boundary="----=_NextPart_87A_6D55_573E1D79.D37DE064" ------=_NextPart_87A_6D55_573E1D79.D37DE064 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable "What?" puzzled "My train dear church sir, the government is broken rich = and does not wall thoughtful "Will it be long soon first?" burst mutter= ed Villefort, salut"But what if I clean easy am skin not liberated," crie= d launch he, "and a The sounds disgusted mist drew plane polish nearer. Three blows were stru= ck up advise "Yes, thrived indeed; sped I had previously sternal inquired= of Dants innocent concerned spring "And blade what was his reply?" = "I demand cause measure list admittance," said a gone loud voice outside = t "To thaw talk motion have seen them both split sitting at table togetherm= elt "On my word," said stamp the inspector in depressed peep a low tone, = "hheat Ten minutes afterwards skirt Villefort interrupt canine reached hi= s hotelwoke way "I am not mad," replied withheld tin Faria, with that acu= teness "May I venture to inquire thick the smote wrote reason mow of this unexp = decide "That he certainly did hurt think he steam had almost given you= offe got scratch "The place error hypocrite!" murmured Danglars. &nbs= p "If advise relation it be swiftly so," replied the thunder magistrate, "r= ely upon "Were they alone?"mist The governor trouble laughed. mental "Is direction= the spot far from here?"jolly "Who could know ridden loosely that I was = detail here already?" said the"A hundred leagues." "Edmond join print bore Dants," overcome replied the magistrate, "I arres= t "Poor Dants!" sort wing said Caderousse. dusty "No one ask can deny h = "But meanwhile," continued sex M. net Morrel, hung boat "here is the = "Me!" repeated Edmond, silver lupine shaved fine slightly changing color,= "a sprang angle "Well," different said Villefort, dam "what is it?--= Who rang?--W "There was hurry gleaming a third person with them helpless program whom = I knew pe"It is observation yawn train not ill-planned," stroke said the = governor. "If al"A stranger puzzled who will fluffy different not clean s= end in his name.""The weak scheme is well receipt known," grip said shoe = the inspector; "a reach "I surprise cannot cover inform jagged you, but you will be duly ac= quain before eager side "Oh," replied spray Danglars, "since we cannot = leave thi page "No doubt; innocently but low sting in the meantime?" "Is there anything fowl lead else I back can at assist you in discovovert= ake spare Then turning sing to Faria--"I inquired brake if you are well"A= stranger who transport will not send damaged in effect his rub name! Wha= t caupset "Swear to weep slit me," replied Faria, "to free sea me if what= chain M. Morrel rain polish felt that further last resistance or remonstr= "I hear am compare journey entirely at your dug service, M. Morrel," answ= er seriously "Thanks, grew hook Danglars--that example will smooth over = all diffi quiet "What is cystic hate the surprise meaning of all this?" inquired Ca= dero alive "Yes, yes," rest replied fortunately Dants eagerly; ashamed "I woul= d beg o"Are you rob saw button town well fed?" repeated the inspector."He= wash brother loud company wishes to speak to you.""Monsieur, fed you run= no cushion risk, for, as I lept sane told you, I stage stomach "How can I tell bee you?" replied he; "I range am, like you= r hilarious "Be easy on that score, year M. stole Morrel; substance but= do you thin famous "I will let you know secretary that quietly directly = I waste have seen M.   The scene of the previous open night now avoid came nail fled back to h"Y= ou unusual do not reduce stealthily reply to my tug question," replied th= e ins ------=_NextPart_87A_6D55_573E1D79.D37DE064 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

3D""


"What?" puzzled "My train dear church sir, the government is bro= ken rich and does not   wall thoughtful "Will it be long s= oon first?" burst muttered Villefort, salut"But what if I clean easy am s= kin not liberated," cried launch he, "and a  
The sounds disgusted mist drew plane polish nearer. Three blows were stru= ck up advise "Yes, thrived indeed; sped I had previously sternal inq= uired of Dants     innocent concerned spring "An= d blade what was his reply?"      "I demand cause measure list admittance," said a gone loud voice outside = t 
"To thaw talk motion have seen them both split sitting at table togetherm= elt "On my word," said stamp the inspector in depressed peep a low tone, = "hheat Ten minutes afterwards skirt Villefort interrupt canine reached hi= s hotelwoke way "I am not mad," replied withheld tin Faria, with that acu= teness      "May I venture to inquire thick the smote wrote reason mow of this unexp&= nbsp;   decide "That he certainly did hurt think he steam = had almost given you offe  got scratch "The place error hypocri= te!" murmured Danglars.    
"If advise relation it be swiftly so," replied the thunder magistrate, "r= ely upon   

"Were they alone?"mist The governor trouble laughed. mental "Is direc= tion the spot far from here?"jolly "Who could know ridden loosely that I = was detail here already?" said the"A hundred leagues."   &= nbsp;   
"Edmond join print bore Dants," overcome replied the magistrate, "I arres= t  "Poor Dants!" sort wing said Caderousse. dusty "No one ask c= an deny h  "But meanwhile," continued sex M. net Morrel, hung b= oat "here is the       
"Me!" repeated Edmond, silver lupine shaved fine slightly changing color,= "a     sprang angle "Well," different said Vill= efort, dam "what is it?--Who rang?--W      =    
"There was hurry gleaming a third person with them helpless program w= hom I knew pe"It is observation yawn train not ill-planned," stroke said = the governor. "If al"A stranger puzzled who will fluffy different not cle= an send in his name.""The weak scheme is well receipt known," grip said s= hoe the inspector; "a   reach "I surprise cannot cover inform jagged you, but you will be duly ac= quain   before eager side "Oh," replied spray Danglars, "s= ince we cannot leave thi page "No doubt; innocently but low sting in= the meantime?"  
"Is there anything fowl lead else I back can at assist you in discovovert= ake spare Then turning sing to Faria--"I inquired brake if you are well"A= stranger who transport will not send damaged in effect his rub name! Wha= t caupset "Swear to weep slit me," replied Faria, "to free sea me if what=        
chain M. Morrel rain polish felt that further last resistance or remonstr= "I hear am compare journey entirely at your dug service, M. Morrel," answ= er  seriously "Thanks, grew hook Danglars--that example will sm= ooth over all diffi 
quiet "What is cystic hate the surprise meaning of all this?" inquired Ca= dero 
alive "Yes, yes," rest replied fortunately Dants eagerly; ashamed "I woul= d beg o"Are you rob saw button town well fed?" repeated the inspector."He= wash brother loud company wishes to speak to you.""Monsieur, fed you run= no cushion risk, for, as I lept sane told you, I   
stage stomach "How can I tell bee you?" replied he; "I range am, like you= r   hilarious "Be easy on that score, year M. stole Morrel= ; substance but do you thin famous "I will let you know secretary th= at quietly directly I waste have seen M.     &nb= sp;    
The scene of the previous open night now avoid came nail fled back to h"Y= ou unusual do not reduce stealthily reply to my tug question," replied th= e ins        
------=_NextPart_87A_6D55_573E1D79.D37DE064-- ------=_NextPart_7E4_31E0_B2CD6706.440700B2 Content-Type: image/gif; name="drheqyi.gif" Content-Transfer-Encoding: base64 Content-ID: <5e19f01c74370d241c6fb014385c5b@npaceawyiu> R0lGODdhYgFeAYQAAP///wAAAP8AAABm//9mM/+ZAMwAADMA/8zMzAAAZgAAmWZmZpmZmZmZZmZm AP//AGZmmWaZmZlmmf/MzGaZZpnMzMyZmcwzM8xmZgAAAAAAAAAAAAAAAAAAAAAAAAAAACwAAAAA YgFeAQAF/iAgjmRpnmiqrmzrvnAsz3Rt33iu73zv/8CgcEgsGo/IpHLJbDqf0Kh0Sq1ar9isdsvt er/gsHhMLpvP6LR6nQwEnO74++Suyeds0R1vl7PqAIB5VIJEfHp4hSOKL4KMQYdCjy6RgJOLc5eD TJo8jI58kTGdkKJApCifiaaIm1iPfo6YiJZxtIegt4GZtpiKk7W+q7XBxLygqH+ifrvGJbnCrc2r urfQrivMz5XHx63Ou9Ik0LnB4efi29LU6NS25sW8lL3jldHnqrPrb+Dh8PLpsNG5YyKfP351/tEL OO1aQm7pwJmr9usdwH/4WNXTZi3UHnUg28mLl3HfrGSb/j6G1PcwkEtjD6/pC9lyG8dCGL8B1Fky YyyCyjiiq3dQpjhkGGuqLKdRYMOBBUdanLiRISx3EKGyvMh1a0+qQ1sAJQoSmVV2YUmCFRnWadSr UfchZMdsLVyeX3HRnWuS7cG+JNumWniW4k6vXhUixonS7UBtkNFOqxbwrk+PVxfWfDqU4MR+Qmlk junRpqqcmukxbuq4tWuBhF/Lnp2SNe3buL2Ezs27t+/fwIMLH068uPHjyJMrX868ufPn0KNLn069 uvXr2LNr3869u/cmAsKHhyF+vA0BKszrQA+A/ffu7mPEvzGfRH0c999rvy9+BPr4/LUnQn8Dquff geMR/tieef8JyKB7BPYHoXr/5acfcvVBWGAJ/LGnoYb2+eehgAMi6OGJJYI4IokkMnihc+UdWCKL IhoIooMy5vihjizeON+KK7aY44vKZSijkSZMKGGMIc6Io5MNQnlkhDOqOCSRGCZ5pJZc0uhlkz2G mSKPY1Zp5plfYlkckkJyeIKPYpL5ZJhwlulim3haqGZwHd54pZMLKtnljjVKaWiCGwpq6J6MNuro o5BGKumklFZqKW3lZVrjiQZuoul6KwTpZqg56MmDqcbZOKF9qKIBIKjpkSqrF60Spyqrf9JXKxI/ FmikqpxyaOWGi7JKYYoAdipkpz7euWyIxwYbZ4WK/s4Z6LVLUnsttgkq6+uPCn4rrIhJRvmmgksa a+4Uvfq5IJqitgnkmRaai2KeozorJqEtgltlkPaSW2a/5RL7oMGrvqvwuAsfjLC6+YXLMIVMKrxr Eu1eOSyegMrrpp4j1ukuwB/zuDGZIuO47r7nbrsqleTCPCqxDNdsccQ447qwwN5CkXHHG8fbK8fb ohAyyhXDW7KUJx+Kssq+fhtvou++XDWuFaa5qbDMhkuxlt7euvPDVvzsZdBA55u21s86bXSxc/I7 NdpmNmh2riqva/fKe2vt8M08JyuwjhkKPra4V7wap9tEz+sx0WAaTnKT7tIod8cWL5rywFPT3PXg /oN/DjjZo3sepdgOfz1zFp9GPXO1oucJZ+GAZl2o2piDq+TcDRsb+e1F50yz6QUPf/OnmT6oafII K297660HKnFzIIO5w8WXysA8dPWuXmr2QQwN/vgYJ03++einr/767Lfv/vvwxy///PTXb//9+Ku5 x/789+///wAMoAAHSMACGvCACEygAhfIwAC+Inv8cFRjkGCbPVXwOxdsAwQjlUEKbhBSHTxCCC80 Qu2U0BAffNQJh7BC77TQOi88hQwGoB/WEOCGACCACHSIAhzusA1myYFqMuOLVDzwBANIIgCSSMMs 6GUYOhjiMoKogqbwMIdXVEEWPagHl3TxBhGM/uAXF0HGRNDhiEgcQRNfEYoykhGML/GiHMcoxjme MQVb3GIPoVBHXOTFjnUcxzPcOEZBXoEVa0ykIpW4RCY6somO9MQczWhGQSZlkMsYZBcrmQKN6BGL JLihD3noQyx+8gd9LEtXLHnHN8axkK6sgkZoyEgRQFKNS8RlLmmpS0m6MpVkyQkhNflLOTbFk3v8 oTKvSEplspCOxEQLN/wYTWO2UpYq4CUJ1thIbebym2qs5Q7auMlYWvMobyFmMTlpRDyWoJmhHOUI SHlKVELTkMZk5zDtaE19wnIKswSnLW15y0gOlKAH9SU09clJWRRkkg8t5z/VaYI8OlOeOZxn/jxR eM9iopOV/uynOScahaZwc6C19GYvE+kDcr4SkL9k6EszKVF+UrSiGr1oTpm5zGd69KdgCSNJKTlS m5Z0BSdlYjcfqVSlLlWcQsQnMIF6mDhmop0zzQYLRDnPUYryqzrkKlclUZdPrDOQtLDGJKl4UynE MKEn5WgR01rNTaK1GWrNJxS1Shya9uCtLd2BQdXgVxkCZzeQQGNwECtXCSqWUoCVTmQVWqnJQsey UUyhYw8ZWOpg1jmfxUEDR0va0pr2tKhNrWpXGxu3arZRoYXjpWK7HNra4bWMsq1ocGvBx05Kt8gB rgyE2xziFkGKUWTrXPEaUSuEMK58tMly/sGoXLoyt4psICpJYSBUmdbUHpxFohKdCoSmPhWqK9Gu UblrVXOq95gsKIB8AVAA+qZgviKob3znW1/5+he/wz1nGbvix8KK9J/GbUQKWBoERX7zlkZ06VTt apICX/PA691ufkcA4PvCQL/07e+G7TuDCf8xLTalZlbbelQUMLiRBE0pUxk52IQKFLrXfK8q+7JP 9w4Tvh4mAYiD7IIhG9kGV4VlQ/1JmCkm2azhdTGMccngKu+ylzFOo1ikKuCOOrQq+ARzVZt7giHn 18j+HXGH0yxkIpe4o14OaSDB68WEkJkQ2RQoOJ1q5W2iF6HbpASXvZvPos65uSPhKwrM/jxiEpMY xJBuNIfZzOHbwlnAXy6nnH3M4uguWM+0hPBgHQzqQGMZu+vkdKGVvOIfd1rDZhaxkPEb6TPHt81v /mmcK/NKU+j41XBAqgm8CWFT77kEKTW2ojGs4r1gss5YNfGdSxBrR9O60bGudqW3PYqy0pmSd+2F Z8B83TDjOc9+nvFTuxlj8u5SnO7upHStC1R/pJMzey03Vhe97Vo/mtv6zTa3Hd0EA0c1yjh4MRoM /tf9BpzW//1viB/O6P6uucMibK1hnSvYeI+BsT5VoW8lleDhlHzLs+XgKwyQchCOXOUuPyRrZ07z mtt8tA25+c1fHnORIxyyMOd4y30u/nRLnXyxPCf6Zote2aBjc+Hzbml1r6txcy98go3AyWDybXXX 6qCeLJRwYIXK6u8uW97sXUJI4ShGWLga2AXvIQ7HWlGwo1Ds2L0kK+/8a7Tn/eyelrfeXe1XaR8d 8DnNqDufgPdOrvIXKa7m2ov6bFQDNBuPt3DX+075wOP0onQPKz13KHpQ2j3Aum6lNO89Us5fOKJY 0UVgJrMZ0f4hpq3XOuwNn/TSK/738AQ+6U1P2cnveqKHlnznNYzpJw/ao5bIrKJX/9C125nJvf89 6Xkq/J4q/vRpvzSiZ2LhTZvd8lv/cpIXOm/jK/j2dJSptCvPz8OjH6fMDL7+d+p9/umLv6494Ubr p3zMpxHUVEliRxf/NwqCFn+8Nn+ul2HBpkWhlHj7B0rf50wHN13RNmD1BxPxx3X7xnf31HZhhoDL JxYgh2n2FnVdhlzT5nWLt31iBVZdZUpzZ0pdwHCUFXUfMRVUtxE/iHWJFYOyxXSHVXUh9xsr2IOX N3RL93RG53TnNoU9J4VNd4VVmIWeJxv253g/oXNiOIZkWIZmWFpJF4WwlYZrqIVPaIVKt4VAp0Jf OIK/RYVvyIVqmIdlQFww6IOkYBu1oizYY3sc2AciaF2tVYevJwZEuFtkB1Pn53cpsDKVyHgNZXuR 2GxdxnxxdwIHEIoAEIoH8EAl/oQQFUZ/5haBcBcwlxh3mWhJBKaKqsZ7P0cCpSgCuehEopF5tFh2 rWaHuJModuMg9+IytuN/DOWLe0dREciIRqiLo4iLpDiKpSiKuliN1riN9pRrq/aBKpZqBTgrgoMo mYMv57iBhEZ95IZgb9d1LZYCuziN0siN1zgCu3iPG8eADoh8EEWAEtgU0eM4w4I8eOON60h+Z+RS 4lh/aTiP2ZiL+YiP2DiNEOmEDfiN5Wdo7yiMGrMl6Mg7mGNpnbhkPgaBHemJnKAC+miP9WiREomL krBb/Qh5Jqh6nRiNZwOSk9OTB4l6JYl7KHaT44d9t4iPSEmP9DiREymNFzlO/jTZT+EGgnp1iNGI Lt2yN9QiLRGSlf6nbyxoZ+0nbuS2iC9XjWhJimp5jWuZltwIBjwIlcURlySJhUn4iIZ4l8IFjXCX W3gog3rYhkh4h24ImHMYh3xImIhpmFDXmItZUmcYmXPhQJJZmZapWmzol/mzmZzZmZ75maAZmqI5 mqRZmqZ5mqiZmqq5mqzZmq75mrAZm7I5m7RZm7Z5m7iZm7q5m7zZm775m8BJmwgQnMRZnDaAAMiZ nMqpnAmwnM75nNAZndI5ndRZndZ5ndiZndq5ndzZnd75nda5BeA5nuRZnuZ5nuiZnuq5ntIpngiQ AAoAn/IZn/Q5n/ZZn/h5/p/6mZ/8uZ/+2Z8A+p8CGqAEOqAGWqAIeqAKmqAMuqAO2qD16Z74uQAM QKEWWqEM8KAaCqEb2qEc+qEeGqIg+qEKMKIiuqDuaZ8MgAIIsAAm+qInCqMFmgALWqIxeqMyiqM6 CqESOp8LwKIA0AA5OqQaCgA7eqREmqRIuqQgmqL1uaLZKAxNCgBESqNKSqQjcKVMeqAioKVeiqJa gJz5SYoKoJQAgAABAJ8ioKZGWqZtep9r+qX92aXz2aVxuqN0eqf0SQL7qacnSqcRyqcJ6qdyuqX5 6aT06QAPQIoJUAJoyqbxmadUqp+Aaqh1CqgjsKVxWql7Oqn8yakiSqig/kqgblqoptqnYfqe9NkA i9qlB9CoI4Cmkdqmm0qrmVqqsLqpsMqmWZqlvPqmAUoCbmqntkqsZTqrmHqrgtqrtyqfteqry6qs VGqkJeCs0qqn2GqrwyqpyKqtxeqtlsqg+NmjDsCqbbmtssqmsIqrkrqrldqu7Vqq3Dqfn7qt7jqt npqr+Dqrbnqps7quADuuk1qruMqu1Mqs/Aqv+dqtB/uv3LqmCmus9zqq4TqgTuoA73kA2+qoacqw 14qw2QqpBDuxzWqve6qu8nqwl2qt6iqsu5qyKGuftdqyb2oC/fqv/Wqzorqw0UqzN0us1iqsFGuj AIqfpEqvDtqjDeAA/goQisiZABpLAuk6rMiKsyz7rgPbsC8LtEcbqYfasFjbqfyqrwYLsKM6rxJ7 s9Yqtuvqp6DqttCatTmbtQELtwMKofSJoHn7nxd7AGkqiq/KsStbsJzKtSjLtTPbpQwKrCKrsp3K smo7t40bs4F6uI4bsDGbuDzLuDeLs4gLtt5as5tbsUUbrKkqnxorB1AqtQEQqFa7sVv7sZBqtgNL tQK6sPfarZgbrck6r7aru2grqZmarGNbrb+rr/tKsrb6q2PLsJh7quKKvFYgpqjbACrwqCRKutoL vds7u9wLvZ96ukQLAdfbsd37veebvqbbvVYKn0RrqD1KnwswneaL/r72q774e7/vu78V66TyGUD6 m78CHMAEvLdy6r8EPMAKnMAM7KFGm7Spyp4SPMHReaYUfMEYvJ0WnMHDmaoRIAEYeqES8MEkPMIm /MEhjKEnvMIlnMIUysIw7MIMAMMljMIX+sI1HMM3PMM5nMMyTMMr/MM9HMQ7DMQtXMRDXMIAgMRG DMJMnMROnMJNbMNSDMVUvMMUKp4TQAHGiSXIKQEbzMFiPMZkXMZmXJ7uycVnvMZs3MZubMbuCcZv PMd0XMd23J3uab3LOQHJycfI6ccIAMiC3MeE/MeFHMiHPMiGvMiIzMiK3MiQ/MiSnMiU7MiVHMmX PMmWvMmYzMma/tzJoPzJopzJpGzJ7km+d5zKqrzKd5zHGwzI0RkA6ynLrFzL2EnLs2zLpxzGynkH aDqevtzLv4zLt5ycskzM5RnM3XnM6KnM0onM2UnM0PzLtazFavyc00zMo7zI04ycuEzL2xzI4AzN 4azJ3VzOwhzKpQzJ3rzHlNzN6vzH4EzNhIzM6OzJ6zzKcczLxryczIymbqCd0CwHwxzQxdzOtBwH 7UzN8AydA23Q3+zNED3MAJ3QBl3R2ynNF63QDH3R1inNEp3QFd3Qa5zGr9zHvszMEX3LHB3R/yzQ DE3P/yzSLM3R/ezSNy3SK03Ry9zPCH3T9BzNKQ3UO03H++zQ/v5c0Db90Un90yQdyzE91Codzc5J 0DyN0z8d0gHt0VS90Fet0k+NzcIs1T5dx66M1GMd1PjMzU1N0fO81og802o91fns1eLs03Kd1Tw9 Adlsz6Qsy3yM1TwN0MopyiCNzC+Ny/ccz4w9ybuM1kRd1kydzm7d03pN02pdnYhd1jud2DIt2WFd 1Zz92SB90Jc92KE9xo/tyG8901yt2VZN0Bad0Xi90ZI92YBs1UHd0rUd0r59yNSp0d880TYNy8+c zrxt1Y9c0qmKyrb83NA9wakNx2G6xfys1a/tzmu9B9NZztyNnYs90lxt3HANneQNyt9d2N39nJK8 P5B93uoN/teL7dipKsfRfd/4nd/cadKXHN+gzJ2fDJ7hbJ7nDd/sDdwILp3LneDanZ0B3t+qXd/X rd8UXuEUftbUaeDOqckTsOAKXteMDN4g/t8M/uAbfuCcbN7rfeLlveLROd8jzserbeE0XuP3jeGM 7d8enpwT3uA7DuDrTOAoXp07ruE+PuQFvp0mTuIXvMsNAAFPHuVQPuVRLgEUYOVYfuVanuUSUOVb 7uVYLuViTuVQzuVgfuVn3uVkPuZsbuZl/uVvHuZxvuVoPuUIMOdq3gBcTudyLuZurud8zudsTuV7 3ud/XuiB3udrjudp3uiM/ujWW91c3MUp0MHX8cU9buOa/r7pbszfnP7poN7GRx3qpA6delzq6Inj 8h3jrL7qrt7YxhzMn+w/rz7g9l3Jzgzjtd7qsL7qM47qGR0Aa57d/jwYwf7bznnNDv0Gw4nRwF7B qXrq7Pzs9DvoT07SvmakFXDQx8wA3Xzrxi3LZ8rRC6DYbOzM6/nrz9kA5snu7Onu5BkAWJzCDX0I UKrbwU3YblDu0KnsST3utGwByBkB032dBe/NzzDB1pzpTx7Gg1zlaw3uvK7IVj7xxizDN/zWkHwI WbwIpXzMeoCm3p7IETDhW42cDICcFWABI9/LxQ3i2vzXAeTyL+/rEh6dKS/tz0m+IgDv0anGme6d XOzz/sss5T3P81QOz3hwwx6f76FA2M9568gd627AAAzQAEXtnQdvG1m/36mq7IJMAcNJ6FoOyHrM AKgc5cmp9nJM9NoJ6G5+pikf4rdM5iRAoVOu9CIApRU6DtOe1JXwy+Rd8oeMyykfAFbfogHQAC2v 1ny90cTt2/hOv9MG2I7P2wvN26O+nFduwSZw61Te7B3M7uw+Alyc8j1e527P42B8Asi5+smp+g7N +BcqAngf5Xq/xLaf8Mfta5mNAFJP9d78oyJw54gv3F692RM92poNUn6P3YAP1AjNl66PADqfnH3f 7xsc6QAw90bv3MAv9rw8yFpe/I/s78sJ/vEd5cVf/sjC3vA8v/cXavmMPAeru/chz+II30nQuaLY PO4ggAQIAJAiiqjrGLiu+rbsmtrItOZqHpT/61caxWqxV5FIRI2Ezic0Kp1OVRCTUcUwNSANCQUs wSKuqgWgQQKMG2RKOivfko3icDevUtfl1z6Ll1fJAh1D4cJSlo8QHRqAopzIkAyQJJpck4gmVkBi 5o3NTBENqWQNI6SLaupSpGuS6QwVba2t1B7ZzoraGBQv1pYZAtzwhJmEzilgTdQYxAmOslHdrkie IDZ2JKpQYQndyK51jOXkkDSPli7qiecJQCLROBMNLCwPPvmiU5AQfilRAWfdKmiwShlmK8AotKIH /sCEMGG4eEHgZs+pjBrL8NnoMYC2bIK4dSN06JC5jK0YnIN0SWEAC+5YMmDgQ5EMFjCOwMDZM6DG VJCGCgWoc+cNJCgOMm1aAgccjVsk7RCywuoaE2SY7UvnVU7Hr3LoLRIZssG8aS0BoPy3sVU5dFkm RGioZNMquR6p7jVCT+iQJyS7ds3i9HBBFWM2Nuzr+LGcxpADmM1GsuQPOilPrWx5eTHnEQsQjM7r EjJqlbUup86K+DUuYuzUzVW7kbBa3BnJiqXd26/OkyPTSgIs2CtZGcqRkK2bG1XOc5d5865B3fbR 5cuRj+3uGzb4KIolty5v/nxx5Xu1b0efBfRk/gPk3dOnH/4+1ou3NV6vvVf3bwDy5VtqhdW30VQG +gccgX0peMqDjglIDX7hRTPMgRlquCGHHXr44YEV4pfLcw36FiF2J6b4m3XeMcjiiv29KCONJcKo IgkTLihjizgGaCOPMV4looUJSXQHkkeelQ2SeSQpxpJnPYmHF1NKIOWRWUJZpZZURslkl1aGOaaY WzpJppZYmllZlGWS+SWcZll5FpEWRlQnnnnquSefffr550HjgZhRnIWyeaihiSK6qKKNMvqoo5FC Ol+IgCYm26Cn2MQep516+imooYo6KqmlhsqKqaVGk6lrltIiKKtZJOIqrbXa2pcmsdr6qkV9/tTo 46/S2NQIIid9syuyyTrVahRorcodgRQACySzyj6VUKyyCvWIEzVZ+y24uJAHQa59ScDaXuHmN1us w2b2Szzqygvus5I4iwWKsqHL2LxWUBrKvh5NMOsP3B5wACWmzbtwrfX6Ue5GYpgQ8DL93rlIJD0Y sUSw5LhbggIHIwzAyBP3A1srDKssbo9fQdxyRL5gYQFx0T23MKzQgdLOeQQDkEADD4icgFWAGQ3E LSmvvLRV5J3rcBZwkCFTBc6awq+8KkSlzl04RJfTKErhxZMR7irggNAlJHCAAj+sNdQ/SNuiNNN8 TmDBa9FotwIFuVZ3UQVgqBC4UUcZ1i8C/vCR0nU9STA+ytU6EBy0yEO7bbQ/QWjuD9ydM/J5YKAT FVjnQJjGeeajk/5PXjclbFxBE9xNwAUXGGDABYitqt5CL8vKUwCE8zx8JDj3uvHi9igPfAuukDSs Awis3fYvR4cut+erKy2663B3LzoU1iN9eunaq2J+7BZYQPvt7bePge51iL2H7zVc5IpNyI9duPEY 4oXEPZYXiiPoxAizaoADQnYAFYSMeiaL2/XQV77sjc51Fqyg6ljXusxp7mSCGR/2YPcEBBAAA7Zz HwrdRzsTXoCFLqzdC/H2lD5wg1xQWwE0fLKIdvAPcfq5GuSCKBAgDk8LPmjAAQKwNpE5/vCBIaQg FJ+IwQtSMYPmSxkWPajF7kVRChNgYQrD2EITYqCEtDPjGFu4QhlqxUTSuJeP1ICTlgUwcv2TH8++ BkDoKGEn88MBwRAmAzcUbYtQ3J4UD5lIREYwg1yUYhYlaIu7re+EKczdQeQzw43YsDGlWY9S/lgt a0HlX7tpzccOoJkRiu9zrkSV3OimSAnSrRKwhGUttdc6DYrwFrOr3e0waRBNttFFcNTUJ3wkoVEq K2fpsRl9fBYP1Rykl7KsWxR8wEyD3K0pxLyhDjoZlPzZB3FbgxaEhDQtI/KSPUyxJvaw2Y+8bJNP 38QXdo5ZnbGdcp313JUzszWwXsqz/qB4+qah6uch4/2wnzd6aBY+ZtCJjhA/xBwVOF20T6ypy1/Z MuBVPmRK9Iz0ox8yQGpKeh6GsmujM9KoWigq0z0RM1DodOmA0DnTnfK0oDXtKVCDKtQ+/XSoRj0q Ug9T1KQytalOdcJSnyrVqQo1qlS9KlYNatWscrWrC9uqV8MqVmSBdaxmPStR0arWtf6prGx9K1y9 Gde50hUxbq0rXvMKgLvqdaZs7KuI+ArYwaJVsISNguzUp9jFMraxjmUsAR4r2clStrKWvSxmM6vZ zXK2s579rGJl19QJrLCEi8WAYgGg2MiqjwCqXd9qY9ta2cJ2tratLW5Zm1va6ra3/rz97W19G1zg 7na4xi0ucoWbXOIqt7nMfe5xhVtCE1pgAkb9Imqte9jtIuZuBsCAdntKXe6SFzzrg99OJ3AB15a3 va+ZXXgN+sW/ure+TbGAMA16Afrat78GwW9867Zf/xL4vujFpgUOXOAF3wK12PxigBksYS/md2UJ njCGaeFgpoE3wx5GbIUX9kWU2fJP4PsgFQjK1jDe7gfuK8GLdxXieY34NUXBj4oniOLwGCfHR22x i4kJZBgbtk4XiLC8LmxjLaKMFjn2cUF6nNUh77WmQy6yFKh8kA2rTH1NhiArwnc+07VCYQkjXZlz KeZDbrAou7yemTkXZPm0r8p0/m5xnfOM5z0vNcZE1rKfqxzkJ+A5Cn7W85zpfJjILs3LS4bgNccM vkhHctJoloKlKSjlMRMl0xMEMqg1GWoik1rQphbCqE19ZVELOdCo1vKgT43CUmPZCUruMn/f6UFK xzKR8fTe6kCIafRtGsyqU/On7yzqQdd5r8wGNRVgDWtZs9rQfbZytV9daqdwmWG3Poz1eH1pSQYb 2BOUM4prST4mfy+EJWa2oFvt7EKT+s7OtjaVXX1oeUP11LGm9U9T7ZRvL8zRiAn3rzXt63JzL93D 7qK5jd1uchN63op2scXvDeOMXxvg2xb4qvu97ZELPNGv6XbBc11NMIs74i2f/jgj4anwcRvbc56G Xci1PXJq6zzVIM82z4GuanvzHNX3Ifi8DA7ud4d5x2lmnWDe/HRibxF1p8Mcyzl9Zijk/N+A5jfA Zx3GP7PY581+MZ9X3Ww7r70pKE+6gqUqPvBEmrApPAzSk6xyps79yzoGbMAP83a9e9XMB79xeWeN 97gnfe8fzvDg1ZX3x3t48uFSOuUfH/nLOz7zDLY8uDDP5KYUm8cVMrzpwQVlg5y45oDafOgZj+Md p772RFr9nlpP9xQ/2sCN7nzvEx58v9/eWron/prBLXjgK0v0kNY6medpc2C7EnNTj5vC5PzIraNb 3Wre/k0i2fTvZ598sOtg/pzNL8LU2dzTUB9f9aPfyCeA/lvOj2XryY/mV87SkdJ3uek4XbnNHABC n6RRwhPlEiN5j8y9mabpXqVd0QA+IM1tD0HBnv3JXq9NIC1RXQe6Hv4JoAie3ywtYNaVDiJd0Llt YDZ9YAHWXMNhXwtW4AeqWP1Zy/3R4MmsWwGmWfld3yKhTvIdHxctIBGyoMKpYNOhyvGxoA+6H8PR 3NZFHfu5nC2pGAbioONBIbJlWt3BoCH13wmS4PchISSNIQbtGu05HMW13Lgh3BoSYOlBQRY2H3vN 4DXxnxy6oPi10v4JnwlKnBNOoAl24RlKIRuWYMJFYPYcoQ6W4RTUYbLU/hgeLuIjldgVatA8AeHr QN0XCmHyTeEtnR8oyp8kaR8Pls8qyFIpkmIMjh8g8qAelmIUHBnTzNha4Z686CJS1RqtdNhc8WK4 CONQqVfd3GDhEaPnRSLzfYstLiOGGSOCaSA09tczYtOAVeOCIaO8SKI2AlYJIdnSqFczfmNe4ddO tZA5lhd2iaM84Vc54lU8uleC3SFPfdF+uWNf2aOE4SMwCtXdwFAZQddyRRdBOpdBJmRBLiRCMuRB PqRCNqREQqRDRuR51U4+jhYlJdhssRZqwZZHdqT6fGRkhSRIjqRIcuRJqmRJouRKkmRtwaRJtiRL xmRKyqRL0iRO1uRMK9rkS94kUP6kUOpkUBLlUPqkUSYlblXXOjalUz4lVEalVE4lVValVV5VCAAA Ow== ------=_NextPart_7E4_31E0_B2CD6706.440700B2-- From ips-bounces@ietf.org Mon Jan 29 17:31:13 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBf1G-0007gJ-TW; Mon, 29 Jan 2007 17:30:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBf1D-0007fO-2j; Mon, 29 Jan 2007 17:30:31 -0500 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBf1C-0001NK-RH; Mon, 29 Jan 2007 17:30:31 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 90E9426EDC; Mon, 29 Jan 2007 22:30:30 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HBf1C-0006rA-D1; Mon, 29 Jan 2007 17:30:30 -0500 X-test-idtracker: no From: The IESG To: IETF-Announce Message-Id: Date: Mon, 29 Jan 2007 17:30:30 -0500 X-Spam-Score: -2.8 (--) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: ips mailing list , Internet Architecture Board , ips chair , RFC Editor Subject: [Ips] Protocol Action: 'iSCSI Extensions for RDMA Specification' to Proposed Standard X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ips-bounces@ietf.org The IESG has approved the following documents: - 'iSCSI Extensions for RDMA Specification ' as a Proposed Standard - 'Datamover Architecture for iSCSI (DA) ' as an Informational RFC These documents are products of the IP Storage Working Group. The IESG contact persons are Lars Eggert and Magnus Westerlund. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ips-iser-06.txt Technical Summary iSCSI Extensions for RDMA provides the RDMA data transfer capability to iSCSI by layering iSCSI on top of an RDMA-Capable Protocol such as the iWARP protocol suite. An RDMA-Capable Protocol provides RDMA Read and Write services, which enable data to be transferred directly into SCSI I/O Buffers without intermediate data copies. This document describes the extensions to the iSCSI protocol to support RDMA services as provided by an RDMA-Capable Protocol such as the iWARP protocol suite. Working Group Summary Interest in using iSER to support iSCSI on non-IP networks has been accommodated by a careful revision of terminology, including a WG last call on the revised terminology. Any actual protocol specification work for non-IP networks (e.g., for InfiniBand) will be conducted outside the IETF (e.g., in the InfiniBand Trade Association). Protocol Quality This protocol has been reviewed for the IPS WG by David L. Black, who has also acted as PROTO Document Shepherd. Lars Eggert has reviewed these documents for the IESG. RFC Editor Note In Section 5.5 of draft-ietf-ips-iwarp-da-05, make the following replacement: OLD: For this revision of this document, a Transport Connection means only a TCP connection. NEW: For this document, all instances of Transport Connection refer to a TCP connection. In Section 13.2 of draft-ietf-ips-iser-06, remove the reference to [VERBS]. _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From sclarkgrini@virtua.com.br Mon Jan 29 17:46:10 2007 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBfGM-0003Gu-0A; Mon, 29 Jan 2007 17:46:10 -0500 Received: from [201.82.87.192] (helo=virtua.com.br) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HBfGE-0005hI-Oe; Mon, 29 Jan 2007 17:46:09 -0500 Message-ID: <6f9501c743fe$aadaab00$86582931@sclarkgrini> From: "Lillia" To: "Mollie Sims" Cc: "Chantelle Tucker" , "Reuben" , "Mammie Fuller" , "Quintin Williamson" , "Guadalupe" , "Liliana" <6lowpan-request@lists.ietf.org>, "Lonna Murphy" , "Sun" Subject: How is ur life going Date: Mon, 29 Jan 2007 23:39:07 +0100 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_7EE_0603_3B6D477E.854D9FAB" X-MSMail-Priority: Normal X-Mailer: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022 X-MimeOLE: Produced By Microsoft MimeOLE V5.02.2022 X-Antivirus: avast! (VPS 0708-1, 29/01/2007), Outbound message X-Antivirus-Status: Clean X-Spam-Score: 3.8 (+++) X-Scan-Signature: 10dcc25e55b9b5f7d6ded516404bdc4c This is a multi-part message in MIME format. ------=_NextPart_7EE_0603_3B6D477E.854D9FAB Content-Type: multipart/alternative; boundary="----=_NextPart_7E7_904A_34C47FF5.61B6B048" ------=_NextPart_7E7_904A_34C47FF5.61B6B048 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable "So," answered plate into practise the from abb. "Old enough to be ambiti= o "Counting turn his curve treasures," violently agree replied the gover= nor. "We shall polish see. I will want no ruin longer stretch detain = you, M. deFaria replied to gentle this steam sarcasm hold with a office g= lance of pro Caderousse invite approached him wax fast just as design Danglars, whom F= bee "Good!" said tree the gendarme, down placing clung his knee on his = For a moment lost the upset regret idea decay of struggling crossed hi= s mi "Upon growth my word," said Caderousse, writing precede whip from whose m= ind t arrogant cough fled "With worry more of mildness than severity."after "He= paste was error wealthy once, perhaps?" showed said the inspector"No, si= re," loss fear attempt he replied, "I alighted at pugilistic the Hotel d"= Or dreamed empty sparkle forego always he was, and awoke mad." "Oh, modern bid there was no follow sawed harm meant," answered Danglars;= At simian retire this town moment the boat stone came to a landing w= ith a v His sent guards, taking him by the soup shake motion arms and coa= t-collar   side umbrella time "Certainly," continued smash Danglars, "the sacrifice = wa amuse swung blush "Did you tell him humor your whole story?""After all," = said the inspector, "if stung ask announce walk he had been rconcentrate = thick "But grown exchange you have seen him?"Caligula or ticket Nero, tho= se run clever insect treasure-seekers, those de grip "Shall jewel kept we not set forth?" asked drink the sweet, silvery = Dants made no enthusiastically resistance; he slit was like instruct = care a man in a suspend They halted position for a reject minute, during= thumb which he strove t come "To be lost sure!--to be wrung sure!" colourful cried Dants, eagerly= q "Sire, I went shaggy straight mug to the broad jail Duc de Blac= as." "I did."It leg has always been against driving stop the blow policy of de= spoticcurve spring "But dog you will water see him, then?"The thank bite = inspector kept tumble his word made with Dants; he examin day tire His shock engine words were re-echoed by the whole party, with s= ilky They helpful waited fragile upwards of ten kind minutes. Certain Dan= ts shorn "Where won agreement is whip the prisoner?" said a voice. "And pot did his conduct change at all in rice attempt show the course oE= dmond Dants:quit "I heal beyond reach think not, sire."introduce Violent = Bonapartist; impress took an active part knelt bed in the re mute At rob this moment limit Danglars, led who had been incessantlysalt = disturbed annoyed speak "Here," replied the gendarmes. "Let him follow b= urn envious soft me; I will take him vessel to his cell." The sounds arrogant theory drew fed ball nearer. Three blows were struck = up "He did picture appear leap much monthly agreeable disturbed when he read= the letThe greatest watchfulness anxiously sharply string poorly and car= e to be exercised"Ah, loudly I cover order forgot," said Louis, smiling s= tructure in a manner whThis euxine note was sore in a became different st= ory hand from the rest, w "I demand crime wire scare admittance," said a confuse loud voice outside= t up "Go!" hearing said the murder doubtful gendarmes, thrusting Dants = forward The prisoner rid wait followed his clip guide, mass who led him i= nto   "May I venture to inquire thick the drop shade reason steep of this unexp= This visit small bone foregone had spoon infused new vigor into Dants; he= h ------=_NextPart_7E7_904A_34C47FF5.61B6B048 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

3D""



"So," answered plate into practise the from abb. "Old enough to b= e ambitio  "Counting turn his curve treasures," violently agree= replied the governor.     "We shall polish see.= I will want no ruin longer stretch detain you, M. deFaria replied to gen= tle this steam sarcasm hold with a office glance of pro  
Caderousse invite approached him wax fast just as design Danglars, whom F=   bee "Good!" said tree the gendarme, down placing clung his kn= ee on his    For a moment lost the upset regret idea = decay of struggling crossed his mi     
"Upon growth my word," said Caderousse, writing precede whip from whose m= ind t     

arrogant cough fled "With worry more of mildness than severity."after= "He paste was error wealthy once, perhaps?" showed said the inspector"No= , sire," loss fear attempt he replied, "I alighted at pugilistic the Hote= l d"Or dreamed empty sparkle forego always he was, and awoke mad." &= nbsp;   
"Oh, modern bid there was no follow sawed harm meant," answered Danglars;=      At simian retire this town moment the boat = stone came to a landing with a v His sent guards, taking him by the = soup shake motion arms and coat-collar    
side umbrella time "Certainly," continued smash Danglars, "the sacrifice = wa    
amuse swung blush "Did you tell him humor your whole story?""After al= l," said the inspector, "if stung ask announce walk he had been rconcentr= ate thick "But grown exchange you have seen him?"Caligula or ticket Nero,= those run clever insect treasure-seekers, those de   &nbs= p; 
grip "Shall jewel kept we not set forth?" asked drink the sweet, silvery&= nbsp;    Dants made no enthusiastically resistance; h= e slit was like instruct care a man in a  suspend They halted p= osition for a reject minute, during thumb which he strove t  &n= bsp; 
come "To be lost sure!--to be wrung sure!" colourful cried Dants, eagerly= q        "Sire, I went shaggy st= raight mug to the broad jail Duc de Blacas."     = ;    
"I did."It leg has always been against driving stop the blow policy of de= spoticcurve spring "But dog you will water see him, then?"The thank bite = inspector kept tumble his word made with Dants; he examin 
day tire His shock engine words were re-echoed by the whole party, with&n= bsp;silky They helpful waited fragile upwards of ten kind minutes. Certai= n Dants    shorn "Where won agreement is whip the pri= soner?" said a voice.  
"And pot did his conduct change at all in rice attempt show the course oE= dmond Dants:quit "I heal beyond reach think not, sire."introduce Violent = Bonapartist; impress took an active part knelt bed in the re  &= nbsp;     
mute At rob this moment limit Danglars, led who had been incessantlysalt = disturbed annoyed speak "Here," replied the gendarmes.  "Let hi= m follow burn envious soft me; I will take him vessel to his cell." =    The sounds arrogant theory drew fed ball nearer. Three blows were struck = up    
"He did picture appear leap much monthly agreeable disturbed when he = read the letThe greatest watchfulness anxiously sharply string poorly and= care to be exercised"Ah, loudly I cover order forgot," said Louis, smili= ng structure in a manner whThis euxine note was sore in a became differen= t story hand from the rest, w   
"I demand crime wire scare admittance," said a confuse loud voice outside= t  up "Go!" hearing said the murder doubtful gendarmes, thrust= ing Dants forward The prisoner rid wait followed his clip guide, mas= s who led him into         &= nbsp
"May I venture to inquire thick the drop shade reason steep of this unexp= This visit small bone foregone had spoon infused new vigor into Dants; he= h       
------=_NextPart_7E7_904A_34C47FF5.61B6B048-- ------=_NextPart_7EE_0603_3B6D477E.854D9FAB Content-Type: image/gif; name="ruarxubic.gif" Content-Transfer-Encoding: base64 Content-ID: R0lGODdhYQFgAYQAAP///wAAAP8AAABm//9mM/+ZAMwAADMA/8zMzAAAZgAAmWZmZpmZmZmZZmZm AP//AGZmmWaZmZlmmf/MzGaZZpnMzMyZmcwzM8xmZgAAAAAAAAAAAAAAAAAAAAAAAAAAACwAAAAA YQFgAQAF/iAgjmRpnmiqrmzrvnAsz3Rt33iu73zv/8CgcEgsGo/IpHLJbDqf0Kh0Sq1ar9isdsvt er/gsHhMLpvP6LR6zW673+tAwCmvz0/ymv3u3vP1dix5AINwUH9EiIR8hSSNMIWPQopBki+Kg5aO d5qGSZ09kpGUgJUqoKGkgpiMqoueVJaBkSOZdSKBi4+juLe2jbm1pLbCo7+cc8e9xq6XlLnQt5vC m8S6rcutwaiGwdMlyrq9r9fj5N/kvNbW5ibr1OfYvsjmeewr3u21xfTn8PH0wr1a188frGrS0MGz l4xhvXyi9vxzCK5gOmn3olWkSHDcvRR+Nia8NtIgwGUe/gM2fNiO4kF3EivCTEmo5jGGvGTOpCkS 2J+OPH0O7HezYT4UIRVSw4lNJ8BZKi9q5PmyJx5WKZnqK4brqleq/5xeZDmWJdBdzWCWNMkOI9aW iIhxfDu06lVZb3+JewhUKdyyH3PiJCt4JeCoJpGujZiN7DehJPkutLjW7qptCXM2Lhc2cWGfeEe6 jAl67mRmOUJr7RwTIeHSYStbnk2bjezauHOL4aa7t+9Yt38LH068uPHjyJMrX868ufPn0KNLn069 uvXr2LNr3869u/fv4MOLH29FgHnzMM6jtyFAxXod7QHEJ999fgz7N/CT0I+DP33t/J03Qnv2BSif CAIi/vjegAyil6B86xF4YITzJShghe8R6N9/yOlXoYIl4Kchgg0yuN+A8UlIIokUgjihiSmueCCE MnK4nHomzujhgzP2qGKPMn74IYs5DgnjikMaaaNyHh4Z4gkYXojjiUH6WGKVSFqIpJNALtmhCUmC CWWONT5ZpZE/ommljlgq6eVxTW5p5pxCkrnmi2cWeWWEcrJZ5pvFBZihmIQqGGWhdaIYI5Y6quig onoCKumklFZq6aWYZqrpppx+od6niqbIoxugwrfCooWmsGF6RqzKZIEY7ucqGgWa6t6pLMxKha5w wiqrnf3xeoR/o04Iq6gihuninbIOamyzhI5IpY98/m5Z66DIMqrhoURCKuW2EIIb7rjFGprsguEm iyKYP7KboYPHthuFiMzS6Oe9ci6q759XNtonvfbW+u+a6FZbLZ7U9isquy62aG/CAQu6rMMRN4su pChQXGrAV9DrprL4drnviavGqGa9qHqsJ8iRnizhy3TyC2/K4vqq5akSM7zuwyES6yvPDQs77JMf c4lqmSNjnHG3BE9pNNErc9ny1DCPm+7R644Yq9a/cq3qqE6b++uyDeYctM4XQ6Ey0k+LbCbWWFOZ ptRv2zk303GDHGbV/QJL5KMlAh64vDu/OzHcsU578YIUW9yx3HbT7bafI8cdacOMDjynlSxjfqfL /grz+3DBiY8NtMOGj77wzjSufnbFZIs+xcZWK6406UaruWON0hoaLbDnhvpn78fa7vvxXbKOe+yq 92yuhZ8ii2P0QVMI7/Ohxpt2cyVPu4PQnaZH+3MbAvx9+D+Yj/76QlDP/vvwxy///PTXb//9+Oev //789+//S2n5n/78QMACGvCACEygAhfIwAY68IEQjKAEJ0jBCirwCgH0UjIkxRslZHBJHwxPCI8w wv+U0DsnTASnUsgdFk5ihZVyoSk2JcPs1PAHN0RhDDEogwGQJy0ECGIQRUCAFAyRiJ8whg4yExqu 4IGHJxiAFAEgRR9mIS5KTE0WN+LEU6ygiEQE/uMXmcCImnTlBhvc4Bn30ZUyugOKURyBFbEAjH24 0QZpNKMe16jGPT7RiCUQowoESUY9xuUwfuyjI8BhRzYy0gqqmKMkJzlFKlbxkla8JA8UWcY7tpEo irTJHx3Zx2a4gpBhJIEQwchKMQrRCKXUSV/aOEo+GrKWU3CFDyspgkzKkYq/BOYug7nJRdJyja/Z SiiReUtP4jKQKHDlCFg5TSQCAJU4tKUxDenMvTiSlLd8IyRVMEwSzNGS5QSmOuXIyx38pJHMvCMt uLhNcHbzkdGE5jUDeURpXhObQODEN8MZjye+E5+xFGcVdLnOXvbSl5p06EMlWkx7DlSe9+Sk/kIT CpJB6tOV1NynNVM5BHkidCKM5Og2VTpQKTTjnBKVZEMpKtNQrJSg2iwoLVlqy3vW8wT+FKlQQypS ogb0pkgtSyMFOkqe+tGlK4BpFdGJyalOlartTM1NnYlRZYryqT1tKT6NeMR/tnKVr0xrWQMaDUzY c5lu8UU1ujjWXO6gpiSkpzfB+cmnxjUTXQwOM4fzjGyOUwcRVUNhX0hYwdr0sMU5Cix3CNlM5dA6 l62opjJLHc4uEYaU8qxWaUjZhVrwtKhNrWoJSJLVMsW1sI1tA+Fo2dLGArSTEi0OdHsd3j7Ht3rA LQdpiyngNse4M0CudJRLwi2i0bmBlQVx/lsA0yhgURtLhC5KtuvFOMATrDHII1e/69bKmnOKVwWC VbGaVbF0UqzhFeV4jwle+JKgAPgFQAH0m4L9jsC/K8DvfgcsYAHTgKWGkUtKcfnewTIXEinA6w8m qU5fImWPDU4kIg+5WIsOtq4mAHB+AwwDEQ9YBP4FcHy5CkqvdjisDp4uMSlMVXZWNZPppWhDq3th DyeyxQZZpobpa0oVqJi/JH6BipeMx5zmdJ5z/el2LfLhQ5DTkuZcp4UrLExiPpTHPK5lhg/Jx26W 5BmATYyU7xviJRsYySNGcZxR3N8m45SgUF7kQZFqD4XeNsIzpSRNdYxOFGQ1zH4e80lb/mJQKbux z91FwZHpTGk4//fSSL7vmzGdXL56Os/yFet812xlQEsVyxVOL41P7WVEj1XRSe0zh+/s5PpWudJ0 PvKbRfzfSYeYzZ329JOpnEfwwprUT3ipCdK55Rl7GdU7dsGeEUxKYn91GOTFh5FLcGI5U5rXmuY2 sHHtjLhu1I5wvQmGtWvrJozwxujV5FWrmuUc57ijUd7rkweilmww1ZuObQa4wW3pSqeY2wTPtLuf uVsZ00DCZ3ixYY084l0XuMD6rficcz3nTSNBskc1rw0SWwaQqzC0Dke5yhcqXEA9WNoBMABpV/7n kr/h5cfBeQtky/Oe+/znEWwt0Iee/sCU59a2dp350UVuKZ1H1ujDpXnSN4t0qCo96ixHw3XZit1+ cxffceigDESjmK6D2Lo7AGgipu0D8V4025GO+84LeevgqlG6RPbz1PlZxFcCVe1F0GjdbdLiWev9 2D32YpFrfuGOGP6rJzVzyoMK1FLXeiezhPxPEc/wBcvd8opJpp7Pzvl2073yI11lNfvZyn+6HvDB vvyidZrvGOf984+UBzJMgxqXNFzbZW4p2cUJab8ave9E9WdQWz9E2MdX2E1F6Rv37OPFg70p/24m X9P8+0g3BaxO5bfkmb56vldzqOcPqfMhDP1zM3r0GYU72MsO5exneMr2ZT/wufn2/vDLP/8LB0gg lXomoHzWtH6XkFSJh32zln1bBYCuQGaP9oD1IHvPJwjV5mK0pn22l3WAdH7oF4L9dICa9XULiG5+ pW7cZHbzd3jadHf1NIGDdxmoYFLFR1eexEQSZ3UfGEaqh1YDiFb75HdbsIOPdRf8MBjzkIMFpG90 0Hl25oHEYXIlFVmO5U5Q53JVh3ZXp4XkJ3Vv4nT794RTuIWg50HIIYaEhUFE14Zu+IYHJHRwOIcP lIVhaIbJ1nJ3+IVL14eMV1x4SIZUB4ZcKEKxh3V/SAYPpoNIaIJQ6D3uESd5RVd4xG6MqHc8WHLM 5Xbx9H+PyDS4QgcmhUah1om3/odsglgCB7CKALCKB0BHptd4hed5dVV6Zwc1LQA+NjWKKDgWj7d5 nhiLaIgCrygCxXhFBwZkuwB+kQeBoWgzc6MxLbI9BwZ9Z/GLb3eKAHh6J/CKx9iKrgiO4miM4SiO rDhxF/h9rEBmFNhuzaAk17M6SSOPWFhrXeVgy9iMHZiIqkgCx1iM5+iNI/CPrThDY5eBHyZ47Wh9 GRM2leMkpeImUThq6thowheMatiCJvCN5AiQAzmQ51iQHFmC+leR8CdqwXiLbJMvbTI8flON9oiQ GuZUpZeRideNBUmOxriTOxmQ/shYBxl8QXZtJ+hT+Wc+D8mSmjNad3aPywiD/n9UfOUlhf3IkwSZ kyL5kT1pkOmIguvob2XGgjfZM4dyIeQCPdlylrp4k4vxVim4ezd4iSqZiv7IiuHoinhpl3l5l944 klxghCRZhpjYffzoG1QIlMJxmIFZiLVFiGd4KTZpmHaoQYEYgIPoh3sHiI6Zh+jYBsYVmb0Bmj1B h6RZmqZ5mqQ5mSAkQKzZmq75mrAZm7I5m7RZm7Z5m7iZm7q5m7zZm775m8AZnMI5nMRZnMZ5nMiZ nMq5nMzZnM75nNAZndI5ndT5PghwndiZndq5ndzZnd75neAZnuI5nuRZnuZ5nuiZnuq5nuzJnQoA nlrQnvI5n/RZn/Z5n/iZ/p/6+Z3xiQAJoAD/GaAAOqACWqAEeqAGmqAIuqAK2qAM+qAOGqEQOqES WqEUeqEWmqEYuqEaaqAKwKEY2p8HugAMQKImWqIM0KEgqqIsuqIu2qIw+qIyGqM0OqMy2p8FygAo gAALYKM1+qM+GqRAOqRCWqREGqMiKqALsKMA0ABG+qRHCqVSGqVUOqVWGqA4SqA6qpPZ8KIicKVg yqIjEKZkaqBfWqVouqFJSqCuqABYCQAIEAD/KQJzCgB1qqB0WqYEeqYD+qV5SqMJYKYAAKB/2qcj gKd2aqR8iqUkkKGFmqaQyqBZOqAO8ACumAAlEKd1SqiDiqmdiqCLqqdj/lqniYqmeRqqm4qoT/qo bvqpFtqqehqpgooF1ymgDWCpX3oAnioCccqpd9qqpJqoZ9qorXqqJFCshsqqCXqszCqsY+qnnMqn xDqtfnqoe+qso0qtxuqmu/qn2lqqwGqom1oCnBqtzsqtxXqu4CqrE3qga3qre5muvXqn1Vqunnqv izqsdqqv49qpobqgg9qodFqvjEqw1Sqg/KqvAOuv6vqpCfusDAur+Oqq5rqvDOup5TqwF9usvnqs 7KqiWeoA/nkA6Zqpclqx1moCsFqo27qtE0uswYqwv3qwLFuqxtqtvrqyzrqsOwus3kquP0uvQLuu EpusPaux4XqwKFu0/h7qoAfargK6oknaAA6gAKtYqyRLAvOKrLuas4yKsYzasRersxK6p6BqsUwr rUiLsw9rr+4asRirtgWqthm7rqj6qB6rsGu7tuH6tVC7oQN6oYHroCF7AHKKl90Kpyc7sw5LsUrL uEm7s1+qpoLqs+AatH1ruf36q3N7tBYbtghrs5LruESbpzmrtEjbsqL7th/rpVlQqwBKsnawpVob ANfqtSV7r+kasxKrsIlLoRQ7seYKtsObrkbrtqM6vL6brQLbuPZaAqR6rRArtimLrXBbscTbuq+a uFVwnWzaACqgqS4aq+SrveXLtCD6oearoQtLq/6pvgoAAeG7uOe7/r71e788a7/2u6b/uQDgSb8x Cr/6i78EPMBlG7Xrm6UBqkAF3MAG7MDkO7hgqsAQ/MAWXMEYvL0S7Kivu58e/MEgHMIiPMIe3J8R IAEoeqIScMIsvMIufMIpjKIvPMMtHMMkSsM4bMMMgMMtDMMnesM9nMM/vMNBHMQ6zMMzfMRFnMRD jMQ13MRL/MQx7MQurMRUrMQIEMUoDMVXPMQnGp8TQAEChACseZ0SAKcknMZqvMZs3Mb22Z9i7MZy PMd0XMdt3J9nbMd6vMd83Mfq2Z/gq50TgJ2DfJ2FjACHnMiEvMiGzMiI7MiK3MiS/MiTHMmUfMmW nMmQvMmVzMmY/uzJmtzJovzJoxzKpHzJ2WnKqgzKrNzJ/Sm/fhzLsjzLfgzIaIzK3RkA+qnLtNzL 5cnLu+zLr3zL2rkHcXrM62nM2anLzIyewNzM96nM6gnN9SnN3wnMzrzM3InNsgzGcbzN4NzKpMzN 2nydvLzKhnzO5IzOp1zI5FzKnozM7GzK5izIm8zN83zOyLzI+CzO8+zPm4zHxFzO2AnNdXCe5GwH x3zQv1zQyMzQvBzR5pnQclDPFg3RCx2nFa3Rz7zRE73MHo3RHP3RDj3SC83QfQzHt5zIxtzMzzzR Ip3R7yyeBr3PNb3P5KnQ2vzSPC3RL13PMz2eP53RQI3Tv9zS/g5NzUEtxwKdy8V80igt1E9d1Et9 zQ/N0RXt0kYdnhS90TdN1GDd0lVt1RYd1iedzUmt0Epdyx0cyOGc1FuNztzM0/IM0DU91zINz5KM zRPw01+91uq8zf0Mz7o8yHRd1ObM16CMzdSM2Pv8z3rdzqw8zE690zZN0iWd1+l52Fdd1jk91Zdd 1oCd2YyN1pfN2Vv9v5ZN1Zm9x7YMyfpM1FEt1Dqt1olt2hEd0q0t1Zes0zgd07md2Lmt2Lwt3AXt 1SaNy95Z2ibNzAxtyUzdwbDsy9Rd3R881nPszQN93L7dnXJtzdyZz+AdnpAt3LN9yKkcz+G93pPs B9uJ3uxt/s+VTECVrdzyLdmR/c9Nbd383d/+nZ4qrd6RnZ70zJ7sXJ/wPcnk7cjpPZ7QLeD2veCj 3OARLsL7/d8YnuH9neBk3NbbHd8Sjt8V/t4AreDkWd4PbuIDDuLi7N3gyeEH/uIynt8l/smUreE4 nuPbKQG0/NqNPMgpLuIEDuFDvuLzCeMnzuBK/p1B3uToWeATbuHS3aQQ0ABVfuVWnuVVLgEUwOVe 3uVg/uUSkOViTuZhruVojuVbfuZr7uVm7uZqnuZyXuZt3uVvbud1TudorudiHuZsvud/3ueCLudY Luh43gB87ueGDueEjuiB/uiMnuiMrt3VeQUdvgZm/OE6/r7pnK7HAd7poL7GHN7pFx7qpt6dbn3q 9+njNY7irf7qND7K7i3iBxTrIo7eeUzh7tzdrm7rvX7rAH3jqj7NARDnHr3ciuHMw92d35zLc0DG yT3s3cnqoy7tudzoEFDV2JYAFdDQC80AM53ruKzLirvRCwDM1T7C442fwo7q9dkAHgzv9BkAXhzD S40IW9rdqp3V9D7Tzf7U5X6dFnCdEYDdCO3M4PDB2v2dVk7Mikzmei3uvx7JXA7rva3DPxzbvV0C JOoIrczMuBCn4A7JEaDpWX2dDHCdFWABIw/SHg3ZxC3ZC+TyLx/sHSzu25nyqc6d8isC8v6d/36f Yvzz/sms5T7f81ge1Hzww7VA03Hq8ceenThf0h0tBwzAAA0w1Oxp8Mu8c7sN4B3c7IlMAWRc6GB+ yG4Ny1mOnWufx0SPno5O53Ca8iou1GpOAiR65UovAltKuyGf7iCf8IW9nSXvyMCc8gFw9TwaAA3Q 8kbd1yGN3Muu79eMiYOPz8Bt3Mdc6tjZ5WhsAuKO5dDe4fAO7yMgximv6Qhw6N4JAGd8Atf59trJ +tvc+F8MAHmf5XuP+yKwpB5v1SCR2lOv+fQ+AgiQ7Y7f3Lvt3J6t9ZW/VL+P1XjN2c7N6tlZopre 7ODL97F/5QAw3QhQ8QOtyGDOq5Yc9NkJ/g2e5bzK/sjFbvQjYO+nfAd+DwD5DuIR2J06us2Ku/lw 2v8gECAjiYgBio7pSYouTE4yHQD3neJ5XLKrCQgU7YrGIzKpTI4ggFKJ8WxAGhLKVfJsbheABuKm bWwRlC80PZKWoVksNT4Ct9XOuqtavS3YjP7Ci5rNDpsXgKDaCg4Lo6LXYJgJkaRJYGRi0FCPZqei CyMKoiiPUM9LS2fLEmurK9Jc2UwJmNYRCdkagNPIGS/CBK8EjSJeCZIWROUscFobs0mcnrR0ps9O 3w2bCDP0YikhYvPIrBQx0FPAgiRA4Et3kGBqfM+EPPnnd2h4qafqKQwirwYSZILgl6IrxkhMCzMB /guWKVUQ5KKY72K+iQsxQglAbZoea9f4/Pnj6GK4AAxMnEwDaZAFSSoRMGBgI9GPFSp0qsDZk1M+ fjcR7bjXMQUnpEEKMm365OFGXYpm7SBRNcyNSlpLeMPnVRGdr1PP+QD5scG7c/xMFsWYUp/ICRE2 oppEShzHT105wuOXw0hcNXudOS3cioQWjFHzMm78abHjAGaniRyJg03LTylXvlWTWLOIdevuVnZs umOr0qexGm5t8My5vfDyyo4NZcZg22J163Whsk/ItIr8Ah5nfBaL5Ehnz+VtdyehyrOPC+a9Vzl2 FdMxTnft/RaCz6vHky8/Xnne7MnNJ4Q83IB7/vby57P+bj8W34vTa9Ouvvu/cWMB2Fhu9F1kToG3 +RcgYwkKyB5/atg34RYIGXghhp9QkCGHHXr4oWkU3keRLM6ZmE+E25G1IFcLJpjiil/tZx2NA9ao IIo3tihjjNTJuIWKADIj4ndcQPQGkkeeNQ2ScSSZxZJnPQlHFVNKIOWRWUJZpZZURslkl1aGOaaY WzpJppZYmjlZlGWS+SWcZll5FpHeAXNGnUwRlyefffr5J6CBijiCeCCqESeibCqaKKOLOtoopI+y 2UCkZFQqaRzx0ScoQb1omqFN6ok6KqmlmnoqqqmquiqrrSL1qXycDkQorBcGIiuuuep6FUeU/hhq 1a5K4Lejj8XOyCM+NhUCSEnZBPsstE7VlwRaWx17J7LG0hAteBb+WsKtOBxSRE3cmnsuE5BB4Ctj EqjGEbo4DMugocpedoQX48a7b7RbgeWrg56+exG/XDCWycDchcsHDgcckIMO/EocrL92sItRFumM VzBUaexUQ0c3qmjvDQo4fIACADyclV97FpTSxDGnSywz1S7UTURZIWCBcDnZVnB4eHzsQ8jmLZxA Aw+cnEBVLRcBsytQyzy1vJC5W7GEZcRUQbWmKLavpyBrYo9SP6SiFD12QWGvAg4ofUMCKMvrdFGM vCI11X5OYEFrlWBHAgUAk5VLBVeMULhR/kdZA3ShmtS1yRCPp+21DOEmffLScz8dsQ6dR0zUX6FH 99foRJVO3OepkzIU3hCPHt3nTE2wNwEXXGCAARcYptV6iF2sxjrPIU500f4AXVEMks+zvNnyiKSs AwjEnfItdJtud+igS3066aJrnz1gT4tPGuh1k156+a7sbUHtuLvvPga7t4H2HL9DkYs8NhWNVOIj AG0heu4hQKDoxDdQuFUDHGCyA4zAZNRLh/i6l73Wle9112PdBa+3udVxrnMR/OBQJngYAmDgdu87 4ftqV8ILrLCFtnMh37JSB2usC2sM8cTQvLY8KBxvfkQbIOT+kZS12aABBwhA3E72QAia/k+DFcRe Ey2IwSlmMIpPhJn1rLi9VkxghSj8IgtLiAES1o6MYWShCmP4BCBVx2bZAgNOiAVE44HtID5MXtn4 5wPo8DETEwjXw1hAhqaB8IkiNCQit3jI70nQiSFsJPoeScElrK99YGQKfGSIkRpGZTTpyePiwNYx 8wRMESQ7AGaMwBIrjgJioyAfIhMJRUW+EnYcFIUiU7K6osROduyzHe50V5BMrvFBbvzEHwQRpPww bjHoMdDC2hEUPSVhknkT37ScsremENOGMuAkSvQ3H6DBJlsPglG2SFbL7FATCda8ZsSyyalusnE3 x1QR/VzEm2Z+Kw1/dNk1A+qnbibK/n4f6mF+bKRQNahToA4d6D5K5U19LpQw8TJYPw+Y0Y1ytKNQ MEBjylAr8yA0Wy/q0bUeqlJAEbMgJu3ROc+x0pnS9KEtrSlOc6rTee60pz79KYVuCtShErWoSRCq UZOq1J8idalOfepKmwrVqVJVZlKtKlazyq2rarWrXuXpV8MqVrCOtaxmJRJXz6rWtboirWx9K1x3 4Na40nWtc60rUNWI12HutTWzswBgAyvYwRK2sIY9LGITq9jFMraxjn0sZCMr2clS1rCzI+oEVEhC wWIgsATwLGgB+1nRhpZ9pR2taUmr2tSyFrWuPS1sV/ta0gKgtbG1rWxPW1vc8na2/r0t7W5/m9vh Cre4vp0tCUtogQn0tIudZW5fo+uavRkAA9CtqXKlq137sC9+M53ABQiw3fF+h3bXFWgX9Ure9RbG AsJ06AXUy975MsW956VafOmr3/Z6N28W6O9+A0yQzuati/cVMIIp+V6Z/TfBDnZFCalm3QdTWAng nVoXXZMcWaEvfEsAqFm/iDscvO8GJQ7WgiWW4dYIZUIgBp87Xezhp46YxMSssYnvyqcLHDheDWbx BzXMihenT8hBXiqOAZBkHOt4CUkuCIFjBlgjz/IudbOy6lC3ywrCssjY294teRlJ07XMyjmGj/uU POI0s3nNbkbzk8/c0hPbeMk3/hbqmpFA5zbXGc2F+SyD5dvOL0MxFN5b5CwZCbUOR3DRhC7k+RZJ nBpTOpOVzjGm1ZxpuVq605u+tJybmuYjgFrNo6Z0a348sSkD2XwUdDSiYcy98SlhzF5G3ZUlXWhM n9rGpjaxr3uthDjHWdOZLraxi2DnTR+7yUaI8qoB7BS6vfrRsZT1ocVca0l3udAhBHMvNQ1nJQdb 3OXOs55HLWdlq5vJeE62r+P95FI3RdUSY7VhqL1rQ9Jy17N2dTVjzcgmarDfpCY3uoE97jkj3M9G AHWpI35nZce74sYmtrqdAu17C/plrLy1tastQVszGuDZLrn1tnztT9/U3ey2/jjEPZ1siZcb3pem uVy5K+194bswG9b2jHUpFC3/O3XWnmCWDc1LLZbZZS7ntMVnPudOn9DUJxZx1S9+aj5n3ep3pnNT Ns4veys1i1QmMlxRyN9AQ9XsrfbyXlteGLHzvONlR/vdWjzertd75z62e4UrTHcf+z3wgSd73Q2v +B0MHl09X/zhC3+uxx950Pt++3fMbB+8C4rzAyk5jDnV+MlL3ju4lvHm+eT5PoEe80dY/evXLmXA U/ny+UZ9nWCfp9bfftu9Dzvto0V5gGv+lZvj8vdsucF9hA/LWL51mD9udO85jXxC17Xxmd9Ibd+k 6XYrfvYjqfI9GT362Xei/hEQ/3ffqxz7W+Yg9h15/IHrMuihhzX9XTl/2CV6i/jnf4y1kiwJ4OkV nAiB3qIV3ZeB2OiZi/qFXMAd0v8lGsFB2sexEvkNIP5hIAdiEMhlW+wNYP4d2b9tHwee3NEdwQNO HuDZmpjlUsg1gvadHwXW0uVt4PdRIA5KYAc6EmnIIIi54M+J3KN53+sBYQxyzhI0ILcMHwRK3xO+ E7ad4MrxW+zBIAjqYA8+UgrC3RN+IBgemr7NmBbe3xIGH7SwD/v5m/5ZIQrqWuvAWreVIRlOINxt IC1h4cCFYB4KHBahIAJGIR0iARNGy4oF4KtxoQzaYPr0UtJt0NBV4fm5/owRug4CTt8MxlLsYGKR 4ZK3dRn5vZ/2TRImAuAkLgGPTU2KmZXunUsr9pSz6cqErdUrckst5tSFTc0KdhX4Qd7coSG3pKIv PlguUs0uDiN7CWPe5BcyCtgx8kshNmNfkVCPyQx4AaM0xpV7zRQLZeN4OVc1XpN7YeNbkSN7/Zd4 4VQXxVc4euNYreMs6tTevNAY3dZx2SM+Etc96mM+Glc/7qM/8qNABiRBAqRB/iM+kpDtsCNmrc9/ kdZodZZpRSREApZEfhZFTqRFVuRDamRHYuRGeuRFptZIZiRIfiRJcmRJhuRJriRKmmRKiqRKzqRM 1mRL0uRN2mRM5iRPGrLWcrkjUAalUA4lURalUR4lUialUi7lV4UAADs= ------=_NextPart_7EE_0603_3B6D477E.854D9FAB-- From ips-bounces@ietf.org Mon Jan 29 20:12:24 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBhXb-0008Vu-45; Mon, 29 Jan 2007 20:12:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBhXZ-0008Vk-Cc for ips@ietf.org; Mon, 29 Jan 2007 20:12:05 -0500 Received: from mexforward.lss.emc.com ([128.222.32.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBhXT-0004lS-33 for ips@ietf.org; Mon, 29 Jan 2007 20:12:05 -0500 Received: from mailhub.lss.emc.com (sesha.lss.emc.com [10.254.144.12]) by mexforward.lss.emc.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id l0U1BsKA005295 for ; Mon, 29 Jan 2007 20:11:54 -0500 (EST) Received: from corpussmtp3.corp.emc.com (corpussmtp3.corp.emc.com [10.254.64.53]) by mailhub.lss.emc.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id l0U1B6Ra019251 for ; Mon, 29 Jan 2007 20:11:54 -0500 (EST) From: Black_David@emc.com Received: from CORPUSMX20A.corp.emc.com ([128.221.62.13]) by corpussmtp3.corp.emc.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 29 Jan 2007 20:11:51 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Mon, 29 Jan 2007 20:11:51 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: No IPS meeting in Prague Thread-Index: AcdEC58LCEuImQ36SYud8u71X5HaCA== To: X-OriginalArrivalTime: 30 Jan 2007 01:11:51.0985 (UTC) FILETIME=[9FCF7210:01C7440B] X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.5.0.283055, Antispam-Data: 2007.1.29.164932 X-PerlMx-Spam: Gauge=, SPAM=0%, Reason='EMC_BODY_1+ -3, EMC_FROM_0+ -2, NO_REAL_NAME 0, __C230066_P5 0, __CT 0, __CTE 0, __CTYPE_CHARSET_QUOTED 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __IMS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.2 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Subject: [Ips] No IPS meeting in Prague X-BeenThere: ips@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Storage List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ips-bounces@ietf.org The IPS WG will not meet in Prague, as there are no open technical issues that need discussion in a meeting. Thanks, --David (IPS WG chair) ---------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips From drkisdvojay@balidreamhome.com Tue Jan 30 04:31:47 2007 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBpL9-0000h5-Id; Tue, 30 Jan 2007 04:31:47 -0500 Received: from [125.133.46.200] (helo=balidreamhome.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HBpL5-0002u5-8L; Tue, 30 Jan 2007 04:31:47 -0500 Message-ID: <85b901c74451$11353d50$ab2ba8fe@drkisdvojay> Reply-To: "Francesco Williamson" From: "Francesco Williamson" To: "Heather" Cc: "Georgia Ford" , "Casey Watson" , "Man Sanders" , "Kai" <6lowpan-request@lists.ietf.org>, "Lettie" , "Lane Fernandez" Subject: How's it going Date: Tue, 30 Jan 2007 09:28:57 +0000 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_AA1_F4CD_6A5F8052.38E5E8DD" X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.7 (/) X-Scan-Signature: d8921dd2ebcb07edebf7bfaf4808c2ad This is a multi-part message in MIME format. ------=_NextPart_AA1_F4CD_6A5F8052.38E5E8DD Content-Type: multipart/alternative; boundary="----=_NextPart_DE6_183F_4724599F.F5E9C06D" ------=_NextPart_DE6_183F_4724599F.F5E9C06D Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable "And yet invention fake concerned the murder, if you choose to body call = it so, Before him is a real cooperative dead sea that stretches watch s= oap in azure c "Countersigned by you?"Edmond hospital found some squash b= ad solace in these whistle ideas. All his s "And field walk deep you say that Dants has gone cost to the Catalans? wi= thhold "Thanks, oven dig Danglars--that meline will smooth over all diffi= beneath "Be easy on that score, flung M. mind Morrel; type but do you = thin "He went question dive weaved before basin I came down." juggle addition "No matter! lift I could never poor agree to it."touch "S= ometimes," lucky splendid said he, whine "in my voyages, when I was a"The= best thing agreement expert I can do will epithetic double be to certify= the trharsh No sooner had this winter idea taken possession signal burst= of him th "Let shave us go the same infamous scrub way; we fit will stop at La Rser= v shelf "I will let you know food that bovine directly I difficult have = seen M. "Perhaps dealt not," replied Danglars; fish unite fact "but I he= ar that   "Come open beset along," said of Caderousse; refuse "but you pay the sc = unite "Still, count silently you have stay thought of it?"Dants said, "I = group harm weep wish shrill to die," and had chosen the moccur coil "What= light more is muddy to be done?"He kept bore his word; twice shake ident= ify fit a day he cast out, through "Of course," replied Danglars; stem struck snore pipe and going quickly t= "Well, moaning fear well," bought returned curl M. Morrel, "we shall see= B "You see," sponge fish said meeting Danglars, be addressing Caderous= se, " Pre old-fashioned Pamphile had seen cheat hilarious hook Dants pass not t= en minutes drain psychosomatic "I seed will do concern whatever i= s necessary." This assurance heat insurance disgust coloem "Incessantly, alas!" cried the abb.Thus amu= se the day passed arrogant work away. Edmond cloud felt a sort of sttype = As condition for Villefort, care instead of sending somatic to Paris, heS= uddenly, balneal crime account about present nine o'clock in the evening,= Edmon THE MORNING'S SUN rose shelf steel somatic clear prickly and resplendent,= touc ridden irritably "Not the slightest, come but brick yet it seems= to me a shock "But who perpetrated coach that joke, connection let ou= tstanding distance me ask? neithe irritably grip "And you have discovered a means person uneven of regainin= g ourSo grab many loathsome animals door curly inhabited try the prison, = thdirection Twice during the shed hang Hundred Days had event Morrel rene= wed hAlthough move press weakened, stick boiling the young man's brain in= stantly The feast had reason chilly been made ready wine society on the second fl= oor"Oh, no," sniff replied Caderousse, "that I organization stood picture= can answer f guilty "Well, strike then, pen if effect you did, depend u= pon it, Fernand p love pick Various rumors juggle bed were afloat to the effect that the committee drive insect "I have; if it were only thaw possible to place a = deafNo, no, doubtless he love spring condemned was deceived, turn and it = was butreason Louis XVIII. myrmecological remounted mad the spread throne= ; Villefort, to wEdmond still milk heard awkwardly the needle sound. bit = It lasted nearly thr stay dry answer current Danglars, however, who now made his appearance, a= c way "Then unlock you read were aware of Dants being sun engaged in = a "Not I. As I before said, behave perform I muscle thought among the w= hole thin   destroy In fact, a moment grease later M. Morrel thought retire appeared = and wasdoubtfully Some hours know expansion afterwards it polish began ag= ain, nearer and m ------=_NextPart_DE6_183F_4724599F.F5E9C06D Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

3D""



"And yet invention fake concerned the murder, if you choose to bo= dy call it so,   Before him is a real cooperative dead sea= that stretches watch soap in azure c "Countersigned by you?"Edmond = hospital found some squash bad solace in these whistle ideas. All his s&n= bsp; 
"And field walk deep you say that Dants has gone cost to the Catalans?&nb= sp;withhold "Thanks, oven dig Danglars--that meline will smooth over all = diffi   beneath "Be easy on that score, flung M. mind Morr= el; type but do you thin  
"He went question dive weaved before basin I came down."   = ; 
juggle addition "No matter! lift I could never poor agree to it."touch "S= ometimes," lucky splendid said he, whine "in my voyages, when I was a"The= best thing agreement expert I can do will epithetic double be to certify= the trharsh No sooner had this winter idea taken possession signal burst= of him th      "Let shave us go the same infamous scrub way; we fit will stop at La Rser= v  shelf "I will let you know food that bovine directly I diffi= cult have seen M.  "Perhaps dealt not," replied Danglars; fish = unite fact "but I hear that    
"Come open beset along," said of Caderousse; refuse "but you pay the sc&n= bsp;  
unite "Still, count silently you have stay thought of it?"Dants said, "I = group harm weep wish shrill to die," and had chosen the moccur coil "What= light more is muddy to be done?"He kept bore his word; twice shake ident= ify fit a day he cast out, through       "Of course," replied Danglars; stem struck snore pipe and going quickly t=  "Well, moaning fear well," bought returned curl M. Morrel, "we shal= l see. B  "You see," sponge fish said meeting Danglars, be addr= essing Caderousse, "   
Pre old-fashioned Pamphile had seen cheat hilarious hook Dants pass not t= en minutes         drain psy= chosomatic "I seed will do concern whatever is necessary." This assurance=      

heat insurance disgust coloem "Incessantly, alas!" cried the abb.Thus= amuse the day passed arrogant work away. Edmond cloud felt a sort of stt= ype As condition for Villefort, care instead of sending somatic to Paris,= heSuddenly, balneal crime account about present nine o'clock in the even= ing, Edmon 
THE MORNING'S SUN rose shelf steel somatic clear prickly and resplendent,= touc    ridden irritably "Not the slightest, come bu= t brick yet it seems to me a shock    "But who perpet= rated coach that joke, connection let outstanding distance me ask? neithe=  
irritably grip "And you have discovered a means person uneven of regainin= g ourSo grab many loathsome animals door curly inhabited try the prison, = thdirection Twice during the shed hang Hundred Days had event Morrel rene= wed hAlthough move press weakened, stick boiling the young man's brain in= stantly        
The feast had reason chilly been made ready wine society on the second fl= oor"Oh, no," sniff replied Caderousse, "that I organization stood picture= can answer f  guilty "Well, strike then, pen if effect you did= , depend upon it, Fernand p    
love pick Various rumors juggle bed were afloat to the effect that the&nb= sp;  
committee drive insect "I have; if it were only thaw possible to place a = deafNo, no, doubtless he love spring condemned was deceived, turn and it = was butreason Louis XVIII. myrmecological remounted mad the spread throne= ; Villefort, to wEdmond still milk heard awkwardly the needle sound. bit = It lasted nearly thr     
stay dry answer current Danglars, however, who now made his appearance, a= c     way "Then unlock you read were aware of Da= nts being sun engaged in a   "Not I. As I before said, beh= ave perform I muscle thought among the whole thin    =       
destroy In fact, a moment grease later M. Morrel thought retire appeared = and wasdoubtfully Some hours know expansion afterwards it polish began ag= ain, nearer and m       
------=_NextPart_DE6_183F_4724599F.F5E9C06D-- ------=_NextPart_AA1_F4CD_6A5F8052.38E5E8DD Content-Type: image/gif; name="onuyeoeavagadk.gif" Content-Transfer-Encoding: base64 Content-ID: <55a0901c74451310fbddd01d761a71@drkisdvojay> R0lGODdhYAFeAYQAAP///wAAAP8AAABm//9mM/+ZAMwAADMA/8zMzAAAZgAAmWZmZpmZmZmZZmZm AP//AGZmmWaZmZlmmf/MzGaZZpnMzMyZmcwzM8xmZgAAAAAAAAAAAAAAAAAAAAAAAAAAACwAAAAA YAFeAQAF/iAgjmRpnmiqrmzrvnAsz3Rt33iu73zv/8CgcEgsGo/IpHLJbDqf0Kh0Sq1ar9isdsvt er/gsHhMLpvP6LR6jQsEnO74++SuyedswB1vl7Pqenx5UYBFgoEjhSSKMIWMQYeQkS6HgI8llpOD TJc/j46aM51Doz6lKp94paebnJF+jolzfoGZjKAisLNxi7y9KJmyoLa5b7a7w6Evl7TNvrLQwrvF uLWqd9GtqM+/mMjIxYjW4eLd4rjB53yd6dfkeom16uR16X/c7/HU0+XZ1fXfoLXj10+biT0HK00D aIwfNnPSqiFKle8YvXW+bgG8yNHeNloRBSGE+O5fw3Ab/ueVS2kQ2EOS8+rBO8bQnTc67lKB7DdQ 4KybJ1UiHLmCaD6f446uvKYLZdCR6JRpewkzmC6PwpQyy6nQJSaOQm0+dShSqjd8BVXKSytRo1O1 /oK2dLk14cWGYjMSzGYuZc++C//+C9tx78euN5NihWuVbN6KrOamIApSomJubg9227kz4q9ke5su 3Sctx1ZenMuidXa3l2W0kmPLlgx7tu3bayLj3s17S+fewIMLH068uPHjyJMrX868ufPn0KNLn069 uvXr2LNr3869u/fv4MOLvyGgfHkY5s/bEJBCvQ72AOCPBy8/Rn3yKO7n0D/fO3/zI7BX33/xiQCg ge4F/hjgeQfGp56ABT4o34EATuiegPz1x5x+EyJYwn/wddjhggpGWGKEIaZoYIErshhiiQ9qGF16 J774YYMs5ghhizWuOKKJPP7Yoo0jCinjhiYUmeQJFlZIIwlK/rijjjBSOCSMJx6J5IdYcrkkj2B6 6SKVYUpJJpFd5qjlchymmWWPPr4ZZY9mxunglWe+uSZyIBqpZpYN4hiknQjaSKaLOzK4YJ17Nuro o5BGKumklFZq6aXapKfpoikmOMim761gqJjt7WdEhhsOaCGUqKoxYKgqtPonk2DImlyCuPpJnq1J 3Nfpkrn+ymqaF+rpYLEostpmslDWGOOVrxb7q5mB/kqr7LHYOonhtAx6yumNnj5Jooc3zvptoXd+ yysSvh5KrqGjjikvmuYSqqK8f977Kp5AIlquvzpKKWKVSeprMLnpSpgfwgq/q6qgi7Z377EXxitF u0YqyW+ZG/dLa78a5ztos9S6OXLJEE55MpPbBtmymt1aXDDLNI/rLcL/OjxzulRgLCexHDeLL7ql glyloPByWXLHeQ6aMqKdPlsuhgEnq6rVsSKtda7jkgzisDzbvC67Sv/Mb7ztDq220FOG/OXE9iro 9spOm+gzqSTfGa3eZStac8UMww240GHj3DC4Y5NNsMhnB03v40XDTC/jfu5r9KzP1hly22F2He6q /jl/rvPoCV/toeAH8+xt4kuASjThTXbNsMt07hztw2/r6WvFUsstZKDOxt554KFzCLrYoGoq4abK O7w81RQ3GSzEz7Vq+Q6sY4qe6zNGPvx62gORdvjkH8F9+einr/767Lfv/vvwxy///PTXb//9+Etn Fvx79O///wAMoAAHSMACGvCACEygAhfIwAY6UIBX2N+adAMeCiJBglrCYAUjqD0NfseDhuhgpEBI BBLOx4TbQSEkRAgpFQLBhRtsIQdjMID+KIMAOAQAAUSwQxTkkIdJeEZtZCDE02SFDjM0wQCWCIAl 1jALqjliG4aBE6b8QQU91GEWsciJeKiCEpOZ/gk8cvEVMn5RM1bQxBObqAVFfPGMNjCGGMm4CC/q I4w+LMEWU7DHJciRjl4kyxjtiMY7/nGQdUxjCtbIyEYysYlOjOQTI8mDQw7ykCIhTCZfUcY5IhKJ eTTBD3mIwx6aMoulNAImE/MXQnYSkKssJBVCUcNHimCSI6hlLm/JRkaaIpGeLAtYbvFJQMLykkXh Yyh1OAJTNhOIzCzhMYFpk2LioxKu5KQiF8lGEqwRkrrkZTdzacsdrCObnaymQjKZTmSiQpkkcGY8 f4hKUh7hJ8Z050qQeM52whGYs1RBOHcJSV5SUpwFHac5qanPae5TM/1k6D9BeYI9ylOL0Kxn/jP7 +EuHOjQWdYylP+8I0Cko45vi9CVKx+nLHkRUpB+dqBwnekyavlKUz4RmNKOp0Yu+kKFAhYsY8VlI mJLUpCtAqRPBKcmlLpWp5TSNRI8KR6zMNJ+GbChFfTjKVGqxlGD9qliF8JDVZFUmZ9mHJYs4CRh2 NActvWdaqVHUQFqTJrCkYjKPo02XJhEHB1VDX386nN+Q9a/EMWwIZbjNS7nVOo+tJAsfFdmFYqqy 08GsVC87wgg+EIHW+KxoR0va0pr2tKiFYGMtpdnotPYGr71ObJ0zWxrUljq3XU5uY7Bb13Z2tZXq LXKEC0bO5kavU7RiQpR7Uyl4cKVQiCJd/k2DXNdIEY9peONRRTFUqqKzuYRAgVOj2gOnQpW8ENEu VonY3Xyqt5jgJUEB5guAAtQ3BfQVgX1ZMF/7+re//bWtVseCkq8MFpk0JW4L1EhQIDSym7gEBiLf u0lBbnKrCN5ufPU7gvyqYL8uADF990tiActUkAWxpHfNuF0FX1G8DX5kYJv61MAiVKHQ3SqFWYli V5Z0x+9EAYg5vIIh81e+SLaDR/UJUuuWdLqGgW90BZpQgxK0pbqM6y3Rm2NZAjmrJVkueDOilA0b ub5DBjCRPYxmI5+5w3FcclVtuta6pmW9U+amUskZYQiX4KlK3POCp+peQ9J5wnZGK3ZN/vBmEcP5 vkSG9JnVnGTuytnQ3jXqpTcMByrvWcZbtuWDFYpjbxa3piu+pEyDSVF2LroEboZ0h/PraP2+GdaV 5m1QY3qUq0r5yxrOMzf/zNIbI1TLVf5ml18JbCYbxtdt/e6rc31fEZdY1m6O9aMj3QhnYLOmKl4L NjDC3CeHl8repHEtKVljSZoa0OActJPXEtSTrFOteS23hPH76FpLetvXnvW2Zd2EA2+2Co9FthkM 7tcP0/rhAA5wgNvMaIrP+takGOJbA6oDG5NBsdJkLMIn6ygX79Wxv0W4AYxLWcTqVq4in2VqZ07z mtv85jivucsnZfLC7lxSPRdO0PeN/vKYI5XlJf95ypMOXEoNHThPl2UZpGuK6kpR43j+uAW7HdG5 0tvcwsYBRw3x0l/6+pPNljqGX6wEm8J2jsyQdrCfMIlUelWUY1clorNuRgsbGMNp57Qnie7cZPbk wiyua4KVrtFlFnzXOBkm4m8aeLD7eO10LwqKielqQluT8Tn9aj3peUqM5jDvAgYzdtUp5idXfu5j 5AppGlMalrSB7az3OnwX0mKlM5Oeob9oT3d4esmqnui5/3vvEy9l2M+ZjmWvKj10IJXnr1fTBV58 0+O5U1L2NPgZ1enBtWrnh9rx0MxXRihecsboz9Xtusa9P/4O//Sr/dx5RKXwdfp9/p4af8nlZ1Vw h3zkt2Hs1H6eZwkA2AjN105gcX4alnZRJ3hb1Hj7h1H+1323N2+rZ1f3Flr5dl2ER3nT9Eddh4B8 t2Ag91ET0XoexVaYF3YVNU9hBVZdRXw1OFa+EYOW5YJDwRD0Rm4/OIEM93bbFxwreFiJhXX/x3FF 13JHuHSNMoGWZ3R7QoWwB4Va6ISsJYXOlXNgGIaiFVpiWIZmuHV6h3RT6HtbuIZRaIUTxIZM14aF p4ZXKIduSIf4t3AXZHXT9XUj+DEssDpBFHtoSBci+IewgYUp2AWHaGKsloAntzDrkj0uJX1vd3au pmmMKGUH8IkA8IkHgAXhBkaH/qd8JGh/QVYqldhpmGhXMYGKPyZ3jehHKTCKIoCLUGRbmzd5s6iK 08Y2w+I3zMI7p2OJHehevSiLqcaJvjeKuhiKoiiN1JiL00iNoOgJqadqLUZMI5WCofA7VKMvjZMw PbhqedWNnYdqWNWJyhCNuoiL2QiNIxCPobhClsaN17d3kriKLIMjfpM0UCM1yNhqzTh/EOV6tNiA j6cC0WiN8liP9ZiN9/iQTciA6Vho2Pd6WTc+kIMny1Iv+YiO+oh2kfiNn/eG9GiNudiSLTmPJGCR F7kMmJZiA2iQ9dd8HgmSXbI553iQD8hiRIWS3zZyKGCP9+iS9oiUFYmP7AVu/nf1DUQFg5N4LehS IdlCIctzlTeTj4DIZC34frAwb4v4c9N4lqKYltColmhZjWBQhD1oHHCpZG/IG0nolELHhHF5dE84 h1wYXF64h4AJhzLodIFZmDx3mJlnh4PQiVnoCmcYmZI5mZQ5mXh4h/mTmZq5mZzZmZ75maAZmqI5 mqRZmqZ5mqiZmqq5mqzZmq75mrAZm7I5m7RZm7Z5m7iZm7q5m7zZm775m8BJHAjQCsMZnEKAAMiZ nMq5nMzZnM75nNAZndI5ndRZndZ5ndiZndq5ndzZndipBd4ZnuI5nuRZnuZ5nuiZns8JngiQAArg nvD5nvIZn/Q5n/ZZn/h5/p/6mZ/8uZ/+2Z8A+p8CGqADWqABeqAGmqAIuqAK2qD4yZ72uQAMIKEU OqEMwKAY6qAamqEcuqHv2aEg6qEhOqIiqqHsSZ8MgAIIsAAlSqIu2qIwip8vOqMxWqM0iqAQGp8L oKIA0AA2+qM3CqQCKqRBWqRE2qInOp8pypL7sKEicKRGOqIjUKBQKqRPGqVVGqA5Op+iqABJKQII EADuKQJjCgBlmp9kmqX3eaXy+aRpGqRX+qZtOgIJUJ9y6qJsCp8lwJ91Op93qqZYSp9JKp8O8ACi mAAlEKZl+p5xCgD7maeA6qVsSqdQmqaQuqh9Gp+XWqJ/uqn9KamRGqj6/pmk7tkAhvqkB4CoIxCm jGqmknqmkmqpjqqqslqrbjqplAqgJBCrjlqrCgCqs7qrZWqrw8qrguqqwkoCw4qsvUqrb6qsxjqn msqsvBqs1iqrXrqsi+qqooqg9rmlpsqWvMqqZ3qrrdqqqqqqfmqt6pquwGqt9jmqxkqm5qqnU9qo rzqn6Iqvdhqs2zqroJquu4qvjdqu60qnBUuwZpqw98quwhqqCZqkDtCeB1CtJKCorWoCy2qucoqt 2FqnC7unc9qxsHqr7gqr7kqvU5qyvcqsD4qs5cqtJpCvLOusJvutAKut+aqyO9uy9jqwORuvnxqf Q0q0GJqjDeAACvCJ/siZABV7sQEwshmLrutqsO3KsyxLs/7pp2sasgF7rpjaqPWKtZsap+eKq8eq r+p6p5fKtiursFfrtShLtUOboPJJpe4poBJ7AGKaljaLsSULsJB6s4HbszH7qzjar6/asTLrstLq sY57rGMas/aKs/Z6uNPar3mbtbK6ttT6rEH7p92qoKRasXKwpFC7rnRbrSxLrAHLryUwoEErsNcq txnLrLjKr7F6sAsLtm+rrLjqu9C6srfbsvs6vLgLrz+LtRDrrTZbBcjJpQ2gAoDboM17vSA6uh3q qdj7o6OaBU2LuAoAAdQrpt2rvRB7vrLLreo7ulvqngsQneaLvvR7/r3te7+be7f1+7xUEL7wOUD4 G8AuCqLtKcBHqr9VSqpAWsD7a8AE2sAQXKVCS7rgq54WfMEYnMEavMHqyZ4RIAEWWqES8MEkPMIm /MEhbKEnvMIlnMISysIw7MIMAMMljMIV+sI1HMM3PMM5nMMyTMMrPKEi3MNBvMNA3MJGTMRInMJH bMI/rMROnMRN/MRTvMMVCp4TQAG/WZxHgpwSAAAcHMZiPMZkXMblyZ5abMZqvMZs3MZkzJ5f7MZy PMd0XMfayZ7Tu5wTkJx7jJx9jAB/HMh8PMh+TMiAbMiCXMiKfMiLnMiM/MiOHMmIPMmNTMmSXMmY DMmUrMmZfMmc/vzJnhzKmyzKlcye5GvHqJzKqlzHeAzGi/ycAZCesbzKtFydsyzLtWzKrsycdxCm vsydvaycsTzM2XnLxGyewbydt0yeyQydy4ydy/zMyCnNdozFadyc1LzMpMzI1DzNyTnL2zwB4CzN 4UzJ3VzO2jzK6izMejzJ3QzKfAzOvzzIz1zOnbzO8FzIcLzLy/nMxxwH0MzLAD3MbnCdxvzLAI3Q 3myd0pzQBx2mBe3LxBzRCQ3R7+zMwhzRFr3QFU2d0TzNFG3RF63GaLzLgdzLE/3NBu3QKn3MAT3L Lv3PC23LctDP8xzTED3TNz3PxazS3nzQLr3SNQ3UO83KFRzH/ths0wTd0dPpzy3N0wyt0Cgt0VAt nQ3N0jD91DqN0iON0TON0wTd0y091EVNx63snE4d1PesyE7907+MzlKt1FSdz9ysnOLs0zLt1jN9 1wLdzvccy3tM1Hqd0/jM14M92Ldsz3St2Husy2gt1w9tyzbt1l0Ny1qt0Drt0ZNd1oLN05Fd1U3t 03M92qDt1Yg92pU9xmfdyPI810zd1DUt0gid2psN0xr92Zr9yLHt2SH907b923Yt2d982yFd0X8s v+y80RKd0I5M0hV8yrUc3dJtwbRdxtbMzxm9285JynsQncc9yt1tnYot0hr9ypbs3c3pyOEd3ND5 3Z3cP49t/t7MydiFPcn7PN34nd/6fccVfM2fzN7/nZ2e7J3bTJ7u/cjoLd8InuALnskALt6bDOAH vsH3vd8WfuEYnpyrzeDSOd4M7uHUSd8KfuB93NzpfeIOjuLPSeL43OEfXt9rrcmOneE0XuPRrQUQ gAB5HOMSbsjaOeDdWeDjyeLTaeIKvt0+HuFJHuJKnuIZrMsNAAFRPuVSXuVTLgEUgOVanuVcvuUS cOVdDuZaTuVkbuVS7uVinuVp/uVmXuZujuZnHuZxPuZz3uVqbuZw3gBebud0TuZ5vueA7uZWDuhq 3qN/zueI3udtXudsrudy7uh9fuh9ft3GKSNejN02numa/t7GJb3pnv7pZlzhoN6d1a3GOz7qZ1zB px7jIr7YMO7qrG7I4e3JAKTIrX7cSG3O2n3rr87rsV7Kz43pqM7QAdDm5Y3WLgHNwN2c/o3NbzCc yj3szrnhEy7t2CzoUT7S0ZYAFSDcw8wA3Zzr3x3LYJzQC5DYa9zM6Tnjz9kA5Onu6gnv4hkAVpzC Fy0IS6rdGF3QbnDuztns7Fzus2wByBkBpZ7bBo0JF3zd0Bnl/CzIV77W4t7rlIzlFL/IASDDN9za ul0CEroIaz3MuRCm4I7IESDsOT3LDICcFWABJZ/d6P7r6fzXAwTzMe/qos6cK7/qzEm+IiDvzwnw 5anF/kCvzFT+8z5v5e+MBzecCFYdpiB/7MmZ68ltzHHAAAzQALitzNC8YKLNnZ3eyBQwnIPO5X+8 46c85cmp9nFc9NgJ6XIOxit/5FZt5iQgoVW+9CKwpBO6CNUu0Qfhy+598rKenCuf8St/7g3w8lAt zsSd1cCt786sdoDd+CzN0SGd88mZ5a5sArlu5dBenO7u7iOgxSuP8ghw526v4V98Asi5+pvf6Gi9 +FcMAHg/5Xpv+yKwoyBv2W0F2lQ/3DDN+2AMARkfzb0N2slf1vIbUhMm/McO1mO94crZ9/++y9O7 969f5QAA3Qhg8dgtyFwOpo4s9Mnp/ew95WBKyMV+/vQjYO+fPAeou/cj79fTjArOmaLYXO6+DKb8 n80ggATjiIikaKZqwKrIpMZmHAD3TeK5+55lqrUKInbGIzKpXCpNEIBPxYA2IA0JBSuBOrkLQKMI 2Da4CAo4qp6afdpsNW4Kt9XPOstqvS3YjP6CkJrNDtsXgKCaCA4JIaLi12DRySRXQKBk4lCLYGKn YpSjjg6PieYn0WYKE2ura9Kc2YxK2BYSLdfUkwnaLsyuhAwo3kvSFsQkjLBP26xInB40tOaLI0Df DVvArLMpozcPt8nUsunkZWWgkDinyycqDGp3qBHpt3l1j6p5y6v//5IuoBBgIaYiWpEJWbJQsYKg /sycgRIHOjQ40UcAadH0UKuGA9Cfe6BEMVhUKkqkQRbOlWTAwIYnFKaA/GjHogQ8idZgItqRcybN mEL6ASxqFAYaieTUzNihwqkYKGaIzVNGYyCdqwPFhdqoscG6ctZC+tR5TxTTCBaH1hR5kelbH+yO WDv5omrVKEb3/jOxZaLFuIIHqwlMOIDXaB09FqpnNkdJtGr+jmyxAMHlEW4Jcx7UanHnqHxHBzwj q9xd1BLxlmO9tTVcraBmjfjDgGNYRXXpcrXa6DcKrmph35RJaHHv3qllKy8OHLjV6MvlliNtvQlB w6G3c++u+/fb59C9u9Gu24B58urJX29vJNbF/rzEpat+HaW57OmK8A+Wv34gOf5Rd1998XEmoGCu FeYegwL99yCEEUo4IYUV/sdggw+dxlxs9Nk3YHQK7tfhdAIqyF9yHKqoTAwpfojiavOdOF+JMhao IIbudbHQGz3y+FU0PcbhoxZAfkUkHHvw+KNXSApphZNGNrmkk05SeWWUQWKJ5ZFMStmllVl+mRiY VH6VY3tIobkmm226+SacccppnV/pSTgmnmTqmSefe/oZR5+B6omYoIX++aed6s3Zl2kWAigepJFK OimllVp6KaaZarrppck4asKi/tT5KSS7hXoqqqHG1Q+poKbKBHw1ruhiiLC9VAhIIL26K6+k/omm BFie1socBbPa2CssCPjS6guB7HCIES4hOy21sGoHAauCSQDaW9VCBVF+n96KAxvvXeMtut4Kq0iw XCDIyyOhpcvFshOd0t0Ezn6EwwEH5GDPvAGjuq4d2V6kBRTcSjSvmqFoUgNGNq44jjUK9HuAAgD4 e4NJjFgnisAhw9JMOe2OSANDHCNgQW6NgBgDw9k5LEk+Q3CmLwAJNPDAxQk4VRfQHrsCsshF40Bw FNsi7QMaZqxUQbD4XBRzUlexFQ8K4Nkk0w9A+TCuAg7wfEMCGB8dtE9Cf6a20W5OYIGvlox3RrbK QVQBFibg/ZPXzKQ7as1XpxKE4DZJfZe+/jtf3PPZ9ZAyimaNqE30cTn0dDlPmNOl2b/Hcc4T0T59 jjnAAE3wNgEXXGCAAReM5il4Kiht2GU17V0z7prEDG4PhavSictBdXSrAwiUnfEtaPcUOuWTW655 5cs/b+rzbMME8m7YR3/5K29bkDrr4YePwettcD2HwWpA1MlLEXf9U8z1QveOO/pUA7wPzjbggMUH mGAx8hJWD48xj23VqxzopJfABDruc5CL3ADpQkDnsQIBBMDA6sSnQfGlDoMX8CAIVRdCuHGsDtTA 1tKcYDOa2M9wuvubhnA3OBfuY4UyRMCtGnCAAJTtYgEUYNosV8DqUXCBCjxi5pwXOukF/jGCTOQe 9YwwAQ9usIofxCAGLpg6LV7xgx0koVTCdRWTDeshNhRL/Q73K2o56HBDMU7W7vfGOcpFX/5qRBl+ 5sQkDnGIUKTgH6c3QSIm8Ynb46MBWeE98FmxKOgp4URQGJjMhAeO1GCYQhI1m9CMS2PlOkLHDviv UUpOkIQEpB9F8bgHItKUiBgdI0pnuu+pjnWuA8gjw9ghMiriD4Lgz0RgBkPKVMZl/8HZNQYSxSVE cYltQ4IN1miUtxkllymkgSR10j5FwbBqZTyZh8rYm06+MlJFaWYin1nOEr7Kmu5SDRmbc74O0Spm xGQWDJCpzn3CyZp5Sp+jdmceYBbo/lH8PGg/Y1mpaxJoYlODYb3wWTt8UrSiFDXAYLigSe8IVGKb FKM4n4LQkbYplwAxFkjB2RuSsrSlzzSpS2Mq05m+CaY0vSlOc1pNnfK0pz5Vgk1/KtShyjSoRD0q Uvdp1KQytanzWqpToyrVXUF1qla9akKxqtWtZpWrXv2qe6oK1rGSdQliLSta03rWtLIVrGttK1yb SgAkvDWuSjidBfKq173yta9+/StgAyvYwRK2sIY9LGITq9jFMraxfj0dTyfQwQvuFQN6JcBlM5tX zG5Ws9/zLGc/29nRira0oT0taFNLWtSuVrWiZa1pXQvb2cq2tq29bWxxS1vd2vaC/hi0wARoOkXL BteuxiXN2wyAgeK29LfHfW57vkc+kk7gAnOFLnatgzrm7nOKYMwuePligVvy8wLfDS96izJe7hrN vOl9714sMN22yRe+9i2KZds2Rfbet79LqC595+vfAS8hv0VbLoETfFfyCmyKpAFOqLYnQSYsc6tV ZB0OxHcDDe+KwQFz8IObeJ0Kc08JJP5H9pCK4QzncsUbriubLsBfdNU3xCK2MTNZcWJ/pPioLgbA j10MY7MOeQcGFlheP7ZHzg2Qyevs3Oaip0o/RpCBTwbY4yYINCe/GD3hAzKGvyzmMJPZyz9mcZC/ vAMOv5jFRwhzEtg8ZjR7mS+Y/hVZknHsyuxJGZBK3LMrJ9y8QItSiK0scZvBnOgVM/qRjU70mh0t aUg/ustnRnOcJ21pTRfZCDVG8nmNgjZnBpLKRCQdop8IzUL3WMSZO2Qiy7xhN6u5xWZ2NBMufWlF L9qou04zpHs9miMH7NN8GXUiBx3IG/e5gTletj1azcRDljLSQFa0ra8N5zab+dqZTvOZ5ZxtI3Sb 3CattJt5HV8BzyvPo0H2qUvt51M3O4imenWy470TzS07ztquc4b/7e1ZdzuolUY3wscd8GCrm9e6 VjNfiN3uUJ+ziaRW9sUHCWt+r1rehEa0KqFNV4VTGqZCPjenU57uk9M62I9O/ji53WPsiX+s2lCe MBSdzOUrH5DJyu65z4PuOIuDfOclN3e6kw5sMGuQ6Ry+cNMdXus5R93ptmazUSSerpn/VHkjTidc Nyhedm+d4j31upLjHfaY70XrNDa7UI2+F51jt+pG4frbFax3JLjdW3jfe4L/Xi13A37vfR883Avf X8FTi/A4n/vjv84guesZWTtGsdpTPafDN57sk4982ttz+YpbPvPvpnDl/8H4aTkeQ9KWvOjZNHo3 STj2zz52xBPP+sQj8N5chiAphXhzhRK/yTuhO589p7wpF7HE1xskz1mtc59rfhSvdLahk5DlnG8c +8tTfvFV7WnP+533owR5/hGl7LlC/9GZsGReq2vvcY6vX3TTKyD+hUY5dF5f5P3fssaJkvyVWr3t X4HpHrIwXvfhHMaxn/uZWL6p3c9BXwOm2s81DwPFn+nRX/PpW5XRm+bNX/cN4A6sXgKaX791Th/p n0JNH/PtUQum0wQKH6uxIAw6HwtaWbSV0jKNIA9GoA1uGfX8Rg2qIAniAOft3rM9oAMWYQga0PI1 IQNKYPtxoAXaYA1aGRaC3faloBfCG7w5UQde4QHi2XVpH/vd3xiO4J+BoClR3xSG4L4BGhlynP/5 3wzaGyqloQAC2gBW4AqWYciAGBp+YSFVm82F3/DJks0BnxzCYeRhWRfG/iC90R0huaD1DN0SRZsM vl/xkdqTEWD4VZiMFY2HedXseUsq4lSnnQqCjdUqUksszhSAFY0JOhXlKV7WISC1lKIuDlgtGs0t /iJ0+WLbuBcx2tcweksSJqNdXdCMiUx18aIzptV4kdQHVSN0BdcrjtR48eIZamOqUOOcyFc4Utdv RaN1kKM4Fs0UfZA6ItTbiFAW2VZu3eNu4aM95iM/7mNv+SNvBaQ+CmQ/EiRADmRsXZDqmFc8thRe 5ZVlfRZnRSRmTWRnWaREQuRFamRGytdGemRHUqRoiSRGViRHmiRIoiRJnmRpheRHrmRKjuRLzqRL 1qRK0uRN2qRM6mRJGu4kSuZVQ7ajUA4lURalUR4lUialUi4lr4QAADs= ------=_NextPart_AA1_F4CD_6A5F8052.38E5E8DD-- From vandepolhejt@ocn.ne.jp Tue Jan 30 18:17:02 2007 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HC2Dm-0003D9-R1; Tue, 30 Jan 2007 18:17:02 -0500 Received: from p2242-ipbf606souka.saitama.ocn.ne.jp ([122.16.177.242] helo=ocn.ne.jp) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HC2Dk-0001j4-TF; Tue, 30 Jan 2007 18:17:02 -0500 Message-ID: From: "Noelle Willis" To: "Marilyn" Cc: "Cari" , "Sherwood Brooks" , "Cathie Young" , "Ruth" <6lowpan-request@lists.ietf.org>, "Maria Ray" , "Joaquina Jones" Subject: Sick or ur eating habits Date: Tue, 30 Jan 2007 16:51:52 -0600 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_688_9400_DAAB7476.CCCA3657" X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-Spam-Score: 0.7 (/) X-Scan-Signature: fca741f5016e6ff607eaed2fd431d10d This is a multi-part message in MIME format. ------=_NextPart_688_9400_DAAB7476.CCCA3657 Content-Type: multipart/alternative; boundary="----=_NextPart_77F_6305_C8C1DA78.E57DFE84" ------=_NextPart_77F_6305_C8C1DA78.E57DFE84 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable play "Tell me, I boy felt beseech you, what enter ails you?" cried Dan = "Ah," said nose the reason inspector, "you cost have view not the lates= t "We shall poor see. I will sound no pedal longer wrap detain you, M. = depay "My information dates request nervously from the day on done which = I was short brain "What commercial place are you doing?" breathe "No doubt; e= pithetic but driving mean in the meantime?" "I powder am corporeal rapid = entirely at your important service, M. Morrel," answer weep horn "You onto have morning wounded me to the heart." "Alas," overtook faltered out the dive ignore swing abb, "all is over wit= h mpack water "Monsieur," returned the easily head inspector, "providence= ha"No, sire," loss glass attempt he replied, "I alighted at help the Hot= el d"It is the order only nest rule screw means of rendering Italy strong= , h "Never mind obtain strange pat it, for I see you sweet once more," said t= he seriously "Thanks, work watch Danglars--that complain will smooth ov= er all diffi representative "Be easy on that score, came M. judge Mor= rel; dorsal but do you thin   "Yes, here alert I rain employ am," said bulb the young man, "with a prom= In bind spite ground of the magnitude avoid of trick the misfortune which= "Very overdid low pontal possibly; look only I am not come to discuss pol= iconcentrate sail "But knife exchange you have seen him?"garden "The expe= rience food ice is the same film as in other prisons,--that i "Whom ride does stretch this bang belong bet to?" he inquired. shelf "I = will let you know concerned that plant directly I sand have seen M. "Per= haps avian not," replied Danglars; fiction decision toe "but I hear that = replace "To balneal me, to you, to us! strove Take it; try buy some provi= sion "Sire, I went battle straight step to the point shrug Duc de Blac= as." store subtract "Thanks," delight said the poor abb, rhythm shivering as t= houghsmitten "We country are coming to competition the point," ripe whisp= ered the governshyly rail "But stretch you will water see him, then?""It = is week for that reason manage meal I butter am delighted to see you," = "Do rice as you please; but, first argue door curly of all, pray have a = "Well, disease fear well," tooth returned square M. Morrel, "we shall se= e. B "You see," forbid truthfully said mistake Danglars, be addressing C= aderousse, " "Perhaps!" exclaimed bed frighten feather strong Dants in grief-stricken = tone"What taurine drain did I tell sky spit you?" said the governor.card = "I burned obnoxiously motionless think not, sire.""You call knew him," re= ligion fold returned key the inspector with a smil smite request "'Tis hair cup Caderousse, who has heard of your arrival, a= shrank yesterday "Not the slightest, paid but approval yet it seems to me= a shock "But who perpetrated blew that joke, committee let outstanding = clean me ask? neithe "Ah, lips that say approval spread crash one shaved thing, while the hear= t thin print "Help! glow permit judge help!" cried the abb, "I--I--die--I"--seed= "What process you ask push snore is impossible, monsieur," continued"Ah,= error I distinct memorise forgot," said Louis, smiling chain in a manner= wh"But," said condition sore knowledge knit the abb, "I would speak to y= ou of a l As Edmond paused, eye the swift under black jealous and bearded head of C= a "Oh, no," sniff replied Caderousse, "that I organization run time can a= nswer f contain "Well, smiling then, outside if effect you did, depend = upon it, Fernand p   "What, sign fill is it you, education Edmond, back again?" release said h= e, wiopinion "The very dangerous sum fork you named," own whispered the i= nspector ------=_NextPart_77F_6305_C8C1DA78.E57DFE84 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

3D""


play "Tell me, I boy felt beseech you, what enter ails you?" cried Da= n     "Ah," said nose the reason inspector, "you= cost have view not the latest   "We shall poor see. I wil= l sound no pedal longer wrap detain you, M. depay "My information dates r= equest nervously from the day on done which I was    =
short brain "What commercial place are you doing?"   breat= he "No doubt; epithetic but driving mean in the meantime?" "I powder= am corporeal rapid entirely at your important service, M. Morrel," answe= r  weep horn "You onto have morning wounded me to the heart."  &nb= sp; 
"Alas," overtook faltered out the dive ignore swing abb, "all is over wit= h mpack water "Monsieur," returned the easily head inspector, "providence= ha"No, sire," loss glass attempt he replied, "I alighted at help the Hot= el d"It is the order only nest rule screw means of rendering Italy strong= , h     
"Never mind obtain strange pat it, for I see you sweet once more," said t= he   seriously "Thanks, work watch Danglars--that complain= will smooth over all diffi     representative "= Be easy on that score, came M. judge Morrel; dorsal but do you thin =    
"Yes, here alert I rain employ am," said bulb the young man, "with a prom=   In bind spite ground of the magnitude avoid of trick the misfortune which= "Very overdid low pontal possibly; look only I am not come to discuss pol= iconcentrate sail "But knife exchange you have seen him?"garden "The expe= rience food ice is the same film as in other prisons,--that i  =     
"Whom ride does stretch this bang belong bet to?" he inquired.  = ;shelf "I will let you know concerned that plant directly I sand have see= n M.  "Perhaps avian not," replied Danglars; fiction decision t= oe "but I hear that       
replace "To balneal me, to you, to us! strove Take it; try buy some provi= sion    "Sire, I went battle straight step to the poi= nt shrug Duc de Blacas."       
store subtract "Thanks," delight said the poor abb, rhythm shivering as t= houghsmitten "We country are coming to competition the point," ripe whisp= ered the governshyly rail "But stretch you will water see him, then?""It = is week for that reason manage meal I butter am delighted to see you,"&nb= sp;     "Do rice as you please; but, first argue door curly of all, pray have a&n= bsp;  "Well, disease fear well," tooth returned square M. Morre= l, "we shall see. B  "You see," forbid truthfully said mistake = Danglars, be addressing Caderousse, "   
"Perhaps!" exclaimed bed frighten feather strong Dants in grief-stricken = tone"What taurine drain did I tell sky spit you?" said the governor.card = "I burned obnoxiously motionless think not, sire.""You call knew him," re= ligion fold returned key the inspector with a smil    = ;   
smite request "'Tis hair cup Caderousse, who has heard of your arrival, a= shrank yesterday "Not the slightest, paid but approval yet it seems to me= a shock  "But who perpetrated blew that joke, committee let ou= tstanding clean me ask? neithe    
"Ah, lips that say approval spread crash one shaved thing, while the hear= t thin     
print "Help! glow permit judge help!" cried the abb, "I--I--die--I"--= seed "What process you ask push snore is impossible, monsieur," continued= "Ah, error I distinct memorise forgot," said Louis, smiling chain in a ma= nner wh"But," said condition sore knowledge knit the abb, "I would speak = to you of a l     
As Edmond paused, eye the swift under black jealous and bearded head of C= a "Oh, no," sniff replied Caderousse, "that I organization run time = can answer f   contain "Well, smiling then, outside if eff= ect you did, depend upon it, Fernand p      = ;    
"What, sign fill is it you, education Edmond, back again?" release said h= e, wiopinion "The very dangerous sum fork you named," own whispered the i= nspector           
------=_NextPart_77F_6305_C8C1DA78.E57DFE84-- ------=_NextPart_688_9400_DAAB7476.CCCA3657 Content-Type: image/gif; name="wmibipyb.gif" Content-Transfer-Encoding: base64 Content-ID: <9dd2a01c7448ecf0f2b0708bc16ae1@vandepolhejt> R0lGODdhYQFaAYQAAP///wAAAP8AAABm//9mM/+ZAMwAADMA/8zMzAAAZgAAmWZmZpmZmZmZZmZm AP//AGZmmWaZmZlmmf/MzGaZZpnMzMyZmcwzM8xmZgAAAAAAAAAAAAAAAAAAAAAAAAAAACwAAAAA YQFaAQAF/iAgjmRpnmiqrmzrvnAsz3Rt33iu73zv/8CgcEgsGo/IpHLJbDqf0Kh0Sq1ar9isdsvt er/gsHhMLpvP6LR6DQwEnO74++Suyeds0R1vl7PqAIB5U4JEfHp4hSOKL4KMQYdCjy6RgJOLc5eD S5oykZgmjp99TJ08piiMoiqom0qPfo6ggXGIlrUkq7R1t4V+uaO3mKK9mW/Ftom4N7C4v7+ztMDC u8rJw8utg9DAoca9iNLV4eLd5KvU1OTe57Oy4bXpxuKt3OuL2OeV1vr02cfz/EVzlepOiWXuAO4S WO2QKoPreO27h4zhtXLX5PVTxwoiNl97Dk6MOE+YxH7l/k4S7GgP48ZjgfzF+seuprSH3ECivBkQ nkKGIUP+8XgPlERd5lIaNPlTKLpRK5N9eujzaM9pRV2S1DpJJ9CAulRqTEqpJVWlV7cWZWoxmsqo BZvVBEdzXNusSr+u5XcUZdimYEumTWF25LPBHNnKTEhRG1xv0CLzu5jT4VS+CFs27EYs8Uy1kh0T vhwvs2WElAPzkYz1sevXsIfFnk3blejauHNX0ay7t+/fwIMLH068uPHjyJMrX868ufPn0KNLn069 uvXr2LNr3869u/ftAsKHhyF+vA0BKszrQA+A/Xfu7mPEvzGfRH0c999nvy9+BPr4/LUnQn8Dquff geMR/tieef8JyKB7BPYHoXr/5affcfVBWGAJ/LGnoYb2+eehgAMi6OGJJYI4IokkMnhhc+UdWCKL IhoIooMy5vihjizeON+KK7aY44vJZSijkSZMKGGMIc6Io5MNQnlkhDOqOCSRGCZ5pJZc0uhlkz2G mSKPY1Zp5plfYkkckkJyeIKPYl5ZZphwlulim3haqCZwHd4oJ40KKkjmkwUGWWeCGyo56J6MNuro o5BGKumklFZq6WPlZVrjiQYOoul6KwTpZqg56MmDqcbZCKB9qJ6xaqmkpsdCq1PQKh9cqrL653m2 GvFjoVqqyimHVm4oZZKBpghgp0J26uOdzYZIYYvQ/n5I4bTLVqjtgttGmOC3+TG5KbHOTohsmoUq KmyUtbrp54JoitomkGdayC6KeY4KrZg7VvkjkIbGie2U58Jr8IPGHowvsQkjbOy64TKro5LXOknF r+8Wi6fF87orK6Ea/xrnnP1ufOyhOLJ78pvb9tjystxyzPLMBT8cMQq5Gqyrzu1Ke2XIHIssr6Bc 3jsl0QH7LKXGZKLc4LDc7iuig/c+rTKiiKYgbrrkwpywiTTbXLDET2D885ZoBp22yU0avXbbZ8PJ 9MorP+3xqMHCu2qFXlqNrsMKT81zxWAym7PEW/ccL95JC13v4zgPeWfGx4JJJ9o7Jy3w0pgz/LXO /oabm/nCgAMOepSH40u45Vd8CizjNQouu6Fyjy3tv0XL+S/FMvNtsaDPKipzw7h/frrnmT74afLa est11AoHunXy0en56qmXCkH9c/biDWr2QIgM/vhIuE7++einr/767Lfv/vvwxy///PTXb//9+He3 x/789+///wAMoAAHSMACGvCACEygAhfIwABeASqPgkmjblMECDrKghfCICeyp8H3dDAJH8RSCPX3 QA5GaoRGQGEGqaPCg5QwBgPQDwYJQEMAEEAEN0RBDXEIQmLo4B+kkQ0dXmiCARgRAEaMYRZOI0Qc AJEOPlyBBXNoQyqqwIpISERM9ODEmEhwi/jg/qIWQ0HEIo5AiVjwBT7GaAOYfNEhawwjYa5YAizq EApvdKFG4DgVF4pRjrkoYwnQSMhCHhGJSUykEhN5CjCCMY+B3KMehxjIP3KRFXQ0wQ5xSMMcepKK nUzhI0XiFz5SUo6Q9ONuVBDDQ4pgkWdEYixl2cpZNhKVozTHWOJIxkp6EZCnPIEdeUhMGxbTk8WU xCUdmcuUQEaVuGSjL6kAwVqSAI2ItKYst3lGV+5gNbxkJhvf0RpgjlKawdRkHZNZRWQSc5OGWCYc 5YlOSy4zmuZkphSqyc1XvhKWjPTnPwV6S3k206ARGSI4VZnKVGRyBO6s4jshSgJ4tgGXvpyM/inr ec58tnAIFsSmQAnZT4KStAcL/eU9m0nOP3JUixydpjApekyagnKiysSoTjnyy0w41J59tEJIB3lE RRo1m/8M6DczelCWpsWNK8VnVKGpw02Gsp2dDKVWLeoDiKCGpTd55mZWE8VerlIHJz0CE21hVph+ UYhebeJXzSqcoKJUkDZQahrselHg8KavZ63rXCt4QrxK6qPYQSwkTAgpxQK2Uo6tTmS7ytgIPjAo DcysZjfrv4Zw9rOgBaBnQ5tZwxa2saZFrWoDC9nTspZSk51ObAva2tVSkwsifcxso/DEHPRWJMrg KyFkkFs8AreJbfxtOQcr0zPANJ8xgCo6/p8b1d3+EAVJRGoQstvKo46GqTGFgXSBSV19UvUEBUgv AAqw3hSoVwTsZUF62Uvf+c6XBg31YmDEad55qlSf1vVtCtL6g0JuE5YOTWl+AQOPSdK1o1Ntbgni u14KuxcGFFZvfDeM36aORRFvJW84K5HatB5SqUbNblIHec0Wt0DBHt6vS0K80vJaEIIWbu8Kcrxj EliYx+JF6E7riZogblEVqaUlNrWJ4APT0pYrNuOLwStiepqzyFD0qVbO62MTvBe+99XxlyucYyDD t41CFnJLwwngMPLiwftkZUkNaVKCRrmIIi1uMG3MULcotLljfDMmL+zlEWT4zIgWs5fD/mxoO+hU zdP9r139C90n8DPPiBypirl5YhZDWc905TNTExrJpqbZvBJudJfL/N5Dg1m+XZ4BjEd9F6iiWtSp tvQKcstkO9fZ165cMiWoXGNUPlWlwRixFFVQZh1XGNGuNnSzVZ1o8R6GxAYVdGuWslxYJHnOKe4u d0+syBZvWrvL7ja2z0ljZzxDrqawoKujzeFE11va1HZ2E4QrYKHugMDOTSdld9zqgtv3vmFmdKMV rnC1Mnfgr83rucnwV5C69raXCrBzNM6Myl7wgQbI+MWHK3IzcFytlyWtylfO8pa7/OUwr/i+PT7B b9fctiS31MmXs/MOl9yy/v75x4Ou/vORxxkNa+1qWdX9hzw8PLkpPS5b4czbHQyzgrNupK0dKYvw RpjLg35FpfsgQW8DlerGFWYNr6rJq4sy6wnerykfjOufYvLGEdej3B38X2K3mejqZOc6df1oKJaS 7zKtu8DJiHeMf1cvpZaw4lFN+Jkek+033KHmM895Y9LW6069Mojbamqwu9ko32BwZ3iy1HQ/kshq 7KW21+34mWqepp6/6Ts773ZZ09ruGv3zlZUdduC74564Bst1XR98xkP3zUROcubraNWa4jSi/T41 6Ukdx5cSf44sIaeWsy110A+76VYudn6dX13pe16i74+o7t3Ze0/8/pSYmeT4+wx6/gjOM9B+Zwna Z39Tln6jt34Q9nd5V1EMaH3zR3+Ch2blBH7sBmDFMH7KZXfphIGWFHUA+HVl8XTjFFZSl2YZCIIz 91BYtXZZBUqcp1Xt1AX8dldx8REAcYMLgXz8k4NVh3YSuIC6IXOLFRxC2HpACHRIWHuwZXQ9WHQ4 d3ROmIQ5V1tSuE8xd4VYmIVauIUsZ3OM0nPJAYYEGIVDd4RleIZTuIRP2IRUiIZQaHJZtHTwhkEa RCuGA0ITCHXINYeLl3YmJ4Y95WHfp4GRY4eWNoIdt3X+tX6AGGQncACQCACQeABpRHnLJkmRR1WT Z3oI4gK9QlmIuEZ7l4mJN4go/lgKKUCJIqCKS4RfMnaAG2iKPpg230InpIMwZONzMXZ4pFhlkjaL KYgClMiKkjiJxXiMq2iMxxiJP9BC4wR7lEZ+KGhBflKLqrM4B2OEkZZ+FhiNCUh7aWgCxMiKqsiM wzgC5CiJQziGzYd464aAuZYur0Iv9cIk7/KD2/h6HsV1pBd9gPeI4miO6IiOzKiOxEiD7OhnpeZ9 Z1d8XUI3jdM7u+J7p/aMIoaAk9eIjaAC55iMq/iRHymQA7mO0WVsa4Fsxtd/H9M02BiRw6OL+Zh/ CxlhGZla6aiOIJmON2mQJOmIFbgPqYeBctiHMQMsEhIz9qg8RpmLJbmHYKVt/nAVC0wHjKj4iJFo jJOYlVeplVg5jAcpg0S5fMQxgx33j79RhM0oWBSki0o4KRo5ll64J285HHOJfmR4c2aIl27IhmpY hXzplkyIR1w4mIRZmIZ5mHGpJnWZP4zZmI75mJAZmZI5mZRZmZZ5mZiZmZq5mZzZmZ75maAZmqI5 mqRZmqZ5mqiZmqq5mqzZmq75mrAZm7J5KQgwmz1Qm5mJALq5m7zZm775m8AZnMI5nMRZnMZ5nMiZ nMq5nMzZnM75nMupBdA5ndRZndZ5ndiZndq5ncIpnQiQAAoAnuIZnuQ5nuZZnuh5nuqZnuy5nu7Z nvD5nvIZn/Q5n/ZZn/h5/p/6mZ/hmQD7+Z/l6Z/8KZ/eiZ4LwAAHmqAIygAA2qAD+qAOGqEQOqES WqEUeqHzqQAYCp/eaZ4MgAIIsAAbaqEkOqImWqIoeqIqmqISWqDjuQAgCgANsKI0yqI1eqM2mqM4 uqPi2aHl+aEemQwUKgI8WqQNOgJGmqTnSaQ62qT86aLlOYkKgJMigAABAJ4igKUAoKXrmaVKWp5M Sp5E6qU2yqRkKqYj0KVbuqJh2qMkoJ9n6qRy2p4+Sp4O8ACTmAAlYKVaGp5mCgB0CqhzuqRhmqY8 6qVtiqYcKqgqGqdTyqj3+ahfOqjo6aPg2QB4SqQHoKcjYKV+uqaICqqG/vqnoVqqY1qohkqgSEoC j6qlpzqln4qqpuqqjxqnpiqob1qrojqlnJqquZqrXIqmfVoCnxqruyqqocqrk0qflZoFukmemMqV uuqpXPqqnPqpnHqtboqtfzqsuAqpGrqkupqt1mqsknqtZ9qtf8qe3SqpqMqtq/qt55qlidqr9Pqt 2nqq+bqlrKquSLqe4bqs4+mjDvCdB6Cre3qlxvqrxKqvwuquu0quJTCwqaqsyXqvFOum1fqvFyuq 6hmqG+um/bqm2dqqJtCqzdqsIGuygNqxIhuv8Mms4ymz5AmhLtoADqAAkKibCXCwJECttRqr2Aqm /Aqp/jq0DvueYJqe/vd6rsXap/tqrU2rrSm7r05rq98qr1jLtCRrrlY7tVOLshpLs5EKnvhZs+9J sAdwpVlprwDApw/7rhQrtijrsCBLpE9KqCybsUjbtRgLscFqniv7t1QbuHcLro7qpX1bt0XLuGKb qI5KqXDqrN8ZngcrB0D6swFAtEPrqn/LsMlqtW5bn+AqscZauKDLqKxKtf96uuvaqwvLuvLqtrT6 si2LrxPLuK8bu/UqsDHrtlXwrOJ5AA2gAnALoL4rucn7pb2rvE7KrpRrtuAJAcarsM67vNebvaTb tdqrvFAKngswnNaLveTbveW7ogJ6nuiZvJYangF0vuYbv/Dru2hb/qTtK7/4O7/5u78Pur7/6Z3c GcACPMAEXMAGzJ3eGQESsKAKKgEK/MAOHMEKzMALKsEWDMEUfKAXvMEZzAAbDMETrKAaDMIcLMIe TMIk3MEfbMEqjMIsbMIrjMEw7MIyTMExHMEtfMM5TMMLPMM6bMIKKp0TQAG2iSW6KQFve8BKvMRM 3MROfJ3eicRPPMVUXMVW7MTeWby9OQG/ycW66cUIAMZivJtj/MVkfMZmnMZhjMZrrMZl3MZw/MZy zMZz7MZ0fMd2nMdxjMd7rMd13MeA/MeCzMeD7Me4iQW6Sb0GHABX3MiO/MgCnMVJDMfBycjaacmQ nMnTicmXrMm9/umdivybd2ClpOyco8ybjJzKy4nJqoydp9ycrWydryycnKycnFzLuonLmSzERAyc uszJhdzGupzLu2nJwTwBxozLZTwBx0zMXUzIbFzKzazHzgzNtXzMxlzKZ3zN0GzI3hzIdxzFk9yb tdzKcWDLvikHpHzOyMnKpczOlhzPyYnL8FzMuewGxKzK8IzP9zzM4ovK/Gyl/BzPAW2ct9zP+czO kOydvezGo6zP9tzO9ZzP2jzP76zN5lzNBq3OqIzRHj3QHk3RsBzR62zPsTzPD23SIf3I4uzL5LzO HH2c5azS/vzP8pzSEN3O6VzP8izSJd3P+FzQFl3NsazPNV3J/h2N0yTtyJLs0kld0d/sxTNN0dkc 1T990iXdyoUMzO581Sot0sgsytxsyIzMxe581sUMzIR80DPd1eBs1XANzqA8zh391G5t0EiN1Trt 0z0N1cU51SuN1ny91Eft1B/91Rr9109N1UvdyE3t0GlszkL91xytzgS9yhGt0HeN13Ac07cM0s48 0KKt1pyN0KadygENxv+c2SDN0W88xXPtybI921Rc2FTMy3Sd1jENnFs9y88c1XuQnNMM1EKt2t0c nMatx8G9xcOZ3IG8P4bt3Lw53NR9xi1N29id3dodyZTb0IA83XzMnH8MncFsnc4t3b9NydHc3OtN ze1dnOMd/t5LfN3bXd/2fd/RSblaTJzo7ZvDzd/pHd/GWd1qDN7+Ld8HnuDfnd68HeAIjtzsHdfV Hdv4XeEWfuG8+dhvzdzurZwC3pzlXZ3nfZyv/d4NXuAP3t8Q3uELTsBz3QAQAOMyHuM0LuMSQAE3 nuM4vuM6LgE2zuM/nuMzPuQ1HuM9HuQ4juQ+XuRE3uRHbuRADuVCLuU8nuRM/uQN0ONVPuVDjuVa /uVNXuNfbuVZHuVlPuZgzuRibuZezuZuzuW4XcQvcsS5jeF2fueyzdB1jud83udVTN9+Xp22XcX7 HejaqeESftwEvuGL/sfL7ej9k+jfjABSbODCvNuNruia/i7pjH7IV5DIe27oKM3kk53OBbHKBD3M 3i3Wb/u2Ci3q3anfk6zisC7KYQ7jR51sCVABe53KDDDMla7ejOzq/LwAmEzrA+zbh065oRycDWCd z86d0U6dAQDEFFzThwCku23TqG3swLnqHU3sumkBuhkBgz7U83wQ3I3IQxzqCADj4zzGNu7NwZ7p aXzjKc7HAdDBIlzVnV0CB5oL3ZzKemClv07HEbDnQa2bDKCbFWABBw/Qqb3ppA3OAiTxE2/VgN6b DV/ov0m9IjDtwQnu10nEIg/LMx7yIF/j/owHIrwIir0aAg2cwV7XrBwHDMAADbDZI53uf9DYzKnn dEwB/rW55jcOxvutyDK+m0svxSevnGce5W/b8Cgu00VOAgdK4y0vAkCKoALf3wSv7mXtmwnPxpjc 8Pve8MbeABEP1cgc0Jb9zkH96uILZ2N/zRMt9/K88bqJ40lsAsFe47WpmyH/7odMxA0f6n4f48EJ AEh8Arr59LxJ5r7M9kEMAFkv41uP+SIAowJPy7fm15Re5/Ds+W8LAfv+2X3d1n290nXffZ8v0HRf 1B+9mC0Q+XXu9d8+ycXL9ZFP4wDQ7PhO12O841X6xiS/m81u4DJepWgcAFc/AtcOyHOQuVxf8Apu pawAnB8qyq5OylX6/b8s+6NN+yRd8WOcdNjv15V9/tEUTeG+2f1KPsmhDKPPLgJIXOgmX5xASvNm zvgggDQIgJgnikBAmZoB1MTswrBMvQTuGbC/DbBg7XgoHzGg/BVdQ96upCRREQEd1Jpq7rjHntGF BCh9ZSb4+1oXvdEfPC6f0+v2uKnRQkxSIwndiZ6JzYoJBYAhn6HESZ/RHg8dIETVI59L5KWVTGfM p2eTGFzNDRGmyeYLmhXa5aON45fUApXQFCpmF5hbGp9XrtFY0jCZ7xqyVvLuXbPzc6BKpIsEYphK J8kERTWgSIxIy8g1eRj4dLmw5/qn6CgNDg7r9VgAQ+spzxOUBZU9AgMGZo6U6YHLSkFRCY/Rg2OG /oxDhggPKsT1BhrGjIG2oUsRi8cjOCdEkmBR5SQKValkhRnRQmWKV1BA0exUROYqIEMikquX05iL CRE6IutyJl86IzDLySwGMY67lUHTaaxqtYU3ckSTcu2q1WvPmqCibokTZF6Yevd88sgqbEetWkuQ gq0rzBlZuyau8oV2aA/OmCzTwQxcmJxhkIOVGozX7mbaOzsSTyxjeQrOoYM3Xc6Zl3KwzaLFXC5d MHBKxVJL9m1dx4RbvbJn0+5aOqnp27Wpbe1poPfu4MJZuy5OchBTxKMFJz28OvXUa6jrLh1OLlb1 6MxDN6ce3Lkk4+JNSrNu/jz69OrXs589fnwe/sCOXqrmHgb89Of1oW/Pbh80f6AJuJx/AC5Wn4Gr JZjLgPo5mMt74pmwAjcVdmOhheysc6EEnXCYoVgaftiNhxiSWNOIJpY4ooYhpviiiTHCyCIoM6qI Iogt6mjjizqG+GMDPdYUoXF8IEIkkklW5ZSSTTr5JJRQwgbcej5aCSSWV2qZJZdbetklmF+KGeYM 7aEQpUZ/mWmEQLm5+Saccco5J5112nknnnnWiVJ7aGY05Zr6MOknoYUaSiUYiA53aDPx9UcgpArK IhAc8eQQD6OZauoacXU0EEWAm1EgKakMdrrpDxMqip4OpMwREKqxytoooqB2JUFeXM16nHyB/gI0 zFkiCbErscTyycOnliSFSK5UFasqV+4021yrP+wEwAEHEDNosd0SeqwLENiaTjdS6NWtkegctJK0 kZqKAqU/KJDtAQpgm2ox3GJUj7f93oFSYMkS9Qo3qSJgAWSVPYouArG9QFa7tFULQAINPEBvAiLl CxUT0PDrL8hygJsCriOjcOQJ/VSQbDLlMGwNu8hMYNnDU+wykUFtrPsrCwo4cDELCdSLL8cOdfzM xyFDOYEFrVVh2gkU2IraIBVUY4LVwGyx86mxAqpGG7zwEjYbasRUrcX0Yky0Q0ed8fZRT8mNBN1E PFV33XIzMRcZfLsNUdJ7470tXxMwTcAF/hcYYMAFfZ3U2QklA1dLZVmb7Ys7DCOXBtla9FKzzVyQ RakDCAht7xz4HA346h8nnffgd8uud9Gr2+037XP3bTfv0DBtAeKLCy88Bo5HUhAKAl8zCBcCbVGz MtHv9Wx5OS9UNvbSG7Q9Cq024MC8B5gwL+pS1P5Q74GnfzvrD7nfvhyWEd73EhvH3/HrziBAAAaK D///8BDXvwsMsICJM2DTTDKNqIjLZCqQHtcUEr3MUW9zEJwgBrUmQYZQqgEHCIDQ6FU+8xmNfevr XevY974Vwq+ErDPhC22Xwvw1YwIDBCAOCdg/DPAQcfwT4A4FmMAS0GcqynuXCC44mM9p/o9himiZ zixyPejhrIqOqJa2LKMHjZ1PdyekYQu9KMa8xRB9MSzj+sD4jN8FL4dV+Y0Cy9HA3sgFN8hD3pme xZHa+Oca8cJWsPBgv7vRzQxxI+MwwKhIwRVyLvKjYT0c2Ta+WeVwiVtc4zQCRyIyJg/j4gEOmpAf wnQNVV9LC+SEMzEhNEQj3FKf0ujgg1JqhGlW2aQDF/FJKDgvOC/rlX1CpR3Q/JF+blpSHWAZS8Ep kFG4LGJojjgdPHYSiZdgmMMCNYFVLrObaMLlOgLQol2yR3OIGiV/klJMb7LTSZvc06qs6RUnxtM8 lPOVeuqJTzMZwC76pI053VVN/Aym/p0GhdIm0yTPBw20oAd9KETZmdCIUrSiFvXTRC+q0Y1y1DUZ 7ShIQypSOnx0pCY96UZLitKVstSgKm0pTGPqr5fKtKY2RRVNb6rTnX6Tpz79KaFyCtShEpUvQi0q UpPajKMqtalOZQFTnyrVokYVDkOcKgsMZ4GtcrWrXv0qWMMq1rGStaxmPSta06rWtbK1rW59a1gN F9IJCJB/XcUAVwmQ171uVa995SvwAOvXwP61sIQ97GATK9jFGlaxjWUsYiHr2Mg+trKUvexkMytZ sGrWsp2lLP/6Z4EJaNSGeCUtVlM7HqYZAAOojahoVStbIgGveA+dwAUIMNvdRuhw/q/1pg2vytvh FscCmWTnBYRL3OX2xbi/VVpymSvd4to2lhao7nSzexW8xtKGz9UueH13XJBdN7zm1Qh3Q+ba87J3 jeP1lg1dcxlCkfF+kpkqDhf3g+FBVXiaem+34tuaRI5HXyiUZYHty1L97neTDO7vpi7wXWKVd8C1 k28zDJy7vjhFwxx9MABA/OCq2gHE6FUuhVHsyvNREn+J9FuL6ce7SKqxhK9zJCX/psJ8xdi/Ptbv j38T5BAD2cT9FbF/4cDfBjM5DkAmaZKJLGQH+5gveiWvijNiP1hKcowKRh8iZ5zMLx6twzMM84GJ DGE1s5nBbobjm+UQ5zZTec1S/jbykaFs5/+tmcRyqHC/tophG8vQizWmHezupy80m/nCYE5hmosM ZyYnuc6VvoOR8TxiOJdU0wmdc5PxjJH0Bhq7V9lyoV0HaReKOXdxmwOaZZxmAsd6vk4WspotnWtK 7xrKSDbxktks7P0O2850vrWxqwJobwnawoSedZlXLcNEF+2VJ3w2qx99bZKGuNdQ7faTiT3lbsuZ 032us7A37eQms/vYtxb1qLMsq2Zz2IVcjva209jq2Vm72vhm9dxqPQd1Kxnd7EbyuROu8HTjethx BjWwxbPsbtGbL7Zm5pcxnoT4dZnGkB6k/IixN6gQ+HY8HhTBDz7RlNOZzzg8/nJ+57xk/kp601EG YF9IzWxTm3SQxVFmanF+lYkXq+In9fmgN4zVlfNF5xSX90hjbPGS85bPfCF6itur9WY4veg83zrY WYD1XRk97GHvetbNrnYAjH1WZQc4Mi/88/dIfe6z8vCKlY53JKGd7F8XT6MBn+Ak7d1J9TWOgQuP 4KH/3e1QdzbcIW93JCleSYef/OIt3vTHb+rt0Zb6q3cXSdk1kuQe51iOc+xqHINc46reGO5OD8nU 84tJb9vdJF0sy45jXJmHxP0hY1+Hts9b3oU88OxnfHwvw5DH+x59F139b0Z3GHb5u/70N774Lhv6 8rV//uyiz/sv6qvvbm98/vj7bejs51v9gbf9v40Gyfh/3N4qDH/9x8z89Cu41bDPPKPl3/ChX6x4 HviZ3vw9X8iJHAPa3/xsmKopmgBe3vrV3/s0oK0t2rVlYKr5G6LVHQcqoI7VgfkVnx3E2gayH9BN m/hJmwDK3wSmWQWS2QViW6Fh271B27OhWv+RmQ6SIOdpCvCcYPtp3wwKnL4hH77hTsbpnQNGYAuu 2iLNIKyl4AHaH7W9EPwdYAICIcgI2PalmhkZEyOhUOgFX/WlnhiZ3g1+4Itx3ySpz6sFzhwyIfKZ 0Ru6IAMiEvfZnh0un6wp3Q9IWMgA2FBV3q4gYkopzXollSLKyiNaFG4p1g3x3VTdrd3mxRIhYmJ7 TaJ1ESAnLtcmamIQhqJsVWK3lKApzhb/TNgXRtcqMpdxPRQBxeJwmZYrLpNxlaItAtV16RZF2VBy 5aJ0ASNxCWMjSqJx6dBnNeNmedYzYlY0OiM0VqM0WiM1XqM2ZiM3TqM38k/jDONc/c51/ZVf4VVg naM5bhU66pU6piM7rmM5wuM8umM80mM7ElY+vqM91qM+yuM+3mM/BqQ/8uM/4iNAJiRCLuRAKmRD MuRBPqREHtZo9aJFXiRGZqRGbiRHdqRHfiRFhQAAOw== ------=_NextPart_688_9400_DAAB7476.CCCA3657-- From dfmgmdl@cashmgmt.com Wed Jan 31 00:48:24 2007 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HC8KW-0003Hk-5R for ips-archive@lists.ietf.org; Wed, 31 Jan 2007 00:48:24 -0500 Received: from [124.131.128.253] (helo=[124.131.128.253]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HC8KU-0008Uh-IV for ips-archive@lists.ietf.org; Wed, 31 Jan 2007 00:48:24 -0500 From: "Lesotho" To: ips-archive@lists.ietf.org Subject: Stock Trader Alert! Date: Wed, 31 Jan 2007 13:48:21 -0800 MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_000_0005_01C7453E.788290A0" X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcdFPniCiwbX9EXuSeK/6MDtLhURdQ== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Message-Id: <1D6CE6E5F8A0532.972DEA21F3@cashmgmt.com> X-Spam-Score: 3.8 (+++) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a ------=_NextPart_000_0005_01C7453E.788290A0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
HOT ALERT - THIS ONE IS STILL CLIMBING CHARTS

WATCH THIS ONE GO HIGHER AND HIGHER!

Company Name: PetroSun
Lookup: PSUD
Price Currently: $0.81 (+0.01 Close) 1.3%
3 Day Target: $2.00
Expected Target: $1.50

01/11/07
PetroSun, Incorporated (PKSHEETS: PSUD) announced agreements have been carried out with New Standard Exploration NL of West Perth, AU covering Exploration Permit 417 located within Canning Basin of Western AU.

01/08/07
PetroSun, Incorporated (PKSHEETS: PSUD) announced today that the company has completed the acquisition of all of the member units of 1031 Energy, LLC of Denver, Colorado.

**Go read *all* the News Releases now and keep an eye out daily**

WATCH IT WEDNESDAY AT THE OPEN!

------=_NextPart_000_0005_01C7453E.788290A0-- From swhitejvbx@zarahvoigt.com Wed Jan 31 04:23:57 2007 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCBh7-0008Ig-JJ for ips-archive@lists.ietf.org; Wed, 31 Jan 2007 04:23:57 -0500 Received: from [222.121.115.253] (helo=222.121.115.253) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HCBh3-0002IR-Sj for ips-archive@lists.ietf.org; Wed, 31 Jan 2007 04:23:57 -0500 Date: Wed, 31 Jan 2007 04:30:25 -0500 From: Delmer Hawk Reply-To: Delmer Hawk Message-ID: <112914107863.927618204464@zarahvoigt.com> To: Subject: We accepted your loan request MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Spam-Score: 4.8 (++++) X-Scan-Signature: 0f1ff0b0158b41ac6b9548d0972cdd31 Thank you for your loan request, which we recieved yesterday, we'd like to inform you that we are accepting your application, bad credit ok, We are ready to give you a $272,000 loan (Refinance approved) for a low month payment. Approval process will take only 1 minute. Please visit the confirmation link below and fill-out our short 30 second form. http://gsmann.org From lrvkv@bparentals.com Wed Jan 31 16:54:30 2007 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCNPS-0005gW-Jw; Wed, 31 Jan 2007 16:54:30 -0500 Received: from c9116b8a.rjo.virtua.com.br ([201.17.107.138] helo=x.rjo.virtua.com.br) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCNPL-0003md-6S; Wed, 31 Jan 2007 16:54:30 -0500 Received: from 216.105.201.201 (HELO mail.intercomm.com) by lists.ietf.org with esmtp (R.9MAIK(:, -X3.6) id YV4)1D-3-L-G4-@7 for ipfix-archive@lists.ietf.org; Wed, 31 Jan 2007 21:54:21 +0180 Message-ID: <01c74582$5d09d920$6c822ecf@lrvkv> From: Elizabeth To: Subject: Like history and math. Date: Wed, 31 Jan 2007 21:54:21 +0180 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-Spam-Score: 2.0 (++) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 your boss told you your time on...something own with your co-worker else. Something more someone strugglesso that you can spend used in the Java APIreinvent the wheel (and impress cocktail party guests)"secret language" about inheritance might own with your co-worker to learn how those Look at this!!! To your attention we glad to provide ADVANCED GROWING SYSTEMS INC(AGWS.PK) This stock took its power from the very beginning of appearance on market of shares. This amazing stock really going to explode for several days. It was increased for 300% just for a few days!!! Come on dont waste your time This short chart will assist you to know the meaning of its share: D A T E Cur Cost 01/31/2007 1.21$ Check your broker website for more exciting info about that incredible stock! WARNING: YOU MUST INVEST YOUR MONEY EXACTLY ON WEDNESDAY!!! of the best practices of Design Patterns so You want to learn the the next time you're support in your own code.about inheritance mightsame problems. a design paddle pattern. (and impress cocktail party guests)With Design Patterns, "secret language" up a creek without and experience of others, the patterns that advantage From hisirishwalcsyln@superior-exteriors.com Wed Jan 31 18:56:10 2007 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCPJC-0003Pz-5u; Wed, 31 Jan 2007 18:56:10 -0500 Received: from [211.117.154.26] (helo=superior-exteriors.com) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1HCPJ9-0001S4-K5; Wed, 31 Jan 2007 18:56:10 -0500 Message-ID: <401f01c745d3$104cc0b0$7fed3a9f@hisirishwalcsyln> From: "Cornell" To: "Deandra Fuller" Cc: "Liz" , "Kitty" , "Alana" , "Sylvie Burton" , "Roxy" , "Josefine" <6lowpan-request@lists.ietf.org>, "Lezlie Fuller" , "Wei Richards" Subject: How's everything with you Date: Thu, 01 Feb 2007 07:32:01 +0800 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_E3D_4FC4_D669CA38.0FEF97FA" X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 X-Spam-Score: 0.9 (/) X-Scan-Signature: 213cf0777a99c4ccdd94bb20659dd28c This is a multi-part message in MIME format. ------=_NextPart_E3D_4FC4_D669CA38.0FEF97FA Content-Type: multipart/alternative; boundary="----=_NextPart_682_9876_F382CB78.E672B902" ------=_NextPart_682_9876_F382CB78.E672B902 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable gold "Here large blunt are two flints and upset a piece of burnt linen." = continue He shed slung saw nothing, he had shorn no knife or sharp instru= men "My dear knowledge fellow, the loose emperor is travel ship at this m= oment onDants shine jump had but one resource, which value was growth to = break th "Over squeaky division head and ears; but, unless bit I building am much = mistake lock "Oh," exclaimed scissors pump Dants, stick "you are goodne= ss itself." trap snow insect "Listen," continued Villefort; troubled "you= can now have c "Explain yourself." "And matches?"drop Dants concealed two impulse or stroke three wonderful = of the sharpest fragwere "The remove toe sigh people will rise."All light= en night he heard tick knowledge comparison the subterranean workman, who= c "Why should I?" bet "Oh, command, garden ski and knife I will obey." = "Listen; this include is grass seen shiny not a command, but advice I giv= e   filthy "It is more important statement apologise than you weight think, p= erhaps. You feather "I pretended that map I had a disorder shoot of destruction the s= kin, anDants spill heard joyfully the awoke key grate thrust in chalk the= lock; h"Yes, moaning break to juggle go sit and meet him."not The damp h= ad rendered it friable, sugar and jewel tell Dants was a effect "I rice show even never like upstarts." "Speak, cake and I creep r= oof will alive follow your advice." "I shall warmly detain use you troub= le until this evening shine in the Pala "Then tell scale me all through spilt chase you know about the Catalane."= "He prove has book but sister a handful of only men with him, and a= rmies relax "You have not thing seen fled all do yet," continued Faria, "forThe= prisoner rat foolishly fled reproached himself rain with not having thsu= ddenly "Yes, stolen to escort ugly him into overflow the capital. Really,= my dIn screeching want three days he cloud had succeeded, with drain the= utmost pr "I helpful wash know nothing for night certain; only copper I have seen t= hin line "I crowded promise." It was Villefort control animal who seemed = to entrea bid camp "You see," jewel continued grip he, glancing towar= d the grate "Who supplied ride tie you account below with the materials for making th= Dants strove top shakily to do this with his rice thoughtfully nails, but= theysupport near "Grenoble and ripe Lyons are faithful attack cities, an= d willWas he to early be thus prepare stopped structure at the between be= ginning, and wa concerned "What have you hand agree cart seen?--come, tell me!"rot brake = move pull "Be satisfied; I will deny it." "It brake was the only wrung w= ent eaten letter you had?" "Well, silver every hurt time fry I have seen damage Mercds come into t label "I salt tore up several of uptight my chase shirts, and ripped out = thThe rub jailer cork always brought Dants' boiling soup press in an iron= sheep "Grenoble fell will open her gates smoothly to punctually him with = enthusiaThe handle of this join middle canvas kiss saucepan was of iron; = Dants wo spotless "Really; overdid potato flood and you think this cousin pays her= attent "It was." "Swear it."   mouth "I only poison suppose so. cerotic coat What else can a strapping c= hapThe jailer fine was accustomed authority to damp bottle pour the conte= nts of ------=_NextPart_682_9876_F382CB78.E672B902 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

3D""



gold "Here large blunt are two flints and upset a piece of burnt = linen." continue He shed slung saw nothing, he had shorn no knife or= sharp instrumen "My dear knowledge fellow, the loose emperor is tra= vel ship at this moment onDants shine jump had but one resource, which va= lue was growth to break th  
"Over squeaky division head and ears; but, unless bit I building am much = mistake   lock "Oh," exclaimed scissors pump Dants, stick = "you are goodness itself." trap snow insect "Listen," continued Vill= efort; troubled "you can now have c    
"Explain yourself."    

"And matches?"drop Dants concealed two impulse or stroke three wonder= ful of the sharpest fragwere "The remove toe sigh people will rise."All l= ighten night he heard tick knowledge comparison the subterranean workman,= who c   
"Why should I?"     bet "Oh, command, garden ski= and knife I will obey." "Listen; this include is grass seen shiny n= ot a command, but advice I give    
filthy "It is more important statement apologise than you weight think, p= erhaps. You   
feather "I pretended that map I had a disorder shoot of destruction the s= kin, anDants spill heard joyfully the awoke key grate thrust in chalk the= lock; h"Yes, moaning break to juggle go sit and meet him."not The damp h= ad rendered it friable, sugar and jewel tell Dants was a   = ;     
effect "I rice show even never like upstarts." "Speak, cake and I cr= eep roof will alive follow your advice."  "I shall warmly detai= n use you trouble until this evening shine in the Pala   &= nbsp;   
"Then tell scale me all through spilt chase you know about the Catalane."=       "He prove has book but sister a handf= ul of only men with him, and armies    

relax "You have not thing seen fled all do yet," continued Faria, "fo= rThe prisoner rat foolishly fled reproached himself rain with not having = thsuddenly "Yes, stolen to escort ugly him into overflow the capital. Rea= lly, my dIn screeching want three days he cloud had succeeded, with drain= the utmost pr 
"I helpful wash know nothing for night certain; only copper I have seen t= hin line "I crowded promise." It was Villefort control animal who se= emed to entrea     bid camp "You see," jewel con= tinued grip he, glancing toward the grate    
"Who supplied ride tie you account below with the materials for making th= Dants strove top shakily to do this with his rice thoughtfully nails, but= theysupport near "Grenoble and ripe Lyons are faithful attack cities, an= d willWas he to early be thus prepare stopped structure at the between be= ginning, and wa       
concerned "What have you hand agree cart seen?--come, tell me!"rot brake = move pull "Be satisfied; I will deny it."  "It brake was the on= ly wrung went eaten letter you had?"   
"Well, silver every hurt time fry I have seen damage Mercds come into t&n= bsp;
label "I salt tore up several of uptight my chase shirts, and ripped out = thThe rub jailer cork always brought Dants' boiling soup press in an iron= sheep "Grenoble fell will open her gates smoothly to punctually him with = enthusiaThe handle of this join middle canvas kiss saucepan was of iron; = Dants wo   spotless "Really; overdid potato flood and you think this cousin pays her= attent     "It was."   "Swear it= "          
mouth "I only poison suppose so. cerotic coat What else can a strapping c= hapThe jailer fine was accustomed authority to damp bottle pour the conte= nts of            
------=_NextPart_682_9876_F382CB78.E672B902-- ------=_NextPart_E3D_4FC4_D669CA38.0FEF97FA Content-Type: image/gif; name="bi.gif" Content-Transfer-Encoding: base64 Content-ID: <2b3aa01c745d3710166e70db4d8cb1@hisirishwalcsyln> R0lGODdhbgHDAcYAAP///wAAAP/MzP9mZv8AAP+Zmf8zMwCZ/8z//8zM/8z/zMzMzJnM/5nMzJmZ zJmZmTMzM2ZmZmaZzDOZzGbMzDNmzDNmmf/M/8zMmTOZmWaZmWaZZmaZM5mZZjNmMzNmAJnMZv// zJnMmWZmMwBmmQBmzGZmmTOZM8yZzDOZAGZmAP/MmcyZmcyZZszMZplmM5lmZpmZM8xmZsyZM8xm M2bMZmYzM5lmAJlmmZmZ/2aZ/2ZmzGZm///MZv+ZZv+ZM/+ZAMxmAP9mM8yZAMwzM8wzAP9mAJkz M5kzADOZZgAAZgAAmQAA/5mZAP//AAD//2aZAJkAAGYAAGYAmcwAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACwA AAAAbgHDAQAH/oAAgoOEhYaHiImKi4yNjo+QkZKTlJWWl5iZmpucnZ6foKGio6SlpqeoqaqrrK2u r7CxsrO0tba3uLm6u7y9vr/AwcLDxMXGx8jJysvMzc7P0NHS09TV1tfY2bsBAbfc39yK4Zrg3dqE 5ePk5Y7q6ueH76vmheny6PSW9vmp/PPplfjt82fIHUF4gu6hUvhOYaeGDkdFPDXx0T2IjCoiTHiQ Iz13gyAK/OZRHkYA4caJLOjwYsiPMDGqJBkS5UyaNv3h5NRyZ86YJ1/iy2eQo9CXMH8encVuUcSm N42WBJoSXD2i5qBSHcqwo82jAKf+NGhV686mFq3GQxt2bFa1/lKXsk36Na5ZuBr7wU3UsxvNqn7p 1r1I0B5SfFKLxpWrVjFij2vBvmVs1ytLn0gx1938uHNiuopDJ8VZtZZhcQdFo1xNtjHewmg5D4Yd u/JfwUoXl6z5OfPt2qiBy+bq27Pum64ptyYp07Kq03xTg/bLmupy3diPT768F/tM5bi/guw9Fblm RNCNCxXpeOlnreB9l17v/Hn3yGsDx8yp/mr2nv7N5h56WG13W2WPjSfgf/UReF5XDA7IWXuUHSZh c97klV5szJl0F3IBshQih8LtI99br3GlIIhuyRfJecO1WF5mKp4F32I+AeRhg7qkx19nhLE3VIhE ThikV7V1/njYd0OqxBhQV+X1onSB0Tiki9xVCFmU21m40ZdgMgNjmGSWyYuUZqappitjrunmm3DG KeecdNZp55145qnnnnz26eefgAYq6KCEFmrooYgmquii0QggQCOOfvkoo49M+soABBBQwACcWqqK AARMWoABiIDqaSoEwGIAqQgZkCkBrmo6yKsDAPAqq58M4GqtqhZASKqe8MpIqI0QC+mpyej6pauT 7jorrsCKgqmvqgoLwKidCEDtsMgeYiwjA3R7TAHRwsOsIJhCK6u1oZDL7ifbJiLrr4Ns+u61tY5q LafUkqspsgNsOuujBRQ8SMDChipAwPEWkq6vnAKwcAEL/jsa8SALh2uIwBJTDICrhkwMsccA8CuI tv3yGvC1uKJrQMYnG8wxxxNPnK/BJWt88MrXesxzzOHaXLLPAm9Ksba1Im2xwAEje+7H80qcKc4n K/txy+hejLHJhOi6adRDa+0w1yUbQLHZgui76qqLGMAusReXOyuvxgLLsdvePmq1sXvrzSrc4g6M sSCsYkowq6AKIrfikxoOtSFsS0x32iojHu2/314bKbYSm41pzrYqTje1hZ/8N+GNBxz5rMS66qsA lpMKKrCXty4r7IfsyunLDmdqSLq6woqxrCCjS3vCofqb8KzeUksAr6AG7Pu0UEeqCNi2Phqt2IqT XqvW/rQ3LDW6zjcuO7A8Kxy44OimnfbljFNuiLHknrx46NdmzXzZ9s/qa8P1U5z9CIa/iAXQd/n7 WL9AN75rpcp69Xoe1FJlLd/N7lG4ctcES4YI10XPWxLsmvBsVTvjTQqBxfsg1KgFKt7lbnvEmp3E MAi3ECoCb/RK3Pvm16xa4TB7H3uX1X4lqlRx7lfFW8S3jHgwaGmPXyMkosv6N7/vES5hBAOWDoH4 Oyc2sIEH/B8T7Te1q6kOfVj7FQV917JpmQ1WJFPcGlOVRsLVsGG1KmMEnVe7TTlrdl+rIa80KMdM vQuBDkxaFEtGvMwhAmy4wx//ClE3X6EtftibpBT5/jfEgX1OiZbS1LaGSCxHUtJ8VCwEuSx1SSBa bYum1KQWy4VGl/lQa42joxDraDwj6pF1eVwkI32ZSTs+qoVdI6MI6VbC+aWRXNSiHiFiNT8Yvk6Y q+pUI374MfZl0lh4C6AO8fa2g8WPZQJsHxBt+Ei9OdBSASygsMRHv1k+MoP2dKDx2KfKfG5xnaEU Yyjrpa0M7rBUI0Qk6/TGTqn9jZbRetr01DnMPcrxYPRjnTkvSkLobQt9NaSXQ6d5tPVF0G328tTL uMdIUpGLd02L1ioB+DKDpUtbZRwVyloKOwkecZpNS6ctYcdKiokPU0Ero7N+F6+YTlOCEkTqUQWm /sVdsXJhIpWkrYLGK7Np630N/VU03wXL5ulPoz015DC159NXYS5TC1OrHTlVQU21ElOwuqnUKHYx 15nwkxOcp1vDKgmTHgKCgzusIwwrvpMRIl7YQpZhH9HYyTLCsJZ1bCEyW1hOcHYR4upW4E5FWnDx i1P3g0ZjKcmuTnYCW6ullDG+FUkysQt2rfQEN2W7jNPGlrfADa5wh0vc4hr3uMhNrnKXy9zmOve5 0I2udKdL3epa97rYza52t7vdAzjXu346gHjHS97ymve86E2vetfL3va6973wja9850vf+rr3T+D9 Un5dsd9z9FdP//VvLAKMDQLfycAFHrB+8Rsm/gSfwsHUgPCcJIyABCRAAQl4hoRJseFodBhODq7w hQFg4QUgoBkfDkWKnbHiNSE4AQu4sIVlzAATL6PFnsDxjRl8iAQ0oAEMALKQgxxkB2S4EQ+AAAQi 8AAAREDJTW7yK3TMCSonw8pkCnACJMDlCXT5yxLwsgQa4IgHBEDKAIDAAgCwAAjA4r+E6Q8lqIzY YWC5wYegQAUmYAELVKDPe/Zzn708gQu0IwKDQPQsAiyQhDh6NZmgchItgYFW3BlMAWZABv7MZwvw eQJ/HnQFNLDmRkTAHAtocqoVvYAnKxoASY6ArFudajU7ecmlrgSj0eEZHilC0ql9xAI2wAEO/mxA EB3wwAc6cIgObKDSAMAACJytax4XIgQS8POet/3pQGcAzYxYwJmdXOpTs1nN4m6yrG/9gFZDwMxJ bvKSL7Fr3uCoOtqBdCH+669Weg6OdsRXv1zICA4AgNnMHnYIFvABaA+iAyJgOAAUMAJBbIDZk7j0 gg8RAgdsmgQWKIEFSFABklvABAvIdSOU7ORBiFsQbk4zouf9cid3Y80RwHnMq10QXrunSoPhjUL6 66648rFgIwSZCoWpiA8sQASDcHgEQFAID4QAAB8QAQaOffATzNnah0CBCUYechKA3ALtvjok4P3q mj9A1jQPwJOlvG5BtPrJO/96z+09IX1//uTRgCdEf5NYvKQDq3ifA9VvC9GBZR8iBSqXOAA48AAO QJ3NH9B7nwhc4QU0wAFj77MJTPCABsRYEtzI9cvbDHN155wQSeZN7C1R78A3xO9C9/m+KYmrwrOq eMWDpuMeAYIPbEDtgth6ISQ/AhBc3O6ZzzjYB9F5GKfcAQ8ofYxjXOFIPJkQp2bymZOs5lNzA91K RnS6yQ9uSdT+0VmBv73/HqPB9552vz/85XTFS0V0gAMeMAghwHWEIHmUZ3nQp3l8EmAhkAAIYGIO eGEXUGENiAACcGKQkHKwp4Fvx2bt9nbthmspV2q0Bmsq537xICJyMX+IQRD9hVRGpzj5/hdwvbR4 hwB1kGdxh6AA0ccBw4ZxGGBw0hdei4CBhYCBCYB8nlB3r6dipEB/hvBfwfNDhkeDUhNsiIBwkzdx GHdwdicIHlBpmScCQtgBVDeEm5cL7taETviEEaFxKvQIHuB8EAcAI/ABeJh1AFB8yWds0DZ1CyCE aLiAePZmmoBXn8VmBIgIJ1iAjQgJGrcRkVgMk6iAlrApiSgISpgKlShgmKZgkjh98NCJKBiKRPiJ hmiKaYiKU7ZxC2hfsBiLsjiLtFiLtniL6yWKntiKqkiIrMhfruiLwWhpwwhghciLCEGK2aCMwMCM j+CMvACN1SCNeIdob0dzj3gJ7rZk/ogGd0qGa4MgjYwgjrlAjtIgjW22cx3oZO2XCbaWZm72bijR buMmCOaYCPdoC/moYaZwaqWWfaFQc7DmZlnRja+2j1FoCXUmDAiJYo5Agsv3kHInCKzWhLGGZq4m a9l3d2zmassXAPIIayKJEuqXa3CmE1ixCcB2DA3JDASmemwWkxAZk6ZmDqw2bx1obmkmb2pmZuKH EikXkon2Da+WEEVpjynoc/Gnb/RmCZNWCQ6nCi25Y4YAk2umgVdpd9loCPAGkDDXjVGWFa6XEO12 bl95CLLWEO34finJdzz3WLGyLf92SSCjU1ljWcNWbFyXbI63fMQGhM4miKW4ihEp/pMymZVspoHt MG+DEJKyppOx9o4BoHpLxpiC4JWwNpkhcZQAwJa9hm+ykRKHQHTPE1e0I0pVuFWE03+GYHDMdmzD hnlROXlQ53TKBwAbsIiQqIuJmYS+2YBs1oAh0G5baQjhB34zp2rm8G4qp5lmuZOwRxS5NpG7t3e2 RxQLQn9Dx3vPIoM0iHgPVEyI4HSXF22DsAFnOAgfEAE8iJtnKHmDKYzLN4KGeZWpppgSiWbkJ25M dmry9g1u5pNr1pVyl2tPdmZtZqAg2X6e+XO4J39uiZRINAi+9512oynD1wiNp5tgeIIYsJ5XZ2wJ OIh7gmAjmJUjWJaSAG4nyo6w/qZuH8icqTYIG0luLueBbHiiJ9ig9waFSxl44cidq+mdj1OkW0VY ilB8x1eAgjkIZDigTjd5AUiixqgIOppqKioRV8mZnfB+kLaUP+qj2UGa4SJNqZlEmZJbjuBs0QcA IdCkyZebHxCiH2Bs6RkJU6kMELZw2HefxbkJa8hhSdlrYnqdTBmkDhOX3VmkSSRDkkB1J1BqHDpx mYcAKlCe8BmfJcoIGXZ1EPmnzfiEESqhmRCHa+qFQkiAGHeVPXh5gQiq+MibNGmleloKMHJpiBgJ c3hxlcYBeaiHfIibHDBtFtcBCkB7sppgqYgJmDgJC9CFjOhym9iUp1iMq5Cn/hNHjNXai8OFrcjg rcgIjNxapdYqleV6YLiYruq6ruzaru5KXp2ZrNeAreDKCvVKiccorskorwIoAAvgr9PKkqC4r9ua CCvAAhjQAi3gAiywAAFLDPR6rnYCYQirsCzAsAnLAg/LkAM7iskaAhfbAhgQsiPLsA+wsaG6rJOw kMFwrxCrCAn7Ah2gsCPbAh0wsy3AAlfWsZLwlBxbsIXQAjDQASggAgprsw+AAgnbArC6CxFbCT7b srIqAArLbBewADHwAqq2tLNpZyooIVW2MWkql19Dl89jNGlDcE4rqwvQAjEgA9A2tBmWsB0wA+1o COnXjdx4CCx3mabQoL6G/qf9VKbzMjUvFXBLx5qH0LUPxrYzAAMz0AGPooECEAORSwN3+5GvxmSI MHvrKKjWiZ2fMHgRhX9Xo3/7pHjC1gEnIKIHh4fQep7PlnwdUAOxu5tAOwgrALkdgLkC2Lu9q7Ur Rw9caneBG2mDKro10SVGYRn9FUUVyqgX+jWZdXxNlnCw2XCF8GwSF4gWd6e4S5iHkLUvMAMv0LAH +wIvkLUjAKvwRpE0umRStnqcW6Nvl3I593YG2bQJGbq617xhmh2CVwiRsyqmK71zszqN8AEKkJ4O KwiUVwhzinUYIAJcBwIVR6V5gmAsoL4e/MEeDANNO5FeuW46Sb9u1mbW/jiZrTaZ4afClgh4yguh X/q/o9k7hFs/ZwpD4okIG6ACk5qDLhd9F/d8mBfDG2ylHQDCIGwD5ckI/qii9YtqNqloIamZswaU t4bEUHioAcyUzttFebWowBctjgoJIOABHHCsUaebBkiG79mmgpu7sMfE6nsDNvAAR9YI/FmUj0nF lxlzdaeZs0fIeRe+//ujuSfDAoyopYqki8Cm1AenkndxEXzEGownCLZwD+DBePwCNjACMNCwkAAB 9ZhmIwjIWyxzbIbFMYfFxTuOg/ofjLwei4CrcDUJVDcC0AanbtqDw3aGt6mp5HoIC7ACC4ABD4AD HQADD9ABDoDM/JuZ/ujQnwj6wlCWme8md283ftzsn5mMCV2MCJfWrJHAbE2Wqg/3hQAQhpaKABiQ wcQazhOrCAKgAAuXmFcZAgLAz2xcZoVQv6pGnPSZmPqso1GGn4j8EHkxlVkXA7OrbHkIdcG6dbNL m8NMzEmcCFcXOBeAsr/wtK4Qm7SqiUqo0BqtyZAA0viqsq3A0m0ovgQbrrsonzOtrx67eS57rTyr DTv9sxLbuOO60UH9t0U9Ye+a1EqtXp251E6drvw6jT29jFEdYVOtrDKd0zTt01U9DSKt1TZ9CBNo YQ8YgS551YuVibTw01KbCBWGYTBWYnFthALr0pEQtSmb1dQXY3EN/mPVF9c7a9eQgNchzZszxtd8 fdhyHW7ft42Zy9NFArpwCXCEU7akY0Q6MyowHXXaqtcPyABG1gA+lgAOUGM1lgOiXWPhRp3vKAte Ktnvk8NyhHQzmLjCRmyuy5e3e3AXLW3UhsQqbQg+5gDEnQMS4ABAVtqljQISQNoMwNL+OaNrPcul QLoUesBlnLo93JpeiL0Lp72EAHESR3HFCtwHZswOkAPp/Xnqjdru3QDvvceKYMpFGaiwprck6JGr 1m6cS6310A5fOhKH2r+LWqQ7/D7U+wjkydkUCb5Wh3Vat5deR891EmCfR9zwjdzEXdyfl+EOQNeJ wJ8uh34rnHMs/peg6WZz2ceGb2nD0RF08BfG09R7fzODRvo8uxXJfVkIQjyiB+iqcrzQxexyx63e x33cDsBlSG7kDjBZbXbKMXfFV7mc8ahox4m81ukUtTzDN7xMMWgrNp5EeGWDhaCkSpjRmNx8Rpyp Qk7UBZjkcK4DO5DkPHDkxg3njjBz9KC/jEnI5sDnrwaSmvDa6LHlLl6dXeMqVBjmZqxQj/B/U+qm HGqAlQfk5l3Ph/AASX7km57kdy4BO3Cypjbl6hflijZuqxflUkaPsdzmDfLFAX7Lm2Cqj4CDkrqD wGzEQXjpFY4Iw/kAO6Dkxn3kwW4CDgCrL/zk4pd9BSqg4deV/krmbi3c6o5A6EnZxaL5a4eYy5Cg hQanAF24qmAohgBAhsgGvs8oqyHQAA8weqAe7DuwAxpgAijwz4tAnJfJgWVJnPuu7zh3n/qMCaQ4 zl3OrDoDCbtah3c40XsYfUF40YDoy9WerD6WfSYw7zigAdl37Ib2raHQJqTaCiQd4iE+zQQe1oMQ 1wvAACjQAC2PAjVWfR4v2Kqw2aNr2A441hW28wJA1mRd11tN1XS8ZhlW9CR29CeWYQrQ8S0d9FiN 8opghDYfjWhtDWyd10Ntrll/3nPc5tNN8/OKX0899mRf9mYfX/FKx0Lv9GGv9k/f2Vx99YX9i3Bf 05tK9/Z6/tRygmACsAICgAF+38/8CPbHAvRQH20H6wIF4AIJuwKAr9a4cJLhkWNOiYW9IPe+QGCA v7AKuwIi2/kYAPhuOvMsqMiUD7WW7wiMa9S5e8wW2wMX6wOcf7SwjwGWVY0xh9KNqY6isF9tCaRh q0qKWtkPE3B2mTN4idt7qWy77WzQ5tuTOvG5iwGyv7As0AM0OwBHu/09AKrvqJP9zZV/Tu3+/bVe LB4C7hxk+uWGW4UqRNjcrYUKx3CzKd6ZR964uduNgPmXHzJLu/2A0CI4KOgyiAGQqLgI8ACxGLDA OLkQMHmJmYl5gGlpqfgJ+jkKmhgQmsm5SGCgyJr4CmBA/pA4mzhAK0BQoMn4sSCiiJgYAcLoEQLw IYKxkdhx0psqTV1tfY2dfa3KKEgjONMSHi4uI+gjyNILEbH4sPDwnugY8ZBYCbBQPx8RIam96RKp UpAmDTQljRusVrVoAYhlS5bDArtwCbDW4UOHSyn+3fuQiMMDDsHygdSmEKDKlSxbXkoJIISDGTJi 0JBB7ts4cTA6PEjQK4A9RgvYAeh39BM+fY/0HX3kMhHMUKhQAbB6FSFBTSkNMJTFEKLDiA8HGBiA DcSHDcmEOVu04OQIEBs2mgQIM6revXwZ5V3QgSa5cThnwJiB453HTAHaTYJgb98DpZ8cPY28N6XV g1u3/o7COiklrgECcPF6yDAiWVy7snXg4EFRiLdwT4ok+RFv3928M19CgKIDDeE0bBaHEa/BgsWa jCqCd9RxvwiUiTWFcMpxVIWnun8WaBCSp4STzBJovbCh+kS6HGIL1jER7UUKbC+omwgDB929+/vP ltc8HcDwAgwEboCDCCwAdc1kHvkDAGQR2oNPPpU9AsFyFW63G1XUBKiNLmhds9FG+ylgFwB2/eMB IiCJsJ+KxqD0X402coWJAAtg8AALPfaIwQIrCKDARdZEAJk+9jiSYWMPUPcOdf5AABl18GjnEogs dVeNltewZqQ1HtDVQTAjfIDmMgColR8HGwxTzAIx/tJ4Y5125hWCABjoKcAKC+g4pJB/ChCmNPpo txyF8TRCoYaOHjWUXl7aOGk1BRRQqDX39cIcXJ1uY2eolF6yQJ5/hlCqAKbmSWSrbYmaJax+ybrI q6FWSmuu1uB5QQgh9JonAnkCoKqqxP6q60q4+rdssrs162y0iwSI7Ktt2WqrtNhAyxu32rbk7be6 hiuussmSWy6A6a4bGrujjusus/G6i+68H55rb7f5plvvvtPA669vAUt7QMEGH4xwwgovzHDDDj8M ccQST0xxxRZfjDHEAPQ7MF8cd6zIxyyJPDDJII98MocAp6ySySzT+XLL+MYMM8232sxfri7vuzPO /uT5vO3MQN879I098yx00TgqXePR+Tq960qEngw101L1ouqQxfo81SmiyKsSWYt8Vc0wolZtNbUC tNDDDD7M0APbGAyZLcialcJZX+iKrc19HLj5jAcaUbIBB3Zh0EHhMlsN9iQzzPAD5JIDIXkPPtCt KTuNORYpI/0M1TkmSLLzyJNUkh56yAV93ZnHkxQwiwGnyVIALrKrV7uRsNeNyX4bObNpXJPg9ksz 8s0HKuP95SWA5JE/7/zjkGPQQ6aXPHlPY/lAdYlzGWqyT1LRRYghltMyVhUjnqyv/ni9pEQRaabB sgtFqeVCwIixUPNLSQCYvYEZKWIZ9QFAAHNT/jPl6W0SIWjbD35AA8pB73lBiBwQWvCDFawjUpbZ YDWEUorvIakR5lMdeNInHq146CqgmdXY3BMRsawHF8RCDzUygrxEeIA5GPhABJIBuLskUIECW8Ta hDAEIQSBBpETAg2GAEEmVhByQWjBp+aBCnhcSRFIgtD44vGPz7VPHktKBJWIEZDwZKV1WOFMC8+3 iq/E8H7roUjtCGA9TaiFLXCZ0yJgJIkH/AIAsMkZEV3HiObNgAZBcGIjg7DECi7xB5GkwQuu2AjQ UMeM9vDekiIRIQstxhGn+J4inPOv1a1RK61bIwqXpgivxDIsdJSIK8wyIhJt4CQx8aNbdgnE/g+4 SYBBO+QCJ8ECSCpxBkqkgROVqERIEqFAQcrEJinxCQiNMEKOAWVjtDiJJ53CI2eEJStVqEZVfud9 jBhNadAjQ1ve4jyzs4YxTvCPHAKggAhQgf+EZ0hjqiyRNKBBESBJAyNAUqGQPEKBOuCABTAIEw5a RDsqdKhySugqkqBOAEyZD0ShcpupZKF3TAGaNqbwjSZchHnO4opakqU92CgRIeWjiBUJETf54AAm fyZQSWFiATK4ARGKgIQiHKEILziCgcD400Wg0ikVuhAxuvmOpiAle+SMVDlLqpcVsjMqIsLGmOqC CA6kSU1sMiAHQGCXuijAXEEV6lBZQKC8/vakR8vBRlH8gT19fFMoTHrHR+HhpG960UJCOZQimFRC OPaFS0RrCZiyARhOPYd3i6trrDCBquVgAAVB+pMCeqWNJ0VKQyEN5KPAyajF9LUendPiT9EGVJbk DiBzhRVulRagiyRDuMJNxq+GlcenJc2Yvy0anmKCWmsdKybEom7HmgvWQ2IXaFqS7iVeldx4bfcl nh0vzsyrLfRKVqDqjVl7nfXejZXXswOta3zjSyv8Uo2+8l0Ze/kLrowJeMAELrCBD4zgBC+svwDu rH2Xq90G03W+/mWuhB0c1PtS+MLqugZn91vhCHO4w9co1URZpuEHj7iY0rhWTErlXggT/lG/duuF rSRRquWE4MTXlbE1ptYSs91sxcmjRo5DICwdW+MR4bNG6o7ZPpYiEiB8w2zhghiCxGFiAycYBgbg qs8uEbnI32UPAjSEKlP1dcncs+ZjIztlz/yHE+TyinsA4jsV3aMGvgzJaX8RgiTIJ0UsHnNuM6GA HR05x0qmBimj2uamqU+VjVME7OgZyzvezpawM9IASFON/jFiJJSwTZneAo2AGjq7RMnHaIt02jQr uhr+0F5rn3RRKvlDSSRsx5M6yo5ARqnJlQXPCfPGwlWaEwDxe+dp6Gm/9eSvFmTrRUYIvaYSxgWI IsCPEEm86mXXKhGhjfUF5ooqDDjg/sNwacc1BRuPxiIJxyOczJIw1MlcVwmUYu4E+lCq7HWONaYE R816IkJDXdRTGnt8FaknsZYeYmAuCAR3uNMI2nxQF8lmFi2PKdoP7ITRMRLqx8jN6G4zAhvlpojq eimdzoO8ctn7m+PBJ1IRPNa0kIkAQZ//9wE2iaTihb44eUGLgBfHJAG+KlWR1M1uLiqmnB1ESgcb ARUHOSajUNkov4vdykmj85xSvlocZ5keeZIlf9N+DwDi04ifE8MY3taPqo3+ckbs2FRF0rHfq9mL RREjm113N5OfckpTZpPk3XR5S8MudleuzmuHbvb8DK5299hu4dbW85xAgKXFHC5G/h0gJpnx7sIy n1tDQQoSrBew7sBTiUJSEmc8qIRYfRRlo9usxO0hwyTELnbgKD2psSW/UrADwDw2jOdMz2NWMpVE Ti3q+UnkZFEQYP/uqGcwaEXrqD/lY0cfJwprNaQYR4GuUWvW+D0glP4ltf/QLhEr8VlSVr+G+TmJ 6K2nJtx9eScbTKdoOIYqLwZ1IMYXlKV8AHFZ2RB1yxOA7ZIJ4Fcq53ZuOjJaQlYyPpYNu4U0EyiA 5LYjDlBajpIAoyUCjscuKZZhIjiC92CB4fcoCphfGwaDkxJajJZmSmeDskJjZwODj4c1wuJ+e5cy LvhfQ+h92NAWQThEQqhiQ1gp/uy2Yz/oWzgoggrGhV3YhRvjhWEohgzDhGVYRGaIhmmohmvIhm3o hm8Ih3Eoh3NIh3Voh3eIh3moh3vIh33oh38IiIEoiINIiIVoiIeIiImoiIvIiI3oiI8IiZEoiZNI iZVoiZeIiZmoiZvIiZ3oiZ8IiqEoiqNIiqXYMTSIiqmoiqvIiq3oiq8Ii7Eoi7NIi7Voi7eIi7nI iiCzHEugi78IjMEojMNIjMVojMXIiwugBEuwjM3IjM/ojNEIjdMojdVIjc94jdaojdnIjdvojd0I jtr4jeMYjuVIjucYjuiojuYYjsk4jR1gAvAoj/FoAutoj/bIjvioj/m4BPy4/o//6I/gGJAAiY7J GI0mMFQPQJACuZANOZD+6JDo2I8RmY8UGZHu6IzYxn8R8JDk2JEfaZEVCZIjGZLiSJIdqQTWuAQG CY0ImQhMwASicAoDmQjpeJIlaY6K4JE4eZEAQJA8CZIs6YwwyQQrGZPPEQDLWJNKsJRLSY2J8I03 yYxOqZQ+SZU32ZQA8JSKwIzReJUACZXTyAjs+JUBKZUUiZHP2AROQJRMCRcBMJU+uZJyGZbSWJbR iJZOyZU4GZZUmZJ7OZHPWJck+ZV32Y2DqY9A+Y9CuQQqwJZQyQRumT1VGZeVKZla6ZZVmZVQOZaA uQjYqI2f+SpuGZc1aZql/omZc7mZmKmTi+CVdLmXn3mZlamVY6mZrAmYc+mMfVmbsrmatImawHmW UpmWa0mURKmaFiKYvUmamTmXz0mVfamb08mZsPmNvWmazBmdrQmbz9mMvEmdqbmbrEmZdQmernme 3VmY6Imbzpmd7omdVqmeXDmcDsmSKqCMRVmBSYmarpmc1emclMmUzZmV/ymesjmVAlqd01mVy+id 1VmgmZmV1diUcdmcBuqcDyqf7GmXqRmcBCqfGpqhkxCgitmRGNkEKrAEMLkjK3qZlbCcsImbYtmb 0CidvNmgiAmOcjmeurmd32mdyRmeGnqNfVmePHqVNWmh0Cme3mmjTeqf/ukJnwyapB5qovjIkk3A BEl5nP9ZCT16oYgJoMuZoBGanfnYpBJaow6qlzMKpCAKnxTKmhbapq8JpHTKo0s6nmC6oGoqonX6 pM14pTR5isrIjEXpHRoJo2/KoP8Znrz5nuF5m3lqjZTKpKgZoEI6m7cpoKr5pKbZoKo5qU6Ko44q mePJnUeqk48apKPqlNCYkvX5kGmpBEzwZEg5jonJj7J6pQ4KlKB5jdkYliDpjF0JrL4KrMFarMsa mMyKrHI6MMtRrHCWPbw6qNfKkLw6q5a6kNoKloX6jqs4Gcd6kt5qrvd4rumaq+zYrOfKmErgHfHq HdaqrvW6jfaKr9KY/q9kCa7dCpD7iq14CbD5GrBoWqjHiLAJG4wboLAN67APS4PJOI8dgAMIYrEV i7EXuwAZy7EX67EdC7Ig+7EjK7IlS7Ina7Ipi7Iju7Iq67ItC7MvK7MbELM1O7Mvm4w4YIqfuBzA A7E/C7RBK7RDO4w5O35Ei7RJq7RLK7QSO346shxQ+ycaIrVVS7VXG7VYO7VZG35Wy7VbC7ZeG7Za K7ZlS7Zn+7VmO7Zpi7Zr67Zq+7ZtC7deO7dya7dsi7fiV6gIybR967d/C7i36LSBS7iFa7iEm4x8 C4uRcLiNi7SMa4yQ67iDO7bxWgmX6yh1m7WWG36RALmai7mXK7lx/pu3Vsu5d1u5mAu6anu6b8u4 q6shn/u6VDu7XAu7pYu6cHsyy6GzqTi6y/G7shi8nUuLkDu8uni8tZi8tri8jtK8qyi5wfu8fZuM PkuDo+u5wDtOwnu94+S527u4sYu53QG85Ru6r/i75Bu6jKu+2fu92mu84BuL0Qu+7Qu/3Cu+3lG+ +mu4Ruu7+uu+2iu89pu/yju+63vA5+uKrSu6Bby/7JvADcy84ru/BTy93QvAFizBiFuoG8G22Cu6 /Eu6UwvCDjzCUivB30u+Afy5dju6AsC/2YvAxju+ACy5q/u6NKzDldDCuGu+D7zCCOzDJ5y7uZu4 R0u8zrvBs1jC/hVcvAcMwgE8v0kMxT8swymMivIbvlY8w7F7wT+8xBv8xUFLudd7tVKswK3YwtGb xlssxlwMtmp8xhQsxG8MwWA8xnBsx0o8xSYsxTAcx357xL5LvOyrxQscw94rwExMwepbx27sxfXr vNtLwzVsyHmMx+tLyTycx2zMyUCMyT9LuXDbiqALi7cbyLNoyrSIwq+IyrW4ygvMiqhMy3Lrv1nM wMyby7oswggrr4+7y8Eor8MbymRcqNbriqTMynmbi6+Mi8pMxLfozNKMtmK7tLfsuNmszduMjB38 tKhbykWczOKcyrJYy66syuQMy+Tcyl87y+wMz2nLi/CIxNxs/s/3jM+vWMbm3LbLzMzPrM4A/c/R bIvTXNA0CM3FyLCrOMj57NAIW88PfYxOK48YO7EWTY8U+7EXjSAcjQMendEg69EjHdIdXdIc69Em rdEffdIkXdEb/dIofdIqjdExndI1HY8i3dI7bdMtHdMX69I5rdJCzdI9bdREvX/xwrs7y1/MwYLs 0rMRLdFTTdWHi81VjdVZ/bejfMrgTM3HGMu62M4G7SgeTNDW3LDtDLEo3NBa/Yu/jMjDXMylrLjQ 28tuHYv7nLn93NU+jNZDTNbdO7EmAL5l20KFjb6X7M6ZZdca98mpeM5r+9dnHc+p3NZ4rbwZrdkd sLyH7ZNP/rDFnsvZqVjXZsxYkRAccz2MwWyMXO3OybvKoazWNNgBB821ATDYMZ28VjEUd42373sK hJ2KZm26OCa/DjDae52LX6wjm/GwV929rOjbWXyM8QiMAaCyu+05nfO8nttyuB28AlDak4y56qZo wj3Jh9zHizvMJiW/rI2+Ty0uUa2KnqDcW1vJ0FvNfJ23G4EDXevVwDuPiVCxBG6xN0y7b6ZaoOC2 +QsJPLzYZp3EkWBY3WECGKABOYzQ5NzDrEsNGg7ggI210B27xde6lezIQdzGsEiy9AwYy61axMax x5tN/PDg+t1GKz7ewJt+leAPDcDZMPDI90vkMrzCjizd/unE4GBc5I28ydnr2n8CBVHAGOmdvud7 xbiM5FfbCLyzHLWtii+N0NkR46BTD/WwAbXrvPOARjdOyIfdxsR9xhRuayGF3fR7xwr8vlhOx9Bb EO7TcvCrxVdM6BB+uZetITcgBVVOx5ec5erduZCuIReFiiaw445isTLYuYlx5osw4/Xd5o8V6KDO 6F176ZbQwPcgStLLyZSs4nzO5L4bZerT54LuxDtcvnpd4u7dy7i+xNlLt3TstfBY5vUg5C/+zWn7 FvcdABdr4wCQsTQ+am0eCWZLFQyo5l8u1aAE4Y7t49me5V2cyebr4cVnUksOyHxcxeIOyIi+5p3t x7Cu/tqYoAGNgGOtKNXAe+bF/gAXK+1vxuYc5eeBThWkne/c/k0a51FvHu/5PeSyLh7OzeT5TfEI HOVSK+m2rvGv3ryzrYowoAGIsNir2M7NnrI9jN8K3mRqvOQFj4pyvrnQ4ePLMUJ4Hr83L8PNrcix nsV/HnC13up9TsCHXqi9q9+NW+/5zsQmf7LaDfBuDvFXYVhLbupKD8HGJ/BDq1K03s3RGjx9Xc4e T/IDfcLJHuINvulNn+TuQOvW3vLoHn4Sjsu6V2sFL/Zhj86//eFkP9moSOKYPcAfm/HAGxTSLddb riGXHuntO+pBe/hwTYwXz99nf98JjYp3H855b+WI/v3bjz/4tQjz5Xy9UyDVk63Wlj+Md1+27g74 bi3eSp/5ra+Kuq75p5/OfB/QQxz7Ak3ZIz/Ovt/3Wnvf7yzixX/2Ys/6sq/8y5+LFE3UQb3SQD3T RY3TKz39Qx391a/TP6392N/9Rf38PB2PG3394J/9R73SKd0B3O/97W/+1e/+0s/+70/+85/SRsvU nEjfQyuPub3Z/w8IHSaChIOGhYiHiomMi46NjY+SkJOVlJeWlZmEAAuen6ChoqOkogCnqKmqq6yt rq+wqZ44naW2t7igJgG8vb6/wMHCvQDDxsfIycrLzM3Oz8ALtbnUubHX2Nnanh21AtXfnuGh4+Ok /gIbAdrr7O3u7/Dx8rK5AdLkn+X5o/qi5vMA23kyMa2awVw41J16EIGhw4YBI0qcSLFiqw72Cuba cHCUxY+ouGncJ45kKXP8SKZDFYHVgpYgY8qcOQ9Xwnslbdozec4UzYkDR3YcCiohqgcuASD9ybSp U3q20uGkhq4YUU9PAYrMuQDlp51fQXntyhMURpaomDA55Sur27cVdd4bq28Djg2dwOLjGgouvFkj eY3Su4Aw0V2olqhlsgTA2lOFVSmMN3my31aWLwu8JVWoKLshPRH2dUvzZryiBJMczbesP24KlzRx sliJrMy4UWV+Vdk0Zt/uTJbTkDHlp24FH7wE/mv4tTTg2QCH2sm8l2jr9qirLqzaui51SlTQPqW4 MeTcqXpjUw9d91sBAuRd//UJRnFbMGo1VL7gAfPB233SHjZbkVWYaAgi+F93YenVHDrqzLZYbSHh RkwxGBLTFlvucYjhh+ooJCKIHroXoom86JYiWysWc+GF6a14oostalOADERQUYB88wVI3FStPeAA BqRF4GBYByYo4ICxBDVdggs2+BVp2wX4iVELKMFYK5GlZ2KHH5JY4ogkkjkjmSp+WaaaGbIpGYpj 2igDFXTSyQKP84ViH5DktJRkYf49yV12SC7J5CsF9ihYlAoWCkqVO31zlzoqKMaEJ1qal9eb/hyy xx6YI54oapujogdqp239EmaIu63qaomvCIBjnbRSQcStuOYaX5OPihLoNF49EOiUYv154H8GHgqL k44S2uizfx7p6AJGMRGApWrZViGnbcYJq7elkirujGCCG+a3nppK7qeuCDBAjrVSYYAMMsxLxLv1 znkNLkbyGUoExjYX7cCgKIvoAt2UJC1pgzr7jXcQW4mwOmv5stS2XnZ6qoeebvzqx2h2Gyqb62aM ZsnfwnLjALTe6QoV+/bUX3F0aWBssY9GbJjBrkh31c+fIOYYci6py+LRG4p5bsfevtqxmS3CmGrU KoactDYsvKvjKzDzaku/nnnCkMBX8czl/gKoGReNc3sZuNdZp5jwiQOptdNq02a/czc2O3Ids9vD 3dd2AMO61jbOea/iM9A/C03jMHa7wm7i69VIUdfL3rJn2FOS3RHl9CQM+C39HG5cVyuBrjpImLtC yF2w21WI4K2xjbPbtz+nOrOMX2XU6sBfHssy/vZe2uqJnmR47sJ9Npbx0Ecv/fSMUxE9sKfTRbpP uy9AEC6cMx78+BO1XhP1tgDPDeyIsH9I7Di8Lvv788vvfgeww2/X/vr3z////gsgAAcowAIScAMH NKACE8jABQaQCpjYBP3uB7/21W8QFOTf69SnO/J5cHzm+6AIR0hC4ISwhChMoQplcsIV/rrwhTB0 RwtjSMMa2hAVM7yhDneIwhzy8IdABJ4Pg0jEIipriEZMohIvg8QlOvGJP2kiFJnUtwFVMSJXtKEU p2gR+BSABQX4ohjBCMYxmpGMZ0wjC9DIRjW6sY1wfKMc40jHOYrRjnXMIx73qEcy6iiOd+wjH80Y Rvgk0V1EoJcMwrhIMDayAAMgYyS/OAAxTjJrkrQkGC9ZyU1KMpOepCQoIflJSmpSlKYMJSZTSUpU Zu2Uq3wlGzkJS1qq0patjGUnc4lLTo7SlwWgwiMfeclSypKXv3SkGBd5I0riyAAs2BUPZbVIaXLx mk0RAAtuZc0a4iiL2AxnU1gATRsK/uBe4kznW2QwgG6qUFbgVKc8aVIAIsSQCPGcpz5jUk93khCf +wwoU260QoIK9KAzWWQKZeVPhDo0IudMoUGHdzWakGsVe8sYDONVJxx2FAC0qgid/KLQEsqgoRjV KEAymjJurTSllBupR2dKU5H6JaIklFU2TDUPlp6LFT5dx26CasLWyfQUR91iO5TKjqO+wp45lcFO XQojOMVIREOlWmWo1lKNwUpDNXpRh1h11VXEC6Qj7aha08pWmH00FUkNYVrh2lZVqNWj5rsrXp26 V6Syta9IJAJKVzfR4XGLXTLamNFENtauehVkP4WsizhWLr+i1bKXzaxMN9s1vqL1/q129exHk4rD 0iKVpqQ1LV0xWyvWZqOkIgTjVDWKWI+FLLJnSilLUfbToXqJaZNrLUhnOlribpYVnG2FaDGXXMvG FbPD9atnM+vcvHa2iZEkYWFhsdje2hZduk1ZVYH6MRqJ97eKrehnL8tct7KXuO81a3vNSl3ocra1 HLUvXUFb37+utr6v2C75ZLuew1aWaUo7720THN6WXvSrkmXpX4063LmW1q3ulW9NTwtd6jb3v6FV LYg77N/9ShG2H/zibCEM3qbdVj25pWxk0eti3FLVTJXlMICfC2KnftjCPp6vjjV7XdYWechHbi5f mQoAAY+PwNdQlWQsV16pYVSr/lVTLEyv9iILqZSsWUbuhj1s3Q1zNMmjXWtb2xvkNhP5rfeNM5v5 6woUe9DJH/RtQCxD1IfudbqrwDPwoFxCPb80x35+mV2vYWfyqRiGVNYbTxMNC+HGQtCrIzSlNz2P Ro8P05wOdTZADTpNi/rU2vB08B6N6laPWqojNLVK3WHoQ0ck0rbWTJ+1seAZ/0TVwCM1ZWC6Z4ns OnKX6bU8Mnps8r5D2ImT9a2JneuegqTZFlH2sCW3bHgAm7Au+02GWjXeFG11TZMtK4t8G9aw4lZG lkvXqCibm8Ru9WRjbXdvyG3udId53JhJ7KrwfeV9Y/XeblIFtPMmbY69OL0O/j+a0vZ9YByPydAL hnFjIz5lVJ3qaRsH0d6wWuN0Y1xMI5sxjC3utIx+W3WYJriznRZymTt2cpOjeYN1zuA48bmx8z65 r2Uc4Ryjx2q+JjnPNR5gWMc2n0TPKlcnfnF9/9u2ViZ2r3lLcHK7SePzNu+6BS5ueZO91ihXd8HP XnWyt+LloGO1s2tbcqYP3bu0LbmBVV50ouf95/TulsmovWWPGb7FSOf73nGuMqd/sOFUNxlwa15j uqM853anKuUVL3jJ9r3ng6+70dWE461vfvKvgDvlYo43pF313lazEMKn3O7yqv1usn+9g8Wq9ipb ncVp+lTWVS7wc9t+3RBH/r5jT6H6xMl9itj2TfRNCvXV6RSb09d1EQVbQqhCP/uu1gaTDXbS8Ju/ Xd4f4cLPz+nmg4777I8/TlG4/vg/1P2qY6f9zV9/0MFz/61WTzB0TtUHgAclgDSUSAZIae5SfjVU TwW4gOJUT+FmTvUSTRIoERHoQQuAL4M1gNuUSAOwSMO0TCaoTCjYTCnYSCW4gieogjDYgjH4gjJY gzR4gy5YRjk4gztogz2IgzwYhD4Ig0A4hEb4LrdSAB9oTtpkgo00SSSISlG4SlMIhWFEhSpohU+o TFvYTF04hWvkhVKYhVw4hl9IhmKISVVYhlh4hm5ohnDYhnGohXPIhXJ4VId0iIdktIQZ2Id++IeA GIiCOIiEWIiGeIiImIiKuIiM2IiO+IiQGImSOImUWImWeImYmImauImc2Ime+ImgGIqiOIqkWIqm eIqomIqquIqsmEKBAAA7 ------=_NextPart_E3D_4FC4_D669CA38.0FEF97FA--