From ips-bounces@ietf.org Mon May 14 17:29:57 2007
Return-path: <ips-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Hni7A-0007t7-2U; Mon, 14 May 2007 17:29:56 -0400
Received: from ips by megatron.ietf.org with local (Exim 4.43)
	id 1Hni79-0007sw-3w
	for ips-confirm+ok@megatron.ietf.org; Mon, 14 May 2007 17:29:55 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Hni78-0007so-Q7
	for ips@ietf.org; Mon, 14 May 2007 17:29:54 -0400
Received: from mail0.lsil.com ([147.145.40.20])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hni77-00031c-4b
	for ips@ietf.org; Mon, 14 May 2007 17:29:54 -0400
Received: from milmhbs0.lsil.com (mhbs.lsil.com [147.145.1.30])
	by mail0.lsil.com (8.12.11/8.12.11) with ESMTP id l4ELT3w8019671
	for <ips@ietf.org>; Mon, 14 May 2007 14:29:04 -0700 (PDT)
Received: from namail.ad.lsil.com (namail.co.lsil.com [172.21.36.18])
	by milmhbs0.lsil.com (8.12.11/8.12.11) with ESMTP id l4ELTl3F008554
	for <ips@ietf.org>; Mon, 14 May 2007 14:29:48 -0700
Received: from NAMAIL3.ad.lsil.com ([172.21.36.22]) by namail.ad.lsil.com with
	Microsoft SMTPSVC(6.0.3790.1830); Mon, 14 May 2007 15:29:46 -0600
x-mimeole: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C7966E.FEBFC3DB"
Date: Mon, 14 May 2007 15:29:43 -0600
Message-ID: <0F08E10B769EAF4EA2C43A573B8CC87FB5773D@NAMAIL3.ad.lsil.com>
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
Thread-Topic: Handling Expected-data-transfer-legnth and CDB transfer-len
	mismatch
Thread-Index: AceWbvyiscMCg7HiQxqE/7MmDiDVww==
From: "Qi, Yanling" <Yanling.Qi@lsi.com>
To: <ips@ietf.org>
X-OriginalArrivalTime: 14 May 2007 21:29:46.0934 (UTC)
	FILETIME=[FED5C560:01C7966E]
X-Scanned-By: MIMEDefang 2.39
X-Spam-Score: 0.0 (/)
X-Scan-Signature: c5b976cb26c967a52d72d6069c7fc54c
Cc: "Qi, Yanling" <Yanling.Qi@lsi.com>
Subject: [Ips] Handling Expected-data-transfer-legnth and CDB transfer-len
	mismatch
X-BeenThere: ips@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IP Storage <ips.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ips>,
	<mailto:ips-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ips@ietf.org>
List-Help: <mailto:ips-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ips>,
	<mailto:ips-request@ietf.org?subject=subscribe>
Errors-To: ips-bounces@ietf.org

This is a multi-part message in MIME format.

------_=_NextPart_001_01C7966E.FEBFC3DB
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_002_01C7966E.FEBFC3DB"


------_=_NextPart_002_01C7966E.FEBFC3DB
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi All,

=20

We saw an initiator problem where the expected-data-transfer-length and
transfer-len inside CDB got mismatched for a write-and-verify (10). The
expected-data-transfer-length is 0x4000 but the transfer-len in the CDB
is 0. The target completed the request with good status, turned
Residual-underflow bit on and set residual-count=3D0x4000. See frames 16
and 38 in the attached ethereal trace file for details. Did the target
handle this error condition correctly?

=20

Thanks,

=20

--yanling

=20

Yanling Qi

Engenio Storage Group - LSI Logic

512-794-3713 (Office)

512-794-3702 (Fax)

yanling.qi@lsi.com

=20


------_=_NextPart_002_01C7966E.FEBFC3DB
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)">
<style>
<!--
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:Arial;
	color:windowtext;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Hi All,<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>We saw an initiator problem where the
expected-data-transfer-length and transfer-len inside CDB got mismatched =
for a
write-and-verify (10). The expected-data-transfer-length is 0x4000 but =
the
transfer-len in the CDB is 0. The target completed the request with good =
status,
turned Residual-underflow bit on and set residual-count=3D0x4000. See =
frames 16
and 38 in the attached ethereal trace file for details. Did the target =
handle
this error condition correctly?<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Thanks,<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>--yanling<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>Yanling Qi<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>Engenio Storage Group - LSI Logic<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>512-794-3713 (Office)<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>512-794-3702 (Fax)<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'><a =
href=3D"mailto:yanling.qi@lsi.com">yanling.qi@lsi.com</a><o:p></o:p></spa=
n></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

</div>

</body>

</html>

------_=_NextPart_002_01C7966E.FEBFC3DB--

------_=_NextPart_001_01C7966E.FEBFC3DB
Content-Type: application/octet-stream;
	name="expectedDataLength-transfer-len.pcap"
Content-Transfer-Encoding: base64
Content-Description: expectedDataLength-transfer-len.pcap
Content-Disposition: attachment;
	filename="expectedDataLength-transfer-len.pcap"

1MOyoQIABAAAAAAAAAAAAP//AAABAAAA99lERiWmAQByAAAAcgAAAACguCAyfQAVxe1LLQgARQAA
ZD9gQABABsCtCgoTYgoKExGJyQy8RDZefaRAZAGAGBhPOt0AAAEBCAoAuKLUAAAWVgGhAAAAACAA
AAAAAAAAAAAAEYRjAABAAAAAtMoAALTMLggAALMAAAAAAAAAAAAAAPfZREYzpgEA6gUAAOoFAAAA
oLggMn0AFcXtSy0IAEUABdw/YkAAQAa7MwoKE2IKChMRickMvEQ2Xq2kQGQBgBAYT0BVAAABAQgK
ALii1AAAFlYAADvdAAAADQAAswD3+3uwRkTZUwAAAAAhbydeAADYNRAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAAADvdAAAADQAAswD3+3uwRkTZUwAAAAAh
bydeAADYNQAAO90AAAANAACzAff7e7BGRNlTAAAAACFvJ14AAAMtEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEAAAO90AAAANAACzAff7e7BGRNlTAAAAACFv
J14AAAMtAAA73QAAAA0AALMC9/t7sEZE2VMAAAAAIW8nXgAAZhQQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEPfZREY7pgEA6gUAAOoFAAAAoLggMn0AFcXt
Sy0IAEUABdw/ZEAAQAa7MQoKE2IKChMRickMvEQ2ZFWkQGQBgBAYT0BVAAABAQgKALii1AAAFlYQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEAAA
O90AAAANAACzAvf7e7BGRNlTAAAAACFvJ14AAGYUAAA73QAAAA0AALMD9/t7sEZE2VMAAAAAIW8n
XgAAvQwQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQAAA7
3QAAAA0AALMD9/t7sEZE2VMAAAAAIW8nXgAAvQwAADvdAAAADQAAswT3+3uwRkTZUwAAAAAhbyde
AACsZhAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAAADvd
AAAADQAAswT3+3uwRkTZUwAAAAAhbydeAACsZgAAO90AAAANAACzBff7e7BGRNlTAAAAACFvJ14A
AHd+EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEPfZREZCpgEA8gQAAPIEAAAAoLggMn0AFcXtSy0IAEUABOQ/
ZkAAQAa8JwoKE2IKChMRickMvEQ2af2kQGQBgBgYTz9dAAABAQgKALii1AAAFlYQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAAADvdAAAADQAAswX3+3uwRkTZUwAAAAAhbydeAAB3fgAAO90A
AAANAACzBvf7e7BGRNlTAAAAACFvJ14AABJHEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEAAAO90AAAANAACzBvf7e7BGRNlTAAAAACFvJ14AABJHAAA73QAA
AA0AALMH9/t7sEZE2VMAAAAAIW8nXgAAyV8QEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQAAA73QAAAA0AALMH9/t7sEZE2VMAAAAAIW8nXgAAyV/32URGTaYB
AOoFAADqBQAAAKC4IDJ9ABXF7UstCABFAAXcP2hAAEAGuy0KChNiCgoTEYnJDLxENm6tpEBkAYAQ
GE9AVQAAAQEICgC4otQAABZWAAA73QAAAA0AALMI9/t7sEZE2VMAAAAAIW8nXgAAMJMQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQAAA73QAAAA0AALMI9/t7
sEZE2VMAAAAAIW8nXgAAMJMAADvdAAAADQAAswn3+3uwRkTZUwAAAAAhbydeAADrixAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAAADvdAAAADQAAswn3+3uw
RkTZUwAAAAAhbydeAADriwAAO90AAAANAACzCvf7e7BGRNlTAAAAACFvJ14AAI6yEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBD32URGVKYBAOoFAADqBQAA
AKC4IDJ9ABXF7UstCABFAAXcP2pAAEAGuysKChNiCgoTEYnJDLxENnRVpEBkAYAQGE9AVQAAAQEI
CgC4otQAABZWEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAAADvdAAAADQAAswr3+3uwRkTZUwAAAAAhbydeAACOsgAAO90AAAANAACzC/f7e7BG
RNlTAAAAACFvJ14AAFWqEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEAAAO90AAAANAACzC/f7e7BGRNlTAAAAACFvJ14AAFWqAAA73QAAAA0AALMM9/t7sEZE
2VMAAAAAIW8nXgAARMAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQAAA73QAAAA0AALMM9/t7sEZE2VMAAAAAIW8nXgAARMAAADvdAAAADQAAsw33+3uwRkTZ
UwAAAAAhbydeAACf2BAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBD32URGWqYBAPIEAADyBAAAAKC4IDJ9ABXF
7UstCABFAATkP2xAAEAGvCEKChNiCgoTEYnJDLxENnn9pEBkAYAYGE8/XQAAAQEICgC4otQAABZW
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQAAA73QAAAA0AALMN9/t7sEZE2VMAAAAAIW8n
XgAAn9gAADvdAAAADQAAsw73+3uwRkTZUwAAAAAhbydeAAD64RAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAAADvdAAAADQAAsw73+3uwRkTZUwAAAAAhbyde
AAD64QAAO90AAAANAACzD/f7e7BGRNlTAAAAACFvJ14AACH5EBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEAAAO90AAAANAACzD/f7e7BGRNlTAAAAACFvJ14A
ACH599lERpOmAQBCAAAAQgAAAAAVxe1LLQCguCAyfwgARQAANEVSAABABvrqCgoTEgoKE2IMvInK
C14O+SYn3N+AEIAATm4AAAEBCAoAABZWALii1PfZREaepgEAQgAAAEIAAAAAFcXtSy0AoLggMn0I
AEUAADRFUwAAQAb66goKExEKChNiDLyJyaRAZAFENl6tgBCAAMCoAAABAQgKAAAWVgC4otT32URG
5KYBAEIAAABCAAAAABXF7UstAKC4IDJ9CABFAAA0RVUAAEAG+ugKChMRCgoTYgy8icmkQGQBRDZp
/YAQgAC1WAAAAQEICgAAFlYAuKLU99lERhenAQBCAAAAQgAAAAAVxe1LLQCguCAyfQgARQAANEVX
AABABvrmCgoTEQoKE2IMvInJpEBkAUQ2dFWAEIAAqwAAAAEBCAoAABZWALii1PfZREYwpwEAQgAA
AEIAAAAAFcXtSy0AoLggMn0IAEUAADRFWAAAQAb65QoKExEKChNiDLyJyaRAZAFENn6tgBCAAKCo
AAABAQgKAAAWVgC4otT32URG1qcBAHIAAAByAAAAABXF7UstAKC4IDJ9CABFAABkRV8AAEAG+q4K
ChMRCgoTYgy8icmkQGQBRDZ+rYAYgADamwAAAQEICgAAFlYAuKLUIYAAAAAAAAAAAAAAAAAAAAAR
hGIAAAAAAAC0zAAAtMoAALZJAAAAAAAAAAAAAAAA99lERgSpAQByAAAAcgAAAACguCAyfwAVxe1L
LQgARQAAZEN7QABABryRCgoTYgoKExKJygy8Jifc3wteDvmAGBgWOt4AAAEBCAoAuKLVAAAWVgHB
AAAAAAAAAAIAAAAAAAAAEWJtAABAAAAAtMgAALTJKAAAALfAAAAgAAAAAAAAAPfZREY4qQEAFgEA
ABYBAAAAFcXtSy0AoLggMn0IAEUAAQhFcQAAQAb5+AoKExEKChNiDLyJyaRAZDFENn6tgBiAABCu
AAABAQgKAAAWVgC4otQhgAACAAAAogAAAAAAAAAAABGEYwAAAAAAALTNAAC0ywAAtkkAAAAAAAAA
AAAAAAAAoHAABgAAAACYAAAAACkAAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAIAQAALggAALMAAAAA
AAAAAFNGNjQ1MDAwMDEgICAgICCWUBAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAABQAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACJhPMDUxMTA3LzE0NTYzMAAAAAAAAAAAAPfZ
REZ9qQEAcgAAAHIAAAAAoLggMn0AFcXtSy0IAEUAAGQ/bkAAQAbAnwoKE2IKChMRickMvEQ2fq2k
QGUFgBgYTzrdAAABAQgKALii1QAAFlYBoQAAAAAgAAAAAAAAAAAAABGEZAAAQAAAALTLAAC0zi4I
AACzAAAAAAAAAAAAAAD32URGjKkBAOoFAADqBQAAAKC4IDJ9ABXF7UstCABFAAXcP3BAAEAGuyUK
ChNiCgoTEYnJDLxENn7dpEBlBYAQGE9AVQAAAQEICgC4otUAABZWAAA73QAAAA0AALMA9/t7sEZE
2VMAAAAAIW8nXgAA2DUQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQAAA73QAAAA0AALMA9/t7sEZE2VMAAAAAIW8nXgAA2DUAADvdAAAADQAAswH3+3uwRkTZ
UwAAAAAhbydeAAADLRAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAAADvdAAAADQAAswH3+3uwRkTZUwAAAAAhbydeAAADLQAAO90AAAANAACzAvf7e7BGRNlT
AAAAACFvJ14AAGYUEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBD32URGlKkBAOoFAADqBQAAAKC4IDJ9ABXF7UstCABFAAXcP3JAAEAGuyMKChNiCgoTEYnJ
DLxENoSFpEBlBYAQGE9AVQAAAQEICgC4otUAABZWEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAAADvdAAAADQAAswL3+3uwRkTZUwAAAAAhbyde
AABmFAAAO90AAAANAACzA/f7e7BGRNlTAAAAACFvJ14AAL0MEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEAAAO90AAAANAACzA/f7e7BGRNlTAAAAACFvJ14A
AL0MAAA73QAAAA0AALME9/t7sEZE2VMAAAAAIW8nXgAArGYQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQAAA73QAAAA0AALME9/t7sEZE2VMAAAAAIW8nXgAA
rGYAADvdAAAADQAAswX3+3uwRkTZUwAAAAAhbydeAAB3fhAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBD32URG
nKkBAPIEAADyBAAAAKC4IDJ9ABXF7UstCABFAATkP3RAAEAGvBkKChNiCgoTEYnJDLxENootpEBl
BYAYGE8/XQAAAQEICgC4otUAABZWEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQAAA73QAA
AA0AALMF9/t7sEZE2VMAAAAAIW8nXgAAd34AADvdAAAADQAAswb3+3uwRkTZUwAAAAAhbydeAAAS
RxAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAAADvdAAAA
DQAAswb3+3uwRkTZUwAAAAAhbydeAAASRwAAO90AAAANAACzB/f7e7BGRNlTAAAAACFvJ14AAMlf
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEAAAO90AAAAN
AACzB/f7e7BGRNlTAAAAACFvJ14AAMlf99lERqapAQDqBQAA6gUAAACguCAyfQAVxe1LLQgARQAF
3D92QABABrsfCgoTYgoKExGJyQy8RDaO3aRAZQWAEBhPQFUAAAEBCAoAuKLVAAAWVgAAO90AAAAN
AACzCPf7e7BGRNlTAAAAACFvJ14AADCTEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEAAAO90AAAANAACzCPf7e7BGRNlTAAAAACFvJ14AADCTAAA73QAAAA0A
ALMJ9/t7sEZE2VMAAAAAIW8nXgAA64sQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQAAA73QAAAA0AALMJ9/t7sEZE2VMAAAAAIW8nXgAA64sAADvdAAAADQAA
swr3+3uwRkTZUwAAAAAhbydeAACOshAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQ99lERqypAQDqBQAA6gUAAACguCAyfQAVxe1LLQgARQAF3D94QABABrsd
CgoTYgoKExGJyQy8RDaUhaRAZQWAEBhPQFUAAAEBCAoAuKLVAAAWVhAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQAAA73QAAAA0AALMK9/t7sEZE
2VMAAAAAIW8nXgAAjrIAADvdAAAADQAAswv3+3uwRkTZUwAAAAAhbydeAABVqhAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAAADvdAAAADQAAswv3+3uwRkTZ
UwAAAAAhbydeAABVqgAAO90AAAANAACzDPf7e7BGRNlTAAAAACFvJ14AAETAEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEAAAO90AAAANAACzDPf7e7BGRNlT
AAAAACFvJ14AAETAAAA73QAAAA0AALMN9/t7sEZE2VMAAAAAIW8nXgAAn9gQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQ99lERrGpAQDyBAAA8gQAAACguCAyfQAVxe1LLQgARQAE5D96QABABrwTCgoTYgoKExGJ
yQy8RDaaLaRAZQWAGBhPP10AAAEBCAoAuKLVAAAWVhAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEAAAO90AAAANAACzDff7e7BGRNlTAAAAACFvJ14AAJ/YAAA73QAAAA0AALMO9/t7sEZE2VMA
AAAAIW8nXgAA+uEQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQAAA73QAAAA0AALMO9/t7sEZE2VMAAAAAIW8nXgAA+uEAADvdAAAADQAAsw/3+3uwRkTZUwAA
AAAhbydeAAAh+RAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAAADvdAAAADQAAsw/3+3uwRkTZUwAAAAAhbydeAAAh+ffZREaCqgEAQgAAAEIAAAAAFcXtSy0A
oLggMn0IAEUAADRFfwAAQAb6vgoKExEKChNiDLyJyaRAZQVENoSFgBCAAJnLAAABAQgKAAAWVgC4
otX32URGvqoBAEIAAABCAAAAABXF7UstAKC4IDJ9CABFAAA0RYIAAEAG+rsKChMRCgoTYgy8icmk
QGUFRDaO3YAQgACPcwAAAQEICgAAFlYAuKLV99lERherAQBCAAAAQgAAAAAVxe1LLQCguCAyfQgA
RQAANEWFAABABvq4CgoTEQoKE2IMvInJpEBlBUQ2mi2AEIAAhCMAAAEBCAoAABZWALii1ffZREYC
rAEA6gUAAOoFAAAAFcXtSy0AoLggMn8IAEUABdxFmAAAQAb0/AoKExIKChNiDLyJygteDvkmJ90P
gBCAAM9LAAABAQgKAAAWVgC4otUlgQAAAABAAAAAAAAAAAAAABFibf////8AALTJAAC0yQAAtkcA
AAAAAAAAAAAAAAAAADxbAAAADQAAt8D3W2uwRkTZ6gAAAAAhbydeAACR+BAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAAADxbAAAADQAAt8D3W2uwRkTZ6gAA
AAAhbydeAACR+AAAPFsAAAANAAC3wfdba7BGRNnqAAAAACFvJ14AAErgEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEAAAPFsAAAANAAC3wfdba7BGRNnqAAAA
ACFvJ14AAErgAAA8WwAAAA0AALfC91trsEZE2eoAAAAAIW8nXgAAL9kQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEPfZREYnrAEA6gUAAOoF
AAAAFcXtSy0AoLggMn8IAEUABdxFmQAAQAb0+woKExIKChNiDLyJygteFKEmJ90PgBCAADbeAAAB
AQgKAAAWVgC4otUQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EAAAPFsAAAANAAC3wvdba7BGRNnqAAAAACFvJ14AAC/ZAAA8WwAAAA0AALfD91trsEZE2eoAAAAA
IW8nXgAA9MEQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
AAA8WwAAAA0AALfD91trsEZE2eoAAAAAIW8nXgAA9MEAADxbAAAADQAAt8T3W2uwRkTZ6gAAAAAh
bydeAADlqxAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAA
ADxbAAAADQAAt8T3W2uwRkTZ6gAAAAAhbydeAADlqwAAPFsAAAANAAC3xfdba7BGRNnqAAAAACFv
J14AAD6zEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEPfZREY5rAEAQgAAAEIAAAAAoLggMn8A
FcXtSy0IAEUAADRDfUAAQAa8vwoKE2IKChMSicoMvCYn3Q8LXhpJgBAYFqrWAAABAQgKALii1gAA
Flb32URGS6wBAOoFAADqBQAAABXF7UstAKC4IDJ/CABFAAXcRZoAAEAG9PoKChMSCgoTYgy8icoL
XhpJJifdD4AQgADkQAAAAQEICgAAFlYAuKLVEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQAAA8WwAAAA0A
ALfF91trsEZE2eoAAAAAIW8nXgAAPrMAADxbAAAADQAAt8b3W2uwRkTZ6gAAAAAhbydeAABbihAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAAADxbAAAADQAA
t8b3W2uwRkTZ6gAAAAAhbydeAABbigAAPFsAAAANAAC3x/dba7BGRNnqAAAAACFvJ14AAICSEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEAAAPFsAAAANAAC3
x/dba7BGRNnqAAAAACFvJ14AAICSAAA8WwAAAA0AALfI91trsEZE2eoAAAAAIW8nXgAAeV4QEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBD32URGZqwB
AOoFAADqBQAAABXF7UstAKC4IDJ/CABFAAXcRZsAAEAG9PkKChMSCgoTYgy8icoLXh/xJifdD4AQ
gADlfwAAAQEICgAAFlYAuKLVEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEAAAPFsAAAANAAC3yPdba7BGRNnqAAAAACFvJ14AAHleAAA8WwAAAA0AALfJ
91trsEZE2eoAAAAAIW8nXgAAokYQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQAAA8WwAAAA0AALfJ91trsEZE2eoAAAAAIW8nXgAAokYAADxbAAAADQAAt8r3
W2uwRkTZ6gAAAAAhbydeAADHfxAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAAADxbAAAADQAAt8r3W2uwRkTZ6gAAAAAhbydeAADHfwAAPFsAAAANAAC3y/db
a7BGRNnqAAAAACFvJ14AABxnEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBD32URGeawBAEIAAABCAAAA
AKC4IDJ/ABXF7UstCABFAAA0Q39AAEAGvL0KChNiCgoTEonKDLwmJ90PC14lmYAQGBafhgAAAQEI
CgC4otYAABZW99lERoysAQDqBQAA6gUAAAAVxe1LLQCguCAyfwgARQAF3EWcAABABvT4CgoTEgoK
E2IMvInKC14lmSYn3Q+AEIAAbvgAAAEBCAoAABZWALii1RAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQAAA8WwAAAA0AALfL91trsEZE2eoAAAAAIW8nXgAAHGcAADxbAAAADQAAt8z3W2uwRkTZ6gAA
AAAhbydeAAANDRAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAAADxbAAAADQAAt8z3W2uwRkTZ6gAAAAAhbydeAAANDQAAPFsAAAANAAC3zfdba7BGRNnqAAAA
ACFvJ14AANYVEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EAAAPFsAAAANAAC3zfdba7BGRNnqAAAAACFvJ14AANYVAAA8WwAAAA0AALfO91trsEZE2eoAAAAA
99lERrCsAQByAAAAcgAAAACguCAyfwAVxe1LLQgARQAAZEOBQABABryLCgoTYgoKExKJygy8Jifd
DwteK0GAGBgWOt4AAAEBCAoAuKLWAAAWVgHBAAAAAAAAAAAAAAAAAAAAEWJuAAAA8AAAtMkAALTK
EgHCAPAAAAAAAAAAAAAAAPfZREazrAEA6gUAAOoFAAAAFcXtSy0AoLggMn8IAEUABdxFnQAAQAb0
9woKExIKChNiDLyJygteK0EmJ90PgBCAADnsAAABAQgKAAAWVgC4otUhbydeAACzLBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAAADxbAAAADQAAt873W2uw
RkTZ6gAAAAAhbydeAACzLAAAPFsAAAANAAC3z/dba7BGRNnqAAAAACFvJ14AAGg0EBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEAAAPFsAAAANAAC3z/dba7BG
RNnqAAAAACFvJ14AAGg0AAA8WwAAAA0AALfQ91trsEZE2eoAAAAAIW8nXgAASKUQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEPfZREbZrAEA6gUAAOoFAAAAFcXtSy0AoLggMn8IAEUABdxFngAAQAb09goKExIKChNi
DLyJygteMOkmJ90PgBCAALLjAAABAQgKAAAWVgC4otUQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEAAAPFsAAAANAAC30Pdba7BGRNnqAAAAACFvJ14AAEilAAA8WwAAAA0AALfR91trsEZE
2eoAAAAAIW8nXgAAk70QEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQAAA8WwAAAA0AALfR91trsEZE2eoAAAAAIW8nXgAAk70AADxbAAAADQAAt9L3W2uwRkTZ
6gAAAAAhbydeAAD2hBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAAADxbAAAADQAAt9L3W2uwRkTZ6gAAAAAhbydeAAD2hAAAPFsAAAANAAC30/dba7BGRNnq
AAAAACFvJ14AAC2cEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEPfZ
REbqrAEAQgAAAEIAAAAAoLggMn8AFcXtSy0IAEUAADRDg0AAQAa8uQoKE2IKChMSicoMvCYn3T8L
XjaRgBAYFo5eAAABAQgKALii1gAAFlb32URG86wBAOoFAADqBQAAABXF7UstAKC4IDJ/CABFAAXc
RZ8AAEAG9PUKChMSCgoTYgy8icoLXjaRJifdD4AQgAA9sgAAAQEICgAAFlYAuKLVEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQAAA8
WwAAAA0AALfT91trsEZE2eoAAAAAIW8nXgAALZwAADxbAAAADQAAt9T3W2uwRkTZ6gAAAAAhbyde
AAA89hAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAAADxb
AAAADQAAt9T3W2uwRkTZ6gAAAAAhbydeAAA89gAAPFsAAAANAAC31fdba7BGRNnqAAAAACFvJ14A
AOfuEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEAAAPFsA
AAANAAC31fdba7BGRNnqAAAAACFvJ14AAOfuAAA8WwAAAA0AALfW91trsEZE2eoAAAAAIW8nXgAA
gtcQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBD32URG/KwBAHIAAAByAAAAABXF7UstAKC4IDJ9CABFAABkRaYAAEAG+mcK
ChMRCgoTYgy8icmkQGUFRDae3YAYgAB5XAAAAQEICgAAFlYAuKLVIYIAAAAAAAAAAAAAAAAAAAAR
hGQAAAAAAAC0zgAAtMwAALZLAAAAAAAAAAAAAEAA99lERiytAQDqBQAA6gUAAAAVxe1LLQCguCAy
fwgARQAF3EWgAABABvT0CgoTEgoKE2IMvInKC148OSYn3Q+AEIAAQJ0AAAEBCAoAABZWALii1RAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAAADxbAAAADQAAt9b3W2uwRkTZ6gAA
AAAhbydeAACC1wAAPFsAAAANAAC31/dba7BGRNnqAAAAACFvJ14AAFnPEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEAAAPFsAAAANAAC31/dba7BGRNnqAAAA
ACFvJ14AAFnPAAA8WwAAAA0AALfY91trsEZE2eoAAAAAIW8nXgAAoAMQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQAAA8WwAAAA0AALfY91trsEZE2eoAAAAA
IW8nXgAAoAMAADxbAAAADQAAt9n3W2uwRkTZ6gAAAAAhbydeAAB7GxAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQ99lERjatAQDqBQAA6gUAAAAVxe1LLQCguCAyfwgARQAF3EWh
AABABvTzCgoTEgoKE2IMvInKC15B4SYn3Q+AEIAAFlYAAAEBCAoAABZWALii1RAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
AAA8WwAAAA0AALfZ91trsEZE2eoAAAAAIW8nXgAAexsAADxbAAAADQAAt9r3W2uwRkTZ6gAAAAAh
bydeAAAeIhAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAA
ADxbAAAADQAAt9r3W2uwRkTZ6gAAAAAhbydeAAAeIgAAPFsAAAANAAC32/dba7BGRNnqAAAAACFv
J14AAMU6EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEAAA
PFsAAAANAAC32/dba7BGRNnqAAAAACFvJ14AAMU6AAA8WwAAAA0AALfc91trsEZE2eoAAAAAIW8n
XgAA1FAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
EBAQEBAQEBAQEBAQ

------_=_NextPart_001_01C7966E.FEBFC3DB
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

------_=_NextPart_001_01C7966E.FEBFC3DB--





From ips-bounces@ietf.org Fri May 18 01:03:21 2007
Return-path: <ips-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HoucT-00039G-IB; Fri, 18 May 2007 01:03:13 -0400
Received: from ips by megatron.ietf.org with local (Exim 4.43)
	id 1HoucS-00037G-Mx
	for ips-confirm+ok@megatron.ietf.org; Fri, 18 May 2007 01:03:12 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HoucS-000378-D2
	for ips@ietf.org; Fri, 18 May 2007 01:03:12 -0400
Received: from m70095e42.tmodns.net ([66.94.9.112]
	helo=svcstsnq08.hotspot.t-mobile.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HoucR-0006Mf-13
	for ips@ietf.org; Fri, 18 May 2007 01:03:12 -0400
Received: from IVVTDKV0981 (32.115.224.10.in-addr.arpa [10.224.115.32])
	by svcstsnq08.hotspot.t-mobile.com (8.13.7+Sun/8.12.10) with SMTP id
	l4I538MW010793; Thu, 17 May 2007 22:03:09 -0700 (PDT)
Message-ID: <001a01c79909$d4fc7a20$05faa8c0@ivivity.com>
From: "Eddy Quicksall" <Quicksall_iSCSI@Bellsouth.net>
To: "Ken Craig" <kcraig@istor.com>, <ips@ietf.org>
References: <9F3F0A752CAEBE4FA7E906CC2FBFF57C06D444@MERCURY.inside.istor.com>
Subject: Re: [Ips] StatSN question
Date: Fri, 18 May 2007 01:03:08 -0400
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-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlx=0
	adultscore=0 adjust=0 reason=mlx engine=3.1.0-0701160000
	definitions=main-0702270060
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f
Cc: 
X-BeenThere: ips@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IP Storage <ips.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ips>,
	<mailto:ips-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ips@ietf.org>
List-Help: <mailto:ips-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ips>,
	<mailto:ips-request@ietf.org?subject=subscribe>
Errors-To: ips-bounces@ietf.org

It would mean the header and data has been received. The reason is because 
the target can use ExpStatSN to free the resources used to send the Data-in. 
At ERL 0 it is faster to just use the TCP ACK; for ERL > 0 I think there was 
argument given once that the TCP ACK may not really indicate that the data 
was received and hence the ExpStatSN would be used for that purpose (I don't 
really remember that well though).

Eddy

----- Original Message ----- 
From: "Ken Craig" <kcraig@istor.com>
To: <ips@ietf.org>
Sent: Friday, April 27, 2007 5:23 PM
Subject: [Ips] StatSN question


I have a question about what ExpStatSN means that
I can't find an answer for in the reflector archives
or in any of the RFCs.

I, as an iSCSI Target running at ERL=0, send a
DATA IN PDU with FINAL=1 and a StatSN of 0.  I
receive a SCSI CMD PDU with an ExpStatSN of 1.
Does this mean that the Initiator has received
the PDU BHS and all of the data or is it simply
an acknowledgement that it has received the PDU
BHS?

Thanks,
Ken Craig


_______________________________________________
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 May 18 12:47:33 2007
Return-path: <ips-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Hp5c1-0007cb-Qs; Fri, 18 May 2007 12:47:29 -0400
Received: from ips by megatron.ietf.org with local (Exim 4.43)
	id 1Hp5c0-0007Yx-Hx
	for ips-confirm+ok@megatron.ietf.org; Fri, 18 May 2007 12:47:28 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Hp5c0-0007WX-37
	for ips@ietf.org; Fri, 18 May 2007 12:47:28 -0400
Received: from stork.istor.com ([12.170.66.34] helo=stork.inside.istor.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hp5bx-0006Md-OC
	for ips@ietf.org; Fri, 18 May 2007 12:47:28 -0400
Received: from mercury.inside.istor.com ([192.168.50.30])
	by stork.inside.istor.com with ESMTP; 18 May 2007 09:47:25 -0700
X-IronPort-AV: i="4.14,553,1170662400"; d="scan'208"; a="3480865:sNHT30513830"
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
Subject: RE: [Ips] StatSN question
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Fri, 18 May 2007 09:46:46 -0700
Message-ID: <9F3F0A752CAEBE4FA7E906CC2FBFF57C06D473@MERCURY.inside.istor.com>
In-Reply-To: <001a01c79909$d4fc7a20$05faa8c0@ivivity.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Ips] StatSN question
Thread-Index: AceZCdZzk62cC/5PRRKW/k/D62yudAAYftpQ
From: "Ken Craig" <kcraig@istor.com>
To: "Eddy Quicksall" <Quicksall_iSCSI@Bellsouth.net>,
	<ips@ietf.org>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab
Cc: 
X-BeenThere: ips@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IP Storage <ips.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ips>,
	<mailto:ips-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ips@ietf.org>
List-Help: <mailto:ips-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ips>,
	<mailto:ips-request@ietf.org?subject=subscribe>
Errors-To: ips-bounces@ietf.org

Eddy,

Thanks for the response.  I've got an Initiator
that is updating ExpStatSn before receiving all
of the data.  I consider that Initiator to be
broken but since the RFC doesn't specifically
state what you said I've got no choice but to
find a way to deal with it.

Ken Craig

-----Original Message-----
From: Eddy Quicksall [mailto:Quicksall_iSCSI@Bellsouth.net]=20
Sent: Thursday, May 17, 2007 10:03 PM
To: Ken Craig; ips@ietf.org
Subject: Re: [Ips] StatSN question


It would mean the header and data has been received. The reason is
because=20
the target can use ExpStatSN to free the resources used to send the
Data-in.=20
At ERL 0 it is faster to just use the TCP ACK; for ERL > 0 I think there
was=20
argument given once that the TCP ACK may not really indicate that the
data=20
was received and hence the ExpStatSN would be used for that purpose (I
don't=20
really remember that well though).

Eddy

----- Original Message -----=20
From: "Ken Craig" <kcraig@istor.com>
To: <ips@ietf.org>
Sent: Friday, April 27, 2007 5:23 PM
Subject: [Ips] StatSN question


I have a question about what ExpStatSN means that
I can't find an answer for in the reflector archives
or in any of the RFCs.

I, as an iSCSI Target running at ERL=3D0, send a
DATA IN PDU with FINAL=3D1 and a StatSN of 0.  I
receive a SCSI CMD PDU with an ExpStatSN of 1.
Does this mean that the Initiator has received
the PDU BHS and all of the data or is it simply
an acknowledgement that it has received the PDU
BHS?

Thanks,
Ken Craig


_______________________________________________
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 May 18 15:47:17 2007
Return-path: <ips-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Hp8Pv-0003KP-Lv; Fri, 18 May 2007 15:47:11 -0400
Received: from ips by megatron.ietf.org with local (Exim 4.43)
	id 1Hp8Pu-0003KK-DU
	for ips-confirm+ok@megatron.ietf.org; Fri, 18 May 2007 15:47:10 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Hp8Pt-0003K9-QC
	for ips@ietf.org; Fri, 18 May 2007 15:47:09 -0400
Received: from mtagate3.de.ibm.com ([195.212.29.152])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hp8Pt-0006g0-7p
	for ips@ietf.org; Fri, 18 May 2007 15:47:09 -0400
Received: from d12nrmr1607.megacenter.de.ibm.com
	(d12nrmr1607.megacenter.de.ibm.com [9.149.167.49])
	by mtagate3.de.ibm.com (8.13.8/8.13.8) with ESMTP id l4IJl8m3117086
	for <ips@ietf.org>; Fri, 18 May 2007 19:47:08 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.8/8.13.8/NCO v8.3) with
	ESMTP id l4IJl8Q43985540
	for <ips@ietf.org>; Fri, 18 May 2007 21:47:08 +0200
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 l4IJl7HI028904 for <ips@ietf.org>; Fri, 18 May 2007 21:47:08 +0200
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 l4IJl7pk028901; Fri, 18 May 2007 21:47:07 +0200
In-Reply-To: <001a01c79909$d4fc7a20$05faa8c0@ivivity.com>
To: "Eddy Quicksall" <Quicksall_iSCSI@Bellsouth.net>
MIME-Version: 1.0
Subject: Re: [Ips] StatSN question
X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006
From: Julian Satran <Julian_Satran@il.ibm.com>
Message-ID: <OFD6DB4058.4EB0CFA5-ONC22572DF.00379A98-C22572DF.006CAF50@il.ibm.com>
Date: Fri, 18 May 2007 22:47:06 +0300
X-MIMETrack: Serialize by Router on D12MC102/12/M/IBM(Release 7.0.2HF71 |
	November 3, 2006) at 18/05/2007 22:47:06,
	Serialize complete at 18/05/2007 22:47:06
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 202a3ece0492a8c7e7c8672d5214398f
Cc: ips@ietf.org
X-BeenThere: ips@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IP Storage <ips.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ips>,
	<mailto:ips-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ips@ietf.org>
List-Help: <mailto:ips-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ips>,
	<mailto:ips-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0903055467=="
Errors-To: ips-bounces@ietf.org

This is a multipart message in MIME format.
--===============0903055467==
Content-Type: multipart/alternative;
	boundary="=_alternative 003846BEC22572DF_="

This is a multipart message in MIME format.
--=_alternative 003846BEC22572DF_=
Content-Type: text/plain; charset="US-ASCII"

ExpStatSN indicates to the target that the initiator has received the 
status for the task and the target may discard whatever it may have hold 
for the task.
It also indicates to to the target when it is safe to send the response to 
a task abort or a "group" abort task management function.
Whether you can you use TCP ack for the same pupose dependes on how you 
stack is layered and/or how your recovery from end-to-end errors is done.

Julo



"Eddy Quicksall" <Quicksall_iSCSI@Bellsouth.net> 
18/05/07 08:03

To
"Ken Craig" <kcraig@istor.com>, <ips@ietf.org>
cc

Subject
Re: [Ips] StatSN question






It would mean the header and data has been received. The reason is because 

the target can use ExpStatSN to free the resources used to send the 
Data-in. 
At ERL 0 it is faster to just use the TCP ACK; for ERL > 0 I think there 
was 
argument given once that the TCP ACK may not really indicate that the data 

was received and hence the ExpStatSN would be used for that purpose (I 
don't 
really remember that well though).

Eddy

----- Original Message ----- 
From: "Ken Craig" <kcraig@istor.com>
To: <ips@ietf.org>
Sent: Friday, April 27, 2007 5:23 PM
Subject: [Ips] StatSN question


I have a question about what ExpStatSN means that
I can't find an answer for in the reflector archives
or in any of the RFCs.

I, as an iSCSI Target running at ERL=0, send a
DATA IN PDU with FINAL=1 and a StatSN of 0.  I
receive a SCSI CMD PDU with an ExpStatSN of 1.
Does this mean that the Initiator has received
the PDU BHS and all of the data or is it simply
an acknowledgement that it has received the PDU
BHS?

Thanks,
Ken Craig


_______________________________________________
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 003846BEC22572DF_=
Content-Type: text/html; charset="US-ASCII"


<br><font size=2 face="sans-serif">ExpStatSN indicates to the target that
the initiator has received the status for the task and the target may discard
whatever it may have hold for the task.</font>
<br><font size=2 face="sans-serif">It also indicates to to the target when
it is safe to send the response to a task abort or a &quot;group&quot;
abort task management function.</font>
<br><font size=2 face="sans-serif">Whether you can you use TCP ack for
the same pupose dependes on how you stack is layered and/or how your recovery
from end-to-end errors is done.</font>
<br>
<br><font size=2 face="sans-serif">Julo</font>
<br>
<br>
<br>
<table width=100%>
<tr valign=top>
<td width=40%><font size=1 face="sans-serif"><b>&quot;Eddy Quicksall&quot;
&lt;Quicksall_iSCSI@Bellsouth.net&gt;</b> </font>
<p><font size=1 face="sans-serif">18/05/07 08:03</font>
<td width=59%>
<table width=100%>
<tr valign=top>
<td>
<div align=right><font size=1 face="sans-serif">To</font></div>
<td><font size=1 face="sans-serif">&quot;Ken Craig&quot; &lt;kcraig@istor.com&gt;,
&lt;ips@ietf.org&gt;</font>
<tr valign=top>
<td>
<div align=right><font size=1 face="sans-serif">cc</font></div>
<td>
<tr valign=top>
<td>
<div align=right><font size=1 face="sans-serif">Subject</font></div>
<td><font size=1 face="sans-serif">Re: [Ips] StatSN question</font></table>
<br>
<table>
<tr valign=top>
<td>
<td></table>
<br></table>
<br>
<br>
<br><tt><font size=2>It would mean the header and data has been received.
The reason is because <br>
the target can use ExpStatSN to free the resources used to send the Data-in.
<br>
At ERL 0 it is faster to just use the TCP ACK; for ERL &gt; 0 I think there
was <br>
argument given once that the TCP ACK may not really indicate that the data
<br>
was received and hence the ExpStatSN would be used for that purpose (I
don't <br>
really remember that well though).<br>
<br>
Eddy<br>
<br>
----- Original Message ----- <br>
From: &quot;Ken Craig&quot; &lt;kcraig@istor.com&gt;<br>
To: &lt;ips@ietf.org&gt;<br>
Sent: Friday, April 27, 2007 5:23 PM<br>
Subject: [Ips] StatSN question<br>
<br>
<br>
I have a question about what ExpStatSN means that<br>
I can't find an answer for in the reflector archives<br>
or in any of the RFCs.<br>
<br>
I, as an iSCSI Target running at ERL=0, send a<br>
DATA IN PDU with FINAL=1 and a StatSN of 0. &nbsp;I<br>
receive a SCSI CMD PDU with an ExpStatSN of 1.<br>
Does this mean that the Initiator has received<br>
the PDU BHS and all of the data or is it simply<br>
an acknowledgement that it has received the PDU<br>
BHS?<br>
<br>
Thanks,<br>
Ken Craig<br>
<br>
<br>
_______________________________________________<br>
Ips mailing list<br>
Ips@ietf.org<br>
https://www1.ietf.org/mailman/listinfo/ips<br>
<br>
<br>
<br>
_______________________________________________<br>
Ips mailing list<br>
Ips@ietf.org<br>
https://www1.ietf.org/mailman/listinfo/ips<br>
</font></tt>
<br>
--=_alternative 003846BEC22572DF_=--



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

--===============0903055467==--





From ips-bounces@ietf.org Fri May 18 16:05:26 2007
Return-path: <ips-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Hp8hW-0007dg-79; Fri, 18 May 2007 16:05:22 -0400
Received: from ips by megatron.ietf.org with local (Exim 4.43)
	id 1Hp8hV-0007bn-CE
	for ips-confirm+ok@megatron.ietf.org; Fri, 18 May 2007 16:05:21 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Hp8hU-0007bf-Ql
	for ips@ietf.org; Fri, 18 May 2007 16:05:20 -0400
Received: from stork.istor.com ([12.170.66.34] helo=stork.inside.istor.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hp8hT-0003Fh-1j
	for ips@ietf.org; Fri, 18 May 2007 16:05:20 -0400
Received: from mercury.inside.istor.com ([192.168.50.30])
	by stork.inside.istor.com with ESMTP; 18 May 2007 13:05:18 -0700
X-IronPort-AV: i="4.14,553,1170662400"; 
	d="scan'208,217"; a="3482350:sNHT117541310"
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
Subject: RE: [Ips] StatSN question
MIME-Version: 1.0
Date: Fri, 18 May 2007 13:05:17 -0700
Message-ID: <9F3F0A752CAEBE4FA7E906CC2FBFF57C06D475@MERCURY.inside.istor.com>
In-Reply-To: <OFD6DB4058.4EB0CFA5-ONC22572DF.00379A98-C22572DF.006CAF50@il.ibm.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Ips] StatSN question
Thread-Index: AceZhVS82ubsRGV0Ttan5FjuqWTzjQAAhjIQ
From: "Ken Craig" <kcraig@istor.com>
To: "Julian Satran" <Julian_Satran@il.ibm.com>
X-Spam-Score: 0.7 (/)
X-Scan-Signature: 3f3e54d3c03ed638c06aa9fa6861237e
Cc: ips@ietf.org
X-BeenThere: ips@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IP Storage <ips.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ips>,
	<mailto:ips-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ips@ietf.org>
List-Help: <mailto:ips-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ips>,
	<mailto:ips-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0378481185=="
Errors-To: ips-bounces@ietf.org

This is a multi-part message in MIME format.

--===============0378481185==
Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C79987.DB1B88EB"

This is a multi-part message in MIME format.

------_=_NextPart_001_01C79987.DB1B88EB
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Julian,
=20
When you say "target may discard whatever it may have
hold for the task" aren't you saying the same thing as
Eddy.  That the ExpStatSN is an indication that the
Initiator has also received the data since resources would
have been used for the data.
=20
Thanks,
Ken Craig
=20
=20
 -----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]=20
Sent: Friday, May 18, 2007 12:47 PM
To: Eddy Quicksall
Cc: ips@ietf.org; Ken Craig
Subject: Re: [Ips] StatSN question




	ExpStatSN indicates to the target that the initiator has
received the status for the task and the target may discard whatever it
may have hold for the task.=20
	It also indicates to to the target when it is safe to send the
response to a task abort or a "group" abort task management function.=20
	Whether you can you use TCP ack for the same pupose dependes on
how you stack is layered and/or how your recovery from end-to-end errors
is done.=20
=09
	Julo=20
=09
=09
=09
"Eddy Quicksall" <Quicksall_iSCSI@Bellsouth.net>=20

18/05/07 08:03=20

To
"Ken Craig" <kcraig@istor.com>, <ips@ietf.org>=20
cc
Subject
Re: [Ips] StatSN question

=09




	It would mean the header and data has been received. The reason
is because=20
	the target can use ExpStatSN to free the resources used to send
the Data-in.=20
	At ERL 0 it is faster to just use the TCP ACK; for ERL > 0 I
think there was=20
	argument given once that the TCP ACK may not really indicate
that the data=20
	was received and hence the ExpStatSN would be used for that
purpose (I don't=20
	really remember that well though).
=09
	Eddy
=09
	----- Original Message -----=20
	From: "Ken Craig" <kcraig@istor.com>
	To: <ips@ietf.org>
	Sent: Friday, April 27, 2007 5:23 PM
	Subject: [Ips] StatSN question
=09
=09
	I have a question about what ExpStatSN means that
	I can't find an answer for in the reflector archives
	or in any of the RFCs.
=09
	I, as an iSCSI Target running at ERL=3D0, send a
	DATA IN PDU with FINAL=3D1 and a StatSN of 0.  I
	receive a SCSI CMD PDU with an ExpStatSN of 1.
	Does this mean that the Initiator has received
	the PDU BHS and all of the data or is it simply
	an acknowledgement that it has received the PDU
	BHS?
=09
	Thanks,
	Ken Craig
=09
=09
	_______________________________________________
	Ips mailing list
	Ips@ietf.org
	https://www1.ietf.org/mailman/listinfo/ips
=09
=09
=09
	_______________________________________________
	Ips mailing list
	Ips@ietf.org
	https://www1.ietf.org/mailman/listinfo/ips
=09
=09


------_=_NextPart_001_01C79987.DB1B88EB
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>Message</TITLE>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2800.1593" name=3DGENERATOR></HEAD>
<BODY>
<DIV><SPAN class=3D112140220-18052007><FONT face=3DArial color=3D#0000ff =

size=3D2>Julian,</FONT></SPAN></DIV>
<DIV><SPAN class=3D112140220-18052007><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D112140220-18052007><FONT face=3DArial color=3D#0000ff =
size=3D2>When=20
you say&nbsp;"target may discard whatever it may =
have</FONT></SPAN></DIV>
<DIV><FONT face=3DArial><FONT size=3D2><FONT color=3D#0000ff><SPAN=20
class=3D112140220-18052007>hold for the task" aren't you saying the same =
thing=20
as</SPAN></FONT></FONT></FONT></DIV>
<DIV><FONT face=3DArial><FONT size=3D2><FONT color=3D#0000ff><SPAN=20
class=3D112140220-18052007>Eddy.&nbsp; That the ExpStatSN is an =
indication that=20
the</SPAN></FONT></FONT></FONT></DIV>
<DIV><FONT face=3DArial><FONT size=3D2><FONT color=3D#0000ff><SPAN=20
class=3D112140220-18052007>Initiator has also received the data since =
resources=20
would</SPAN></FONT></FONT></FONT></DIV>
<DIV><FONT face=3DArial><FONT size=3D2><FONT color=3D#0000ff><SPAN=20
class=3D112140220-18052007>have been used for the=20
data.</SPAN></FONT></FONT></FONT></DIV>
<DIV><FONT face=3DArial><FONT size=3D2><FONT color=3D#0000ff><SPAN=20
class=3D112140220-18052007></SPAN></FONT></FONT></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial><FONT size=3D2><FONT color=3D#0000ff><SPAN=20
class=3D112140220-18052007>Thanks,</SPAN></FONT></FONT></FONT></DIV>
<DIV><FONT face=3DArial><FONT size=3D2><FONT color=3D#0000ff><SPAN=20
class=3D112140220-18052007>Ken Craig</SPAN></FONT></FONT></FONT></DIV>
<DIV><FONT face=3DArial><FONT size=3D2><FONT color=3D#0000ff><SPAN=20
class=3D112140220-18052007></SPAN></FONT></FONT></FONT>&nbsp;</DIV>
<DIV><FONT face=3DTahoma><FONT size=3D2><SPAN =
class=3D112140220-18052007><FONT=20
face=3DArial color=3D#0000ff>&nbsp;</FONT></SPAN></FONT></FONT></DIV>
<DIV><FONT face=3DTahoma><FONT size=3D2><SPAN=20
class=3D112140220-18052007>&nbsp;</SPAN>-----Original =
Message-----<BR><B>From:</B>=20
Julian Satran [mailto:Julian_Satran@il.ibm.com] <BR><B>Sent:</B> Friday, =
May 18,=20
2007 12:47 PM<BR><B>To:</B> Eddy Quicksall<BR><B>Cc:</B> ips@ietf.org; =
Ken=20
Craig<BR><B>Subject:</B> Re: [Ips] StatSN =
question<BR><BR></DIV></FONT></FONT>
<BLOCKQUOTE style=3D"MARGIN-RIGHT: 0px"><BR><FONT face=3Dsans-serif=20
  size=3D2>ExpStatSN indicates to the target that the initiator has =
received the=20
  status for the task and the target may discard whatever it may have =
hold for=20
  the task.</FONT> <BR><FONT face=3Dsans-serif size=3D2>It also =
indicates to to the=20
  target when it is safe to send the response to a task abort or a =
"group" abort=20
  task management function.</FONT> <BR><FONT face=3Dsans-serif =
size=3D2>Whether you=20
  can you use TCP ack for the same pupose dependes on how you stack is =
layered=20
  and/or how your recovery from end-to-end errors is done.</FONT> =
<BR><BR><FONT=20
  face=3Dsans-serif size=3D2>Julo</FONT> <BR><BR><BR>
  <TABLE width=3D"100%">
    <TBODY>
    <TR vAlign=3Dtop>
      <TD width=3D"40%"><FONT face=3Dsans-serif size=3D1><B>"Eddy =
Quicksall"=20
        &lt;Quicksall_iSCSI@Bellsouth.net&gt;</B> </FONT>
        <P><FONT face=3Dsans-serif size=3D1>18/05/07 08:03</FONT> </P>
      <TD width=3D"59%">
        <TABLE width=3D"100%">
          <TBODY>
          <TR vAlign=3Dtop>
            <TD>
              <DIV align=3Dright><FONT face=3Dsans-serif =
size=3D1>To</FONT></DIV>
            <TD><FONT face=3Dsans-serif size=3D1>"Ken Craig"=20
              &lt;kcraig@istor.com&gt;, &lt;ips@ietf.org&gt;</FONT>=20
          <TR vAlign=3Dtop>
            <TD>
              <DIV align=3Dright><FONT face=3Dsans-serif =
size=3D1>cc</FONT></DIV>
            <TD>
          <TR vAlign=3Dtop>
            <TD>
              <DIV align=3Dright><FONT face=3Dsans-serif =
size=3D1>Subject</FONT></DIV>
            <TD><FONT face=3Dsans-serif size=3D1>Re: [Ips] StatSN=20
          question</FONT></TR></TBODY></TABLE><BR>
        <TABLE>
          <TBODY>
          <TR vAlign=3Dtop>
            <TD>
            =
<TD></TR></TBODY></TABLE><BR></TR></TBODY></TABLE><BR><BR><BR><TT><FONT=20
  size=3D2>It would mean the header and data has been received. The =
reason is=20
  because <BR>the target can use ExpStatSN to free the resources used to =
send=20
  the Data-in. <BR>At ERL 0 it is faster to just use the TCP ACK; for =
ERL &gt; 0=20
  I think there was <BR>argument given once that the TCP ACK may not =
really=20
  indicate that the data <BR>was received and hence the ExpStatSN would =
be used=20
  for that purpose (I don't <BR>really remember that well=20
  though).<BR><BR>Eddy<BR><BR>----- Original Message ----- <BR>From: =
"Ken Craig"=20
  &lt;kcraig@istor.com&gt;<BR>To: &lt;ips@ietf.org&gt;<BR>Sent: Friday, =
April=20
  27, 2007 5:23 PM<BR>Subject: [Ips] StatSN question<BR><BR><BR>I have a =

  question about what ExpStatSN means that<BR>I can't find an answer for =
in the=20
  reflector archives<BR>or in any of the RFCs.<BR><BR>I, as an iSCSI =
Target=20
  running at ERL=3D0, send a<BR>DATA IN PDU with FINAL=3D1 and a StatSN =
of 0.=20
  &nbsp;I<BR>receive a SCSI CMD PDU with an ExpStatSN of 1.<BR>Does this =
mean=20
  that the Initiator has received<BR>the PDU BHS and all of the data or =
is it=20
  simply<BR>an acknowledgement that it has received the=20
  PDU<BR>BHS?<BR><BR>Thanks,<BR>Ken=20
  =
Craig<BR><BR><BR>_______________________________________________<BR>Ips=20
  mailing=20
  =
list<BR>Ips@ietf.org<BR>https://www1.ietf.org/mailman/listinfo/ips<BR><BR=
><BR><BR>_______________________________________________<BR>Ips=20
  mailing=20
  =
list<BR>Ips@ietf.org<BR>https://www1.ietf.org/mailman/listinfo/ips<BR></F=
ONT></TT><BR></BLOCKQUOTE></BODY></HTML>
=00
------_=_NextPart_001_01C79987.DB1B88EB--



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

--===============0378481185==--





From ips-bounces@ietf.org Fri May 18 16:15:21 2007
Return-path: <ips-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Hp8r8-0007GA-M4; Fri, 18 May 2007 16:15:18 -0400
Received: from ips by megatron.ietf.org with local (Exim 4.43)
	id 1Hp8r6-0007Bk-Og
	for ips-confirm+ok@megatron.ietf.org; Fri, 18 May 2007 16:15:16 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Hp8r6-00078D-BG
	for ips@ietf.org; Fri, 18 May 2007 16:15:16 -0400
Received: from mtagate7.de.ibm.com ([195.212.29.156])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hp8r5-0005DJ-GP
	for ips@ietf.org; Fri, 18 May 2007 16:15:16 -0400
Received: from d12nrmr1607.megacenter.de.ibm.com
	(d12nrmr1607.megacenter.de.ibm.com [9.149.167.49])
	by mtagate7.de.ibm.com (8.13.8/8.13.8) with ESMTP id l4IKFEQ4335014
	for <ips@ietf.org>; Fri, 18 May 2007 20:15:14 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.8/8.13.8/NCO v8.3) with
	ESMTP id l4IKFEKU3985630
	for <ips@ietf.org>; Fri, 18 May 2007 22:15:14 +0200
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 l4IKFEst008035 for <ips@ietf.org>; Fri, 18 May 2007 22:15:14 +0200
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 l4IKFE6e008032; Fri, 18 May 2007 22:15:14 +0200
In-Reply-To: <9F3F0A752CAEBE4FA7E906CC2FBFF57C06D475@MERCURY.inside.istor.com>
To: "Ken Craig" <kcraig@istor.com>
MIME-Version: 1.0
Subject: RE: [Ips] StatSN question
X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006
From: Julian Satran <Julian_Satran@il.ibm.com>
Message-ID: <OFC0ABF011.92770042-ONC22572DF.006EFE9D-C22572DF.006F4203@il.ibm.com>
Date: Fri, 18 May 2007 23:15:13 +0300
X-MIMETrack: Serialize by Router on D12MC102/12/M/IBM(Release 7.0.2HF71 |
	November 3, 2006) at 18/05/2007 23:15:13,
	Serialize complete at 18/05/2007 23:15:13
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 10d2fdecab7a7fa796e06e001d026c91
Cc: ips@ietf.org
X-BeenThere: ips@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IP Storage <ips.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ips>,
	<mailto:ips-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ips@ietf.org>
List-Help: <mailto:ips-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ips>,
	<mailto:ips-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0133712697=="
Errors-To: ips-bounces@ietf.org

This is a multipart message in MIME format.
--===============0133712697==
Content-Type: multipart/alternative;
	boundary="=_alternative 006F40B0C22572DF_="

This is a multipart message in MIME format.
--=_alternative 006F40B0C22572DF_=
Content-Type: text/plain; charset="US-ASCII"

Definitely yes (acknowledging the status is equivalent to acking all the 
data). In addition resources are help to enable status retransmission even 
in commands that do not have data transfers. Julo



"Ken Craig" <kcraig@istor.com> 
18/05/07 23:05

To
Julian Satran/Haifa/IBM@IBMIL
cc
<ips@ietf.org>
Subject
RE: [Ips] StatSN question






Julian,
 
When you say "target may discard whatever it may have
hold for the task" aren't you saying the same thing as
Eddy.  That the ExpStatSN is an indication that the
Initiator has also received the data since resources would
have been used for the data.
 
Thanks,
Ken Craig
 
 
 -----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com] 
Sent: Friday, May 18, 2007 12:47 PM
To: Eddy Quicksall
Cc: ips@ietf.org; Ken Craig
Subject: Re: [Ips] StatSN question


ExpStatSN indicates to the target that the initiator has received the 
status for the task and the target may discard whatever it may have hold 
for the task. 
It also indicates to to the target when it is safe to send the response to 
a task abort or a "group" abort task management function. 
Whether you can you use TCP ack for the same pupose dependes on how you 
stack is layered and/or how your recovery from end-to-end errors is done. 

Julo 


"Eddy Quicksall" <Quicksall_iSCSI@Bellsouth.net> 
18/05/07 08:03 


To
"Ken Craig" <kcraig@istor.com>, <ips@ietf.org> 
cc

Subject
Re: [Ips] StatSN question








It would mean the header and data has been received. The reason is because 

the target can use ExpStatSN to free the resources used to send the 
Data-in. 
At ERL 0 it is faster to just use the TCP ACK; for ERL > 0 I think there 
was 
argument given once that the TCP ACK may not really indicate that the data 

was received and hence the ExpStatSN would be used for that purpose (I 
don't 
really remember that well though).

Eddy

----- Original Message ----- 
From: "Ken Craig" <kcraig@istor.com>
To: <ips@ietf.org>
Sent: Friday, April 27, 2007 5:23 PM
Subject: [Ips] StatSN question


I have a question about what ExpStatSN means that
I can't find an answer for in the reflector archives
or in any of the RFCs.

I, as an iSCSI Target running at ERL=0, send a
DATA IN PDU with FINAL=1 and a StatSN of 0.  I
receive a SCSI CMD PDU with an ExpStatSN of 1.
Does this mean that the Initiator has received
the PDU BHS and all of the data or is it simply
an acknowledgement that it has received the PDU
BHS?

Thanks,
Ken Craig


_______________________________________________
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 006F40B0C22572DF_=
Content-Type: text/html; charset="US-ASCII"


<br><font size=2 face="sans-serif">Definitely yes (acknowledging the status
is equivalent to acking all the data). In addition resources are help to
enable status retransmission even in commands that do not have data transfers.
Julo</font>
<br>
<br>
<br>
<table width=100%>
<tr valign=top>
<td width=40%><font size=1 face="sans-serif"><b>&quot;Ken Craig&quot; &lt;kcraig@istor.com&gt;</b>
</font>
<p><font size=1 face="sans-serif">18/05/07 23:05</font>
<td width=59%>
<table width=100%>
<tr valign=top>
<td>
<div align=right><font size=1 face="sans-serif">To</font></div>
<td><font size=1 face="sans-serif">Julian Satran/Haifa/IBM@IBMIL</font>
<tr valign=top>
<td>
<div align=right><font size=1 face="sans-serif">cc</font></div>
<td><font size=1 face="sans-serif">&lt;ips@ietf.org&gt;</font>
<tr valign=top>
<td>
<div align=right><font size=1 face="sans-serif">Subject</font></div>
<td><font size=1 face="sans-serif">RE: [Ips] StatSN question</font></table>
<br>
<table>
<tr valign=top>
<td>
<td></table>
<br></table>
<br>
<br>
<br><font size=2 color=blue face="Arial">Julian,</font>
<br><font size=3>&nbsp;</font>
<br><font size=2 color=blue face="Arial">When you say &quot;target may
discard whatever it may have</font>
<br><font size=2 color=blue face="Arial">hold for the task&quot; aren't
you saying the same thing as</font>
<br><font size=2 color=blue face="Arial">Eddy. &nbsp;That the ExpStatSN
is an indication that the</font>
<br><font size=2 color=blue face="Arial">Initiator has also received the
data since resources would</font>
<br><font size=2 color=blue face="Arial">have been used for the data.</font>
<br><font size=3>&nbsp;</font>
<br><font size=2 color=blue face="Arial">Thanks,</font>
<br><font size=2 color=blue face="Arial">Ken Craig</font>
<br><font size=3>&nbsp;</font>
<br><font size=2 color=blue face="Arial">&nbsp;</font>
<br><font size=2 face="Tahoma">&nbsp;-----Original Message-----<b><br>
From:</b> Julian Satran [mailto:Julian_Satran@il.ibm.com] <b><br>
Sent:</b> Friday, May 18, 2007 12:47 PM<b><br>
To:</b> Eddy Quicksall<b><br>
Cc:</b> ips@ietf.org; Ken Craig<b><br>
Subject:</b> Re: [Ips] StatSN question<br>
</font>
<br><font size=2 face="sans-serif"><br>
ExpStatSN indicates to the target that the initiator has received the status
for the task and the target may discard whatever it may have hold for the
task.</font><font size=3> </font><font size=2 face="sans-serif"><br>
It also indicates to to the target when it is safe to send the response
to a task abort or a &quot;group&quot; abort task management function.</font><font size=3>
</font><font size=2 face="sans-serif"><br>
Whether you can you use TCP ack for the same pupose dependes on how you
stack is layered and/or how your recovery from end-to-end errors is done.</font><font size=3>
<br>
</font><font size=2 face="sans-serif"><br>
Julo</font><font size=3> <br>
<br>
</font>
<table width=100%>
<tr valign=top>
<td width=51%><font size=1 face="sans-serif"><b>&quot;Eddy Quicksall&quot;
&lt;Quicksall_iSCSI@Bellsouth.net&gt;</b> </font>
<p><font size=1 face="sans-serif">18/05/07 08:03</font><font size=3> </font>
<td width=48%>
<br>
<table width=100%>
<tr valign=top>
<td width=14%>
<div align=right><font size=1 face="sans-serif">To</font></div>
<td width=85%><font size=1 face="sans-serif">&quot;Ken Craig&quot; &lt;kcraig@istor.com&gt;,
&lt;ips@ietf.org&gt;</font><font size=3> </font>
<tr valign=top>
<td>
<div align=right><font size=1 face="sans-serif">cc</font></div>
<td>
<tr valign=top>
<td>
<div align=right><font size=1 face="sans-serif">Subject</font></div>
<td><font size=1 face="sans-serif">Re: [Ips] StatSN question</font></table>
<br>
<br>
<table width=100%>
<tr valign=top>
<td width=50%>
<td width=50%></table>
<br></table>
<br><font size=3><br>
<br>
</font><tt><font size=2><br>
It would mean the header and data has been received. The reason is because
<br>
the target can use ExpStatSN to free the resources used to send the Data-in.
<br>
At ERL 0 it is faster to just use the TCP ACK; for ERL &gt; 0 I think there
was <br>
argument given once that the TCP ACK may not really indicate that the data
<br>
was received and hence the ExpStatSN would be used for that purpose (I
don't <br>
really remember that well though).<br>
<br>
Eddy<br>
<br>
----- Original Message ----- <br>
From: &quot;Ken Craig&quot; &lt;kcraig@istor.com&gt;<br>
To: &lt;ips@ietf.org&gt;<br>
Sent: Friday, April 27, 2007 5:23 PM<br>
Subject: [Ips] StatSN question<br>
<br>
<br>
I have a question about what ExpStatSN means that<br>
I can't find an answer for in the reflector archives<br>
or in any of the RFCs.<br>
<br>
I, as an iSCSI Target running at ERL=0, send a<br>
DATA IN PDU with FINAL=1 and a StatSN of 0. &nbsp;I<br>
receive a SCSI CMD PDU with an ExpStatSN of 1.<br>
Does this mean that the Initiator has received<br>
the PDU BHS and all of the data or is it simply<br>
an acknowledgement that it has received the PDU<br>
BHS?<br>
<br>
Thanks,<br>
Ken Craig<br>
<br>
<br>
_______________________________________________<br>
Ips mailing list<br>
Ips@ietf.org<br>
https://www1.ietf.org/mailman/listinfo/ips<br>
<br>
<br>
<br>
_______________________________________________<br>
Ips mailing list<br>
Ips@ietf.org<br>
https://www1.ietf.org/mailman/listinfo/ips</font></tt><font size=3><br>
</font>
<br>
--=_alternative 006F40B0C22572DF_=--



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

--===============0133712697==--





From ips-bounces@ietf.org Sat May 19 16:05:42 2007
Return-path: <ips-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HpVBJ-0000zN-FS; Sat, 19 May 2007 16:05:37 -0400
Received: from ips by megatron.ietf.org with local (Exim 4.43)
	id 1HpVBI-0000xX-2o
	for ips-confirm+ok@megatron.ietf.org; Sat, 19 May 2007 16:05:36 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HpVBH-0000w4-Ou
	for ips@ietf.org; Sat, 19 May 2007 16:05:35 -0400
Received: from imo-d05.mx.aol.com ([205.188.157.37])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HpVBF-0005Rk-6J
	for ips@ietf.org; Sat, 19 May 2007 16:05:35 -0400
Received: from ISCSIPerson@aol.com
	by imo-d05.mx.aol.com (mail_out_v38_r9.2.) id 9.d61.8adfc58 (60434);
	Sat, 19 May 2007 16:05:20 -0400 (EDT)
Received: from mblk-r15 (mblk-r15.mblk.aol.com [152.163.211.206]) by
	ciaaol-d01.mail.aol.com (v115.11) with ESMTP id
	MAILCIAAOLD013-ec12464f5880182; Sat, 19 May 2007 16:05:20 -0400
To: Julian_Satran@il.ibm.com, kcraig@istor.com
Subject: Re: [Ips] StatSN question
Date: Sat, 19 May 2007 16:05:20 -0400
In-Reply-To: <OFC0ABF011.92770042-ONC22572DF.006EFE9D-C22572DF.006F4203@il.ibm.com>
X-MB-Message-Source: WebUI
Received: from 75.36.181.121 by mblk-r15.sysops.aol.com (152.163.211.206) with
	HTTP (WebMailUI); Sat, 19 May 2007 16:05:20 -0400
MIME-Version: 1.0
From: iscsiperson@aol.com
X-MB-Message-Type: User
X-Mailer: AOL WebMail 25698
Message-Id: <8C968682942742D-6E8-6589@mblk-r15.sysops.aol.com>
X-AOL-IP: 152.163.211.206
X-Spam-Flag: NO
X-Spam-Score: 0.4 (/)
X-Scan-Signature: e3ebaaff3b3539efaf29ef65eea2aded
Cc: ips@ietf.org
X-BeenThere: ips@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IP Storage <ips.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ips>,
	<mailto:ips-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ips@ietf.org>
List-Help: <mailto:ips-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ips>,
	<mailto:ips-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1464870895=="
Errors-To: ips-bounces@ietf.org


--===============1464870895==
Content-Type: multipart/alternative; 
	boundary="--------MB_8C968682942742D_6E8_AF1D_mblk-r15.sysops.aol.com"


----------MB_8C968682942742D_6E8_AF1D_mblk-r15.sysops.aol.com
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"

In the original message, Ken did NOT say that the "S" bit was set to 1 in the last Data-In PDU.
 
According to the RFC (3270) - Section 10.7.3"
 
"The fields StatSN, Status, and Residual Count only have meaningful content if the S bit is set to 1 and their values are defined in Section 10.4 SCSI Response." 
My interpretation of that section would be that the iSCSI Initiator should NOT have sent ExpStatSN=1, until the SCSI Response PDU was received.
 
Take Care,
 
Greg Alvey
Solution Technoloy
www.soltechnology.com
 
 
-----Original Message-----
From: Julian_Satran@il.ibm.com
To: kcraig@istor.com
Cc: ips@ietf.org
Sent: Fri, 18 May 2007 1:15 PM
Subject: RE: [Ips] StatSN question



Definitely yes (acknowledging the status is equivalent to acking all the data). In addition resources are help to enable status retransmission even in commands that do not have data transfers. Julo 


"Ken Craig" <kcraig@istor.com> 
18/05/07 23:05 ToJulian Satran/Haifa/IBM@IBMIL 
cc<ips@ietf.org> 
SubjectRE: [Ips] StatSN question







Julian, 
  
When you say "target may discard whatever it may have 
hold for the task" aren't you saying the same thing as 
Eddy.  That the ExpStatSN is an indication that the 
Initiator has also received the data since resources would 
have been used for the data. 
  
Thanks, 
Ken Craig 
  
  
 -----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com] 
Sent: Friday, May 18, 2007 12:47 PM
To: Eddy Quicksall
Cc: ips@ietf.org; Ken Craig
Subject: Re: [Ips] StatSN question


ExpStatSN indicates to the target that the initiator has received the status for the task and the target may discard whatever it may have hold for the task. 
It also indicates to to the target when it is safe to send the response to a task abort or a "group" abort task management function. 
Whether you can you use TCP ack for the same pupose dependes on how you stack is layered and/or how your recovery from end-to-end errors is done. 

Julo 

"Eddy Quicksall" <Quicksall_iSCSI@Bellsouth.net> 
18/05/07 08:03 
To"Ken Craig" <kcraig@istor.com>, <ips@ietf.org> 
cc
SubjectRe: [Ips] StatSN question









It would mean the header and data has been received. The reason is because 
the target can use ExpStatSN to free the resources used to send the Data-in. 
At ERL 0 it is faster to just use the TCP ACK; for ERL > 0 I think there was 
argument given once that the TCP ACK may not really indicate that the data 
was received and hence the ExpStatSN would be used for that purpose (I don't 
really remember that well though).

Eddy

----- Original Message ----- 
From: "Ken Craig" <kcraig@istor.com>
To: <ips@ietf.org>
Sent: Friday, April 27, 2007 5:23 PM
Subject: [Ips] StatSN question


I have a question about what ExpStatSN means that
I can't find an answer for in the reflector archives
or in any of the RFCs.

I, as an iSCSI Target running at ERL=0, send a
DATA IN PDU with FINAL=1 and a StatSN of 0.  I
receive a SCSI CMD PDU with an ExpStatSN of 1.
Does this mean that the Initiator has received
the PDU BHS and all of the data or is it simply
an acknowledgement that it has received the PDU
BHS?

Thanks,
Ken Craig


_______________________________________________
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
________________________________________________________________________
AOL now offers free email to everyone.  Find out more about what's free from AOL at AOL.com.

----------MB_8C968682942742D_6E8_AF1D_mblk-r15.sysops.aol.com
Content-Transfer-Encoding: 7bit
Content-Type: text/html; charset="us-ascii"

<HTML><BODY>
<div>In the original message, Ken did NOT say that the "S" bit was set to 1 in the last Data-In PDU.</div>


<div>&nbsp;</div>


<div>According to the RFC (3270) - Section 10.7.3"</div>


<div>&nbsp;</div>


<div>"<FONT size=2>The fields StatSN, Status, and Residual Count only have meaningful content if the S bit is set to 1 and their values are defined in Section 10.4 SCSI Response.</FONT>"<SPAN contentEditable=false style="DISPLAY: inline-block"></SPAN></div>


<div>&nbsp;</div>


<div>My interpretation of that section would be that the iSCSI Initiator should NOT have sent ExpStatSN=1, until the SCSI Response PDU was received.</div>


<div>&nbsp;</div>


<div>Take Care,</div>


<div>&nbsp;</div>


<div>Greg Alvey</div>


<div>Solution Technoloy</div>


<div><A href="http://www.soltechnology.com">www.soltechnology.com</A></div>


<div>&nbsp;</div>
&nbsp;<br>
-----Original Message-----<br>
From: Julian_Satran@il.ibm.com<br>
To: kcraig@istor.com<br>
Cc: ips@ietf.org<br>
Sent: Fri, 18 May 2007 1:15 PM<br>
Subject: RE: [Ips] StatSN question<br>
<br>

<STYLE>
.AOLPlainTextBody {
    margin: 0px;
    font-family: Tahoma, Verdana, Arial, Sans-Serif;
    font-size: 12px; 
    color: #000; 
    background-color: #fff; 
}

.AOLPlainTextBody pre {
    font-size: 9pt;
}

.AOLInlineAttachment {
    margin: 10px;
}

.AOLAttachmentHeader {
    font: 11px arial;
    border: 1px solid #7DA8D4;
    background: #F9F9F9;
}

.AOLAttachmentHeader .Title {
    font: 11px arial;
    background: #B5DDFA;
    padding: 3px 3px 3px 3px;
}

.AOLAttachmentHeader .FieldLabel {
    font: 11px arial; 
    color: #000000;
    padding: 1px 10px 1px 9px;
    background: #F9F9F9;
}

.AOLAttachmentHeader .FieldValue {
    font: 11px arial; 
    color: #000000;
    background: #F9F9F9;
}

.AOLAttachmentHeader a, .AOLImage a {
    color: #2864B4;
    text-decoration: none;
}

.AOLAttachmentHeader a:hover, .AOLImage a:hover {
    color: #2864B4;
    text-decoration: underline;
}

.AOLWebSuiteCompose .AOLPicturesFullSizeLink,
.AOLWebSuite .AOLPicturesFullSizeLink {
    height: 1px;
    width: 1px;
    overflow: hidden;
}

body {
    background-color: white;
    font-family: "Verdana";
    font-size: 10pt;
    border: 0px;
}

.AOLWebSuiteCompose p {
    margin: 0px;
    padding: 0px;
}

img.managedImg {
    width: 0px;
    height: 0px;
}

img.placeholder {
    width: 275px;
    height: 206px;
    background: #F4F4F4 center center no-repeat;
    border: 1px solid #DADAD6 !important;  
}

</STYLE>


<div id=AOLMsgPart_3_abed8725-160a-4b2f-876b-baef25f22025><br>
<FONT face=sans-serif size=2>Definitely yes (acknowledging the status is equivalent to acking all the data). In addition resources are help to enable status retransmission even in commands that do not have data transfers. Julo</FONT> <br>
<br>
<br>

<TABLE width="100%">
<TBODY>
<TR vAlign=top>
<TD width="40%"><FONT face=sans-serif size=1><B>"Ken Craig" &lt;<A href='javascript:parent.ComposeTo("kcraig%40istor.com", "");'>kcraig@istor.com</A>&gt;</B> </FONT>

<div><FONT face=sans-serif size=1>18/05/07 23:05</FONT> </div>

<TD width="59%">
<TABLE width="100%">
<TBODY>
<TR vAlign=top>
<TD>

<div align=right><FONT face=sans-serif size=1>To</FONT></div>

<TD><FONT face=sans-serif size=1>Julian Satran/Haifa/IBM@IBMIL</FONT> 
<TR vAlign=top>
<TD>

<div align=right><FONT face=sans-serif size=1>cc</FONT></div>

<TD><FONT face=sans-serif size=1>&lt;<A href='javascript:parent.ComposeTo("ips%40ietf.org", "");'>ips@ietf.org</A>&gt;</FONT> 
<TR vAlign=top>
<TD>

<div align=right><FONT face=sans-serif size=1>Subject</FONT></div>

<TD><FONT face=sans-serif size=1>RE: [Ips] StatSN question</FONT></TD></TR></TBODY></TABLE><br>

<TABLE>
<TBODY>
<TR vAlign=top>
<TD>
<TD></TD></TR></TBODY></TABLE><br>
</TD></TR></TBODY></TABLE><br>
<br>
<br>
<FONT face=Arial color=blue size=2>Julian,</FONT> <br>
<FONT size=3>&nbsp;</FONT> <br>
<FONT face=Arial color=blue size=2>When you say "target may discard whatever it may have</FONT> <br>
<FONT face=Arial color=blue size=2>hold for the task" aren't you saying the same thing as</FONT> <br>
<FONT face=Arial color=blue size=2>Eddy. &nbsp;That the ExpStatSN is an indication that the</FONT> <br>
<FONT face=Arial color=blue size=2>Initiator has also received the data since resources would</FONT> <br>
<FONT face=Arial color=blue size=2>have been used for the data.</FONT> <br>
<FONT size=3>&nbsp;</FONT> <br>
<FONT face=Arial color=blue size=2>Thanks,</FONT> <br>
<FONT face=Arial color=blue size=2>Ken Craig</FONT> <br>
<FONT size=3>&nbsp;</FONT> <br>
<FONT face=Arial color=blue size=2>&nbsp;</FONT> <br>
<FONT face=Tahoma size=2>&nbsp;-----Original Message-----<B><br>
From:</B> Julian Satran [<A href='javascript:parent.ComposeTo("Julian_Satran%40il.ibm.com", "");'>mailto:Julian_Satran@il.ibm.com</A>] <B><br>
Sent:</B> Friday, May 18, 2007 12:47 PM<B><br>
To:</B> Eddy Quicksall<B><br>
Cc:</B> <A href='javascript:parent.ComposeTo("ips%40ietf.org", "");'>ips@ietf.org</A>; Ken Craig<B><br>
Subject:</B> Re: [Ips] StatSN question<br>
</FONT><br>
<FONT face=sans-serif size=2><br>
ExpStatSN indicates to the target that the initiator has received the status for the task and the target may discard whatever it may have hold for the task.</FONT><FONT size=3> </FONT><FONT face=sans-serif size=2><br>
It also indicates to to the target when it is safe to send the response to a task abort or a "group" abort task management function.</FONT><FONT size=3> </FONT><FONT face=sans-serif size=2><br>
Whether you can you use TCP ack for the same pupose dependes on how you stack is layered and/or how your recovery from end-to-end errors is done.</FONT><FONT size=3> <br>
</FONT><FONT face=sans-serif size=2><br>
Julo</FONT><FONT size=3> <br>
<br>
</FONT>
<TABLE width="100%">
<TBODY>
<TR vAlign=top>
<TD width="51%"><FONT face=sans-serif size=1><B>"Eddy Quicksall" &lt;<A href='javascript:parent.ComposeTo("Quicksall_iSCSI%40Bellsouth.net", "");'>Quicksall_iSCSI@Bellsouth.net</A>&gt;</B> </FONT>

<div><FONT face=sans-serif size=1>18/05/07 08:03</FONT><FONT size=3> </FONT></div>

<TD width="48%"><br>

<TABLE width="100%">
<TBODY>
<TR vAlign=top>
<TD width="14%">

<div align=right><FONT face=sans-serif size=1>To</FONT></div>

<TD width="85%"><FONT face=sans-serif size=1>"Ken Craig" &lt;<A href='javascript:parent.ComposeTo("kcraig%40istor.com", "");'>kcraig@istor.com</A>&gt;, &lt;<A href='javascript:parent.ComposeTo("ips%40ietf.org", "");'>ips@ietf.org</A>&gt;</FONT><FONT size=3> </FONT>
<TR vAlign=top>
<TD>

<div align=right><FONT face=sans-serif size=1>cc</FONT></div>

<TD>
<TR vAlign=top>
<TD>

<div align=right><FONT face=sans-serif size=1>Subject</FONT></div>

<TD><FONT face=sans-serif size=1>Re: [Ips] StatSN question</FONT></TD></TR></TBODY></TABLE><br>
<br>

<TABLE width="100%">
<TBODY>
<TR vAlign=top>
<TD width="50%">
<TD width="50%"></TD></TR></TBODY></TABLE><br>
</TD></TR></TBODY></TABLE><br>
<FONT size=3><br>
<br>
</FONT><TT><FONT size=2><br>
It would mean the header and data has been received. The reason is because <br>
the target can use ExpStatSN to free the resources used to send the Data-in. <br>
At ERL 0 it is faster to just use the TCP ACK; for ERL &gt; 0 I think there was <br>
argument given once that the TCP ACK may not really indicate that the data <br>
was received and hence the ExpStatSN would be used for that purpose (I don't <br>
really remember that well though).<br>
<br>
Eddy<br>
<br>
----- Original Message ----- <br>
From: "Ken Craig" &lt;<A href='javascript:parent.ComposeTo("kcraig%40istor.com", "");'>kcraig@istor.com</A>&gt;<br>
To: &lt;<A href='javascript:parent.ComposeTo("ips%40ietf.org", "");'>ips@ietf.org</A>&gt;<br>
Sent: Friday, April 27, 2007 5:23 PM<br>
Subject: [Ips] StatSN question<br>
<br>
<br>
I have a question about what ExpStatSN means that<br>
I can't find an answer for in the reflector archives<br>
or in any of the RFCs.<br>
<br>
I, as an iSCSI Target running at ERL=0, send a<br>
DATA IN PDU with FINAL=1 and a StatSN of 0. &nbsp;I<br>
receive a SCSI CMD PDU with an ExpStatSN of 1.<br>
Does this mean that the Initiator has received<br>
the PDU BHS and all of the data or is it simply<br>
an acknowledgement that it has received the PDU<br>
BHS?<br>
<br>
Thanks,<br>
Ken Craig<br>
<br>
<br>
_______________________________________________<br>
Ips mailing list<br>
<A href='javascript:parent.ComposeTo("Ips%40ietf.org", "");'>Ips@ietf.org</A><br>
<A href="https://www1.ietf.org/mailman/listinfo/ips" target=_blank>https://www1.ietf.org/mailman/listinfo/ips</A><br>
<br>
<br>
<br>
_______________________________________________<br>
Ips mailing list<br>
<A href='javascript:parent.ComposeTo("Ips%40ietf.org", "");'>Ips@ietf.org</A><br>
<A href="https://www1.ietf.org/mailman/listinfo/ips" target=_blank>https://www1.ietf.org/mailman/listinfo/ips</A></FONT></TT><FONT size=3><br>
</FONT><br>
</div>
<!-- end of AOLMsgPart_3_abed8725-160a-4b2f-876b-baef25f22025 -->

<div class=AOLPlainTextBody id=AOLMsgPart_4_abed8725-160a-4b2f-876b-baef25f22025><PRE><TT>_______________________________________________
Ips mailing list
<A href='javascript:parent.ComposeTo("Ips%40ietf.org", "");'>Ips@ietf.org</A>
<A href="https://www1.ietf.org/mailman/listinfo/ips" target=_blank>https://www1.ietf.org/mailman/listinfo/ips</A>
</TT></PRE></div>
<!-- end of AOLMsgPart_4_abed8725-160a-4b2f-876b-baef25f22025 -->
<div class="AOLPromoFooter">
<hr style="margin-top:10px;" />
AOL now offers free email to everyone.  Find out more about what's free from AOL at <a href="http://www.aol.com?ncid=AOLAOF00020000000437" target="_blank"><b>AOL.com</b></a>.<br />
</div>

</BODY></HTML>

----------MB_8C968682942742D_6E8_AF1D_mblk-r15.sysops.aol.com--



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

--===============1464870895==--





From ips-bounces@ietf.org Sun May 20 22:34:32 2007
Return-path: <ips-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Hpxj9-0005vx-92; Sun, 20 May 2007 22:34:27 -0400
Received: from ips by megatron.ietf.org with local (Exim 4.43)
	id 1Hpxj8-0005vs-8J
	for ips-confirm+ok@megatron.ietf.org; Sun, 20 May 2007 22:34:26 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Hpxj7-0005vk-PU
	for ips@ietf.org; Sun, 20 May 2007 22:34:25 -0400
Received: from mail-gw3.adaptec.com ([216.52.22.36])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hpxj7-0004td-0i
	for ips@ietf.org; Sun, 20 May 2007 22:34:25 -0400
Received: from aime2k302.adaptec.com (aime2k302.adaptec.com [10.25.8.48])
	by mail-gw3.adaptec.com (Spam Firewall) with ESMTP
	id CADE61A4BFC; Sun, 20 May 2007 19:34:22 -0700 (PDT)
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] StatSN question
Date: Sun, 20 May 2007 19:34:18 -0700
Message-ID: <368FBF3D8437A748BA8222526BF9309901CCCEC5@aime2k302.adaptec.com>
In-reply-to: <9F3F0A752CAEBE4FA7E906CC2FBFF57C06D473@MERCURY.inside.istor.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Ips] StatSN question
Thread-Index: AceZCdZzk62cC/5PRRKW/k/D62yudAAYftpQAHiBRqA=
References: <001a01c79909$d4fc7a20$05faa8c0@ivivity.com>
	<9F3F0A752CAEBE4FA7E906CC2FBFF57C06D473@MERCURY.inside.istor.com>
From: "Sandars, Ken" <ken_sandars@adaptec.com>
To: "Ken Craig" <kcraig@istor.com>,
	"Eddy Quicksall" <Quicksall_iSCSI@Bellsouth.net>, <ips@ietf.org>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 31247fb3be228bb596db9127becad0bc
Cc: 
X-BeenThere: ips@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IP Storage <ips.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ips>,
	<mailto:ips-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ips@ietf.org>
List-Help: <mailto:ips-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ips>,
	<mailto:ips-request@ietf.org?subject=subscribe>
Errors-To: ips-bounces@ietf.org

Hi Ken,

Interesting initiator. If it is truly issuing an ExpStatSN which
acknowledges a response which has not been sent by the target, the
implementers should be directed to section 3.2.2.2 of RFC3720.

Is it possible that the target is not initialising its StatSN counter
correctly? Your example refers to a StatSN of 0 for the Data-In PDU
(which I am assuming also has the S bit set). Have a read of section
10.13.4 and ensure the target is incrementing StatSN correctly.

HTH,
Ken

-----Original Message-----
From: Ken Craig [mailto:kcraig@istor.com]=20
Sent: Saturday, 19 May 2007 02:47
To: Eddy Quicksall; ips@ietf.org
Subject: RE: [Ips] StatSN question

Eddy,

Thanks for the response.  I've got an Initiator that is updating
ExpStatSn before receiving all of the data.  I consider that Initiator
to be broken but since the RFC doesn't specifically state what you said
I've got no choice but to find a way to deal with it.

Ken Craig

-----Original Message-----
From: Eddy Quicksall [mailto:Quicksall_iSCSI@Bellsouth.net]
Sent: Thursday, May 17, 2007 10:03 PM
To: Ken Craig; ips@ietf.org
Subject: Re: [Ips] StatSN question


It would mean the header and data has been received. The reason is
because=20
the target can use ExpStatSN to free the resources used to send the
Data-in.=20
At ERL 0 it is faster to just use the TCP ACK; for ERL > 0 I think there
was=20
argument given once that the TCP ACK may not really indicate that the
data=20
was received and hence the ExpStatSN would be used for that purpose (I
don't=20
really remember that well though).

Eddy

----- Original Message -----=20
From: "Ken Craig" <kcraig@istor.com>
To: <ips@ietf.org>
Sent: Friday, April 27, 2007 5:23 PM
Subject: [Ips] StatSN question


I have a question about what ExpStatSN means that
I can't find an answer for in the reflector archives
or in any of the RFCs.

I, as an iSCSI Target running at ERL=3D0, send a
DATA IN PDU with FINAL=3D1 and a StatSN of 0.  I
receive a SCSI CMD PDU with an ExpStatSN of 1.
Does this mean that the Initiator has received
the PDU BHS and all of the data or is it simply
an acknowledgement that it has received the PDU
BHS?

Thanks,
Ken Craig


_______________________________________________
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 Mon May 21 13:16:32 2007
Return-path: <ips-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HqBUk-0006nJ-Ri; Mon, 21 May 2007 13:16:30 -0400
Received: from ips by megatron.ietf.org with local (Exim 4.43)
	id 1HqBUi-0006ky-Tx
	for ips-confirm+ok@megatron.ietf.org; Mon, 21 May 2007 13:16:29 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HqBUh-0006jR-VQ
	for ips@ietf.org; Mon, 21 May 2007 13:16:28 -0400
Received: from stork.istor.com ([12.170.66.34] helo=stork.inside.istor.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HqBUh-000811-CV
	for ips@ietf.org; Mon, 21 May 2007 13:16:27 -0400
Received: from mercury.inside.istor.com ([192.168.50.30])
	by stork.inside.istor.com with ESMTP; 21 May 2007 10:16:25 -0700
X-IronPort-AV: i="4.14,562,1170662400"; d="scan'208"; a="3509595:sNHT38779220"
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] StatSN question
Date: Mon, 21 May 2007 10:16:24 -0700
Message-ID: <9F3F0A752CAEBE4FA7E906CC2FBFF57C06D47A@MERCURY.inside.istor.com>
In-Reply-To: <368FBF3D8437A748BA8222526BF9309901CCCEC5@aime2k302.adaptec.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Ips] StatSN question
Thread-Index: AceZCdZzk62cC/5PRRKW/k/D62yudAAYftpQAHiBRqAAHvrE0A==
From: "Ken Craig" <kcraig@istor.com>
To: "Sandars, Ken" <ken_sandars@adaptec.com>,
	<ips@ietf.org>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e
Cc: 
X-BeenThere: ips@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IP Storage <ips.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ips>,
	<mailto:ips-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ips@ietf.org>
List-Help: <mailto:ips-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ips>,
	<mailto:ips-request@ietf.org?subject=subscribe>
Errors-To: ips-bounces@ietf.org

Ken,

My iSCSI Target has been working for the last
couple of years with all of the Initiators I
have been able to get a hold of.  I guess I
should have been more explicit in my example.
The Initiator negotiated a 256K
MaxRecvDataSegmentLength of 256K then sent a
128K Read command which allowed me to send all
of the data in one PDU.  The DATA IN PDU had
the Status and Final bits set with Command
Status of Good.  It wasn't until I had a
situation where a few of the Ethernet Frames
with the rest of the data for this particular
DATA IN PDU were stalled for ~.5 second (due
to what I think was the Initiator not opening
up its window size) that the problem was seen. =20

Ken Craig

-----Original Message-----
From: Sandars, Ken [mailto:ken_sandars@adaptec.com]=20
Sent: Sunday, May 20, 2007 7:34 PM
To: Ken Craig; Eddy Quicksall; ips@ietf.org
Subject: RE: [Ips] StatSN question


Hi Ken,

Interesting initiator. If it is truly issuing an ExpStatSN which
acknowledges a response which has not been sent by the target, the
implementers should be directed to section 3.2.2.2 of RFC3720.

Is it possible that the target is not initialising its StatSN counter
correctly? Your example refers to a StatSN of 0 for the Data-In PDU
(which I am assuming also has the S bit set). Have a read of section
10.13.4 and ensure the target is incrementing StatSN correctly.

HTH,
Ken

-----Original Message-----
From: Ken Craig [mailto:kcraig@istor.com]=20
Sent: Saturday, 19 May 2007 02:47
To: Eddy Quicksall; ips@ietf.org
Subject: RE: [Ips] StatSN question

Eddy,

Thanks for the response.  I've got an Initiator that is updating
ExpStatSn before receiving all of the data.  I consider that Initiator
to be broken but since the RFC doesn't specifically state what you said
I've got no choice but to find a way to deal with it.

Ken Craig

-----Original Message-----
From: Eddy Quicksall [mailto:Quicksall_iSCSI@Bellsouth.net]
Sent: Thursday, May 17, 2007 10:03 PM
To: Ken Craig; ips@ietf.org
Subject: Re: [Ips] StatSN question


It would mean the header and data has been received. The reason is
because=20
the target can use ExpStatSN to free the resources used to send the
Data-in.=20
At ERL 0 it is faster to just use the TCP ACK; for ERL > 0 I think there
was=20
argument given once that the TCP ACK may not really indicate that the
data=20
was received and hence the ExpStatSN would be used for that purpose (I
don't=20
really remember that well though).

Eddy

----- Original Message -----=20
From: "Ken Craig" <kcraig@istor.com>
To: <ips@ietf.org>
Sent: Friday, April 27, 2007 5:23 PM
Subject: [Ips] StatSN question


I have a question about what ExpStatSN means that
I can't find an answer for in the reflector archives
or in any of the RFCs.

I, as an iSCSI Target running at ERL=3D0, send a
DATA IN PDU with FINAL=3D1 and a StatSN of 0.  I
receive a SCSI CMD PDU with an ExpStatSN of 1.
Does this mean that the Initiator has received
the PDU BHS and all of the data or is it simply
an acknowledgement that it has received the PDU
BHS?

Thanks,
Ken Craig


_______________________________________________
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 May 22 18:50:50 2007
Return-path: <ips-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HqdBp-0000Te-2h; Tue, 22 May 2007 18:50:49 -0400
Received: from ips by megatron.ietf.org with local (Exim 4.43)
	id 1HqdB7-0007we-BB
	for ips-confirm+ok@megatron.ietf.org; Tue, 22 May 2007 18:50:05 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HqdB5-0007vo-KJ; Tue, 22 May 2007 18:50:04 -0400
Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1HqdB5-0004RL-0o; Tue, 22 May 2007 18:50:03 -0400
Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com
	[10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id A6AE126EA0;
	Tue, 22 May 2007 22:50:02 +0000 (GMT)
Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43)
	id 1HqdB4-0000wd-HV; Tue, 22 May 2007 18:50:02 -0400
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: i-d-announce@ietf.org
From: Internet-Drafts@ietf.org
Message-Id: <E1HqdB4-0000wd-HV@stiedprstage1.ietf.org>
Date: Tue, 22 May 2007 18:50:02 -0400
X-Spam-Score: -2.5 (--)
X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be
Cc: ips@ietf.org
Subject: [Ips] I-D ACTION:draft-ietf-ips-iscsi-impl-guide-08.txt 
X-BeenThere: ips@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IP Storage <ips.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ips>,
	<mailto:ips-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ips@ietf.org>
List-Help: <mailto:ips-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ips>,
	<mailto:ips-request@ietf.org?subject=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-08.txt,.pdf
	Pages		: 49
	Date		: 2007-5-22
	
iSCSI is a SCSI transport protocol and maps the SCSI 
     architecture and command sets 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-08.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-08.txt".

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

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

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-ips-iscsi-impl-guide-08.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body; access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID: <2007-5-22152049.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-ips-iscsi-impl-guide-08.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-ips-iscsi-impl-guide-08.txt";
	site="ftp.ietf.org"; access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <2007-5-22152049.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 Wed May 23 08:50:35 2007
Return-path: <ips-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HqqIT-0003Bl-Kj; Wed, 23 May 2007 08:50:33 -0400
Received: from ips by megatron.ietf.org with local (Exim 4.43)
	id 1HqqIS-0003Bg-GN
	for ips-confirm+ok@megatron.ietf.org; Wed, 23 May 2007 08:50:32 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HqqIS-0003BY-6N
	for ips@ietf.org; Wed, 23 May 2007 08:50:32 -0400
Received: from imf20aec.mail.bellsouth.net ([205.152.59.68])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HqqIR-0007sU-PJ
	for ips@ietf.org; Wed, 23 May 2007 08:50:32 -0400
Received: from ibm64aec.bellsouth.net ([74.228.222.58])
	by imf20aec.mail.bellsouth.net with ESMTP id
	<20070523125002.UGMH22883.imf20aec.mail.bellsouth.net@ibm64aec.bellsouth.net>
	for <ips@ietf.org>; Wed, 23 May 2007 08:50:02 -0400
Received: from IVVTDKV0981 ([74.228.222.58]) by ibm64aec.bellsouth.net
	with SMTP
	id <20070523125001.BQHX2600.ibm64aec.bellsouth.net@IVVTDKV0981>;
	Wed, 23 May 2007 08:50:01 -0400
Message-ID: <002801c79d38$de1a3f60$05faa8c0@ivivity.com>
From: "Eddy Quicksall" <Quicksall_iSCSI@Bellsouth.net>
To: "Ken Craig" <kcraig@istor.com>, "Sandars, Ken" <ken_sandars@adaptec.com>,
	<ips@ietf.org>
References: <9F3F0A752CAEBE4FA7E906CC2FBFF57C06D47A@MERCURY.inside.istor.com>
Subject: Re: [Ips] StatSN question
Date: Wed, 23 May 2007 08:49:52 -0400
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: 8fbbaa16f9fd29df280814cb95ae2290
Cc: 
X-BeenThere: ips@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IP Storage <ips.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ips>,
	<mailto:ips-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ips@ietf.org>
List-Help: <mailto:ips-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ips>,
	<mailto:ips-request@ietf.org?subject=subscribe>
Errors-To: ips-bounces@ietf.org

It would behoove all of us if the initiator was fixed. We should not be 
adding code to overcome a bug in the initiator especially if it is hard to 
detect.

Can you tell us the initiator so we can run tests too?

Eddy
----- Original Message ----- 
From: "Ken Craig" <kcraig@istor.com>
To: "Sandars, Ken" <ken_sandars@adaptec.com>; <ips@ietf.org>
Sent: Monday, May 21, 2007 1:16 PM
Subject: RE: [Ips] StatSN question


Ken,

My iSCSI Target has been working for the last
couple of years with all of the Initiators I
have been able to get a hold of.  I guess I
should have been more explicit in my example.
The Initiator negotiated a 256K
MaxRecvDataSegmentLength of 256K then sent a
128K Read command which allowed me to send all
of the data in one PDU.  The DATA IN PDU had
the Status and Final bits set with Command
Status of Good.  It wasn't until I had a
situation where a few of the Ethernet Frames
with the rest of the data for this particular
DATA IN PDU were stalled for ~.5 second (due
to what I think was the Initiator not opening
up its window size) that the problem was seen.

Ken Craig

-----Original Message-----
From: Sandars, Ken [mailto:ken_sandars@adaptec.com]
Sent: Sunday, May 20, 2007 7:34 PM
To: Ken Craig; Eddy Quicksall; ips@ietf.org
Subject: RE: [Ips] StatSN question


Hi Ken,

Interesting initiator. If it is truly issuing an ExpStatSN which
acknowledges a response which has not been sent by the target, the
implementers should be directed to section 3.2.2.2 of RFC3720.

Is it possible that the target is not initialising its StatSN counter
correctly? Your example refers to a StatSN of 0 for the Data-In PDU
(which I am assuming also has the S bit set). Have a read of section
10.13.4 and ensure the target is incrementing StatSN correctly.

HTH,
Ken

-----Original Message-----
From: Ken Craig [mailto:kcraig@istor.com]
Sent: Saturday, 19 May 2007 02:47
To: Eddy Quicksall; ips@ietf.org
Subject: RE: [Ips] StatSN question

Eddy,

Thanks for the response.  I've got an Initiator that is updating
ExpStatSn before receiving all of the data.  I consider that Initiator
to be broken but since the RFC doesn't specifically state what you said
I've got no choice but to find a way to deal with it.

Ken Craig

-----Original Message-----
From: Eddy Quicksall [mailto:Quicksall_iSCSI@Bellsouth.net]
Sent: Thursday, May 17, 2007 10:03 PM
To: Ken Craig; ips@ietf.org
Subject: Re: [Ips] StatSN question


It would mean the header and data has been received. The reason is
because
the target can use ExpStatSN to free the resources used to send the
Data-in.
At ERL 0 it is faster to just use the TCP ACK; for ERL > 0 I think there
was
argument given once that the TCP ACK may not really indicate that the
data
was received and hence the ExpStatSN would be used for that purpose (I
don't
really remember that well though).

Eddy

----- Original Message ----- 
From: "Ken Craig" <kcraig@istor.com>
To: <ips@ietf.org>
Sent: Friday, April 27, 2007 5:23 PM
Subject: [Ips] StatSN question


I have a question about what ExpStatSN means that
I can't find an answer for in the reflector archives
or in any of the RFCs.

I, as an iSCSI Target running at ERL=0, send a
DATA IN PDU with FINAL=1 and a StatSN of 0.  I
receive a SCSI CMD PDU with an ExpStatSN of 1.
Does this mean that the Initiator has received
the PDU BHS and all of the data or is it simply
an acknowledgement that it has received the PDU
BHS?

Thanks,
Ken Craig


_______________________________________________
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



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



From ips-bounces@ietf.org Wed May 23 13:29:40 2007
Return-path: <ips-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HqueY-0003MO-DU; Wed, 23 May 2007 13:29:38 -0400
Received: from ips by megatron.ietf.org with local (Exim 4.43)
	id 1HqueX-0003MJ-VH
	for ips-confirm+ok@megatron.ietf.org; Wed, 23 May 2007 13:29:37 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HqueX-0003MB-Le
	for ips@ietf.org; Wed, 23 May 2007 13:29:37 -0400
Received: from stork.istor.com ([12.170.66.34] helo=stork.inside.istor.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HqueX-0005TK-77
	for ips@ietf.org; Wed, 23 May 2007 13:29:37 -0400
Received: from mercury.inside.istor.com ([192.168.50.30])
	by stork.inside.istor.com with ESMTP; 23 May 2007 10:29:32 -0700
X-IronPort-AV: i="4.14,570,1170662400"; d="scan'208"; a="3529754:sNHT55590760"
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] StatSN question
Date: Wed, 23 May 2007 10:29:32 -0700
Message-ID: <9F3F0A752CAEBE4FA7E906CC2FBFF57C06D482@MERCURY.inside.istor.com>
In-Reply-To: <002801c79d38$de1a3f60$05faa8c0@ivivity.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Ips] StatSN question
Thread-Index: AcedOPOtE+b6s9YxSG6GZ8DPlvxFSQAJt2Og
From: "Ken Craig" <kcraig@istor.com>
To: "Eddy Quicksall" <Quicksall_iSCSI@Bellsouth.net>,
	<ips@ietf.org>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0ff9c467ad7f19c2a6d058acd7faaec8
Cc: 
X-BeenThere: ips@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IP Storage <ips.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ips>,
	<mailto:ips-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ips@ietf.org>
List-Help: <mailto:ips-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ips>,
	<mailto:ips-request@ietf.org?subject=subscribe>
Errors-To: ips-bounces@ietf.org

Eddy,

The person in my organization that has all of
the pertinent information is out of the office
until next week so I won't be able to get it
to you until then.

Ken Craig


-----Original Message-----
From: Eddy Quicksall [mailto:Quicksall_iSCSI@Bellsouth.net]=20
Sent: Wednesday, May 23, 2007 5:50 AM
To: Ken Craig; Sandars, Ken; ips@ietf.org
Subject: Re: [Ips] StatSN question


It would behoove all of us if the initiator was fixed. We should not be=20
adding code to overcome a bug in the initiator especially if it is hard
to=20
detect.

Can you tell us the initiator so we can run tests too?

Eddy
----- Original Message -----=20
From: "Ken Craig" <kcraig@istor.com>
To: "Sandars, Ken" <ken_sandars@adaptec.com>; <ips@ietf.org>
Sent: Monday, May 21, 2007 1:16 PM
Subject: RE: [Ips] StatSN question


Ken,

My iSCSI Target has been working for the last
couple of years with all of the Initiators I
have been able to get a hold of.  I guess I
should have been more explicit in my example.
The Initiator negotiated a 256K
MaxRecvDataSegmentLength of 256K then sent a
128K Read command which allowed me to send all
of the data in one PDU.  The DATA IN PDU had
the Status and Final bits set with Command
Status of Good.  It wasn't until I had a
situation where a few of the Ethernet Frames
with the rest of the data for this particular
DATA IN PDU were stalled for ~.5 second (due
to what I think was the Initiator not opening
up its window size) that the problem was seen.

Ken Craig

-----Original Message-----
From: Sandars, Ken [mailto:ken_sandars@adaptec.com]
Sent: Sunday, May 20, 2007 7:34 PM
To: Ken Craig; Eddy Quicksall; ips@ietf.org
Subject: RE: [Ips] StatSN question


Hi Ken,

Interesting initiator. If it is truly issuing an ExpStatSN which
acknowledges a response which has not been sent by the target, the
implementers should be directed to section 3.2.2.2 of RFC3720.

Is it possible that the target is not initialising its StatSN counter
correctly? Your example refers to a StatSN of 0 for the Data-In PDU
(which I am assuming also has the S bit set). Have a read of section
10.13.4 and ensure the target is incrementing StatSN correctly.

HTH,
Ken

-----Original Message-----
From: Ken Craig [mailto:kcraig@istor.com]
Sent: Saturday, 19 May 2007 02:47
To: Eddy Quicksall; ips@ietf.org
Subject: RE: [Ips] StatSN question

Eddy,

Thanks for the response.  I've got an Initiator that is updating
ExpStatSn before receiving all of the data.  I consider that Initiator
to be broken but since the RFC doesn't specifically state what you said
I've got no choice but to find a way to deal with it.

Ken Craig

-----Original Message-----
From: Eddy Quicksall [mailto:Quicksall_iSCSI@Bellsouth.net]
Sent: Thursday, May 17, 2007 10:03 PM
To: Ken Craig; ips@ietf.org
Subject: Re: [Ips] StatSN question


It would mean the header and data has been received. The reason is
because the target can use ExpStatSN to free the resources used to send
the Data-in. At ERL 0 it is faster to just use the TCP ACK; for ERL > 0
I think there was argument given once that the TCP ACK may not really
indicate that the data was received and hence the ExpStatSN would be
used for that purpose (I don't really remember that well though).

Eddy

----- Original Message -----=20
From: "Ken Craig" <kcraig@istor.com>
To: <ips@ietf.org>
Sent: Friday, April 27, 2007 5:23 PM
Subject: [Ips] StatSN question


I have a question about what ExpStatSN means that
I can't find an answer for in the reflector archives
or in any of the RFCs.

I, as an iSCSI Target running at ERL=3D0, send a
DATA IN PDU with FINAL=3D1 and a StatSN of 0.  I
receive a SCSI CMD PDU with an ExpStatSN of 1.
Does this mean that the Initiator has received
the PDU BHS and all of the data or is it simply
an acknowledgement that it has received the PDU
BHS?

Thanks,
Ken Craig


_______________________________________________
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


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



From ips-bounces@ietf.org Thu May 24 00:31:20 2007
Return-path: <ips-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Hr4yr-0001Q7-Vq; Thu, 24 May 2007 00:31:17 -0400
Received: from ips by megatron.ietf.org with local (Exim 4.43)
	id 1Hr4yr-0001P4-3c
	for ips-confirm+ok@megatron.ietf.org; Thu, 24 May 2007 00:31:17 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Hr4yq-0001Ow-Q1
	for ips@ietf.org; Thu, 24 May 2007 00:31:16 -0400
Received: from imf23aec.mail.bellsouth.net ([205.152.59.71])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hr4yq-0006D9-Ci
	for ips@ietf.org; Thu, 24 May 2007 00:31:16 -0400
Received: from ibm66aec.bellsouth.net ([74.228.222.58])
	by imf23aec.mail.bellsouth.net with ESMTP id
	<20070524043115.UUYS17388.imf23aec.mail.bellsouth.net@ibm66aec.bellsouth.net>
	for <ips@ietf.org>; Thu, 24 May 2007 00:31:15 -0400
Received: from IVVTDKV0981 ([74.228.222.58]) by ibm66aec.bellsouth.net
	with SMTP
	id <20070524043113.EPOM19701.ibm66aec.bellsouth.net@IVVTDKV0981>;
	Thu, 24 May 2007 00:31:13 -0400
Message-ID: <001e01c79dbc$5c91f3f0$05faa8c0@ivivity.com>
From: "Eddy Quicksall" <Quicksall_iSCSI@Bellsouth.net>
To: "Qi, Yanling" <Yanling.Qi@lsi.com>,
	<ips@ietf.org>
References: <0F08E10B769EAF4EA2C43A573B8CC87FB5773D@NAMAIL3.ad.lsil.com>
Subject: Re: [Ips] Handling Expected-data-transfer-legnth and CDB
	transfer-lenmismatch
Date: Thu, 24 May 2007 00:31:08 -0400
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: a4a24b484706be629f915bfb1a3e4771
Cc: "Qi, Yanling" <Yanling.Qi@lsi.com>
X-BeenThere: ips@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IP Storage <ips.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ips>,
	<mailto:ips-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ips@ietf.org>
List-Help: <mailto:ips-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ips>,
	<mailto:ips-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0424455744=="
Errors-To: ips-bounces@ietf.org

This is a multi-part message in MIME format.

--===============0424455744==
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_001B_01C79D9A.D2532FE0"

This is a multi-part message in MIME format.

------=_NextPart_000_001B_01C79D9A.D2532FE0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Looking at the trace, the initiator sent 0x2000 bytes of immediate data. =
The target did not request anymore data because the count was 0. So U =
with a residual of 0x4000 is correct. The target would just discard the =
immediate data. It is legal to write 0 bytes with a WRITE (10) and WRITE =
AND VERITY (10) refers back to that.=20

The iSCSI layer is not required to check the Expected Data Transfer =
Length against the CDB (to do so would require that the iSCSI layer =
understand all of the CDB's). I don't recall seeing any requirement for =
the Device Server to check the CDB against the Expected Data Transfer =
Length either.

Eddy
  ----- Original Message -----=20
  From: Qi, Yanling=20
  To: ips@ietf.org=20
  Cc: Qi, Yanling=20
  Sent: Monday, May 14, 2007 5:29 PM
  Subject: [Ips] Handling Expected-data-transfer-legnth and CDB =
transfer-lenmismatch


  Hi All,

  =20

  We saw an initiator problem where the expected-data-transfer-length =
and transfer-len inside CDB got mismatched for a write-and-verify (10). =
The expected-data-transfer-length is 0x4000 but the transfer-len in the =
CDB is 0. The target completed the request with good status, turned =
Residual-underflow bit on and set residual-count=3D0x4000. See frames 16 =
and 38 in the attached ethereal trace file for details. Did the target =
handle this error condition correctly?

  =20

  Thanks,

  =20

  --yanling

  =20

  Yanling Qi

  Engenio Storage Group - LSI Logic

  512-794-3713 (Office)

  512-794-3702 (Fax)

  yanling.qi@lsi.com

  =20



-------------------------------------------------------------------------=
-----


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

------=_NextPart_000_001B_01C79D9A.D2532FE0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML xmlns=3D"http://www.w3.org/TR/REC-html40" xmlns:o =3D=20
"urn:schemas-microsoft-com:office:office" xmlns:w =3D=20
"urn:schemas-microsoft-com:office:word"><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.6000.16441" name=3DGENERATOR>
<STYLE>@page Section1 {size: 8.5in 11.0in; margin: 1.0in 1.25in 1.0in =
1.25in; }
P.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"
}
LI.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"
}
DIV.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"
}
A:link {
	COLOR: blue; TEXT-DECORATION: underline
}
SPAN.MsoHyperlink {
	COLOR: blue; TEXT-DECORATION: underline
}
A:visited {
	COLOR: purple; TEXT-DECORATION: underline
}
SPAN.MsoHyperlinkFollowed {
	COLOR: purple; TEXT-DECORATION: underline
}
SPAN.EmailStyle17 {
	COLOR: windowtext; FONT-FAMILY: Arial; mso-style-type: personal-compose
}
DIV.Section1 {
	page: Section1
}
</STYLE>
</HEAD>
<BODY lang=3DEN-US vLink=3Dpurple link=3Dblue bgColor=3D#ffffff>
<DIV><FONT face=3DCourierNewPS-BoldMT size=3D2>Looking at the trace, the =
initiator=20
sent 0x2000 bytes of immediate data. The target did not request anymore =
data=20
because the count was 0. So U with a residual of 0x4000&nbsp;is correct. =
The=20
target would just discard the immediate data.&nbsp;It is&nbsp;legal to =
write 0=20
bytes with a WRITE (10)&nbsp;and WRITE AND VERITY (10) refers back to =
that.=20
</FONT></DIV>
<DIV><FONT face=3DCourierNewPS-BoldMT size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourierNewPS-BoldMT size=3D2>The iSCSI layer is not =
required to=20
check the Expected Data Transfer Length against the CDB (to do so would =
require=20
that the iSCSI layer understand all of the CDB's). </FONT><FONT=20
face=3DCourierNewPS-BoldMT size=3D2>I don't recall seeing any =
requirement for the=20
Device Server to check the CDB against the Expected Data Transfer Length =

either.</DIV></FONT>
<DIV><FONT size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2>Eddy</FONT></DIV>
<BLOCKQUOTE=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
  <DIV style=3D"FONT: 10pt arial">----- Original Message ----- </DIV>
  <DIV=20
  style=3D"BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: =
black"><B>From:</B>=20
  <A title=3DYanling.Qi@lsi.com href=3D"mailto:Yanling.Qi@lsi.com">Qi, =
Yanling</A>=20
  </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>To:</B> <A title=3Dips@ietf.org=20
  href=3D"mailto:ips@ietf.org">ips@ietf.org</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Cc:</B> <A =
title=3DYanling.Qi@lsi.com=20
  href=3D"mailto:Yanling.Qi@lsi.com">Qi, Yanling</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Sent:</B> Monday, May 14, 2007 5:29 =
PM</DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Subject:</B> [Ips] Handling=20
  Expected-data-transfer-legnth and CDB transfer-lenmismatch</DIV>
  <DIV><BR></DIV>
  <DIV class=3DSection1>
  <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">Hi=20
  All,<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">We saw an initiator =
problem where=20
  the expected-data-transfer-length and transfer-len inside CDB got =
mismatched=20
  for a write-and-verify (10). The expected-data-transfer-length is =
0x4000 but=20
  the transfer-len in the CDB is 0. The target completed the request =
with good=20
  status, turned Residual-underflow bit on and set =
residual-count=3D0x4000. See=20
  frames 16 and 38 in the attached ethereal trace file for details. Did =
the=20
  target handle this error condition =
correctly?<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial">Thanks,<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial">--yanling<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
  style=3D"FONT-SIZE: 12pt">Yanling Qi<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
  style=3D"FONT-SIZE: 12pt">Engenio Storage Group - LSI=20
  Logic<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
  style=3D"FONT-SIZE: 12pt">512-794-3713 =
(Office)<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
  style=3D"FONT-SIZE: 12pt">512-794-3702 =
(Fax)<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
  style=3D"FONT-SIZE: 12pt"><A=20
  =
href=3D"mailto:yanling.qi@lsi.com">yanling.qi@lsi.com</A><o:p></o:p></SPA=
N></FONT></P>
  <P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
  style=3D"FONT-SIZE: 12pt"><o:p>&nbsp;</o:p></SPAN></FONT></P></DIV>
  <P>
  <HR>

  <P></P>_______________________________________________<BR>Ips mailing=20
  =
list<BR>Ips@ietf.org<BR>https://www1.ietf.org/mailman/listinfo/ips<BR></B=
LOCKQUOTE></BODY></HTML>

------=_NextPart_000_001B_01C79D9A.D2532FE0--




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

--===============0424455744==--






From ips-bounces@ietf.org Thu May 24 10:41:54 2007
Return-path: <ips-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HrEVj-0000GL-No; Thu, 24 May 2007 10:41:51 -0400
Received: from ips by megatron.ietf.org with local (Exim 4.43)
	id 1HrEVi-0000GD-Oj
	for ips-confirm+ok@megatron.ietf.org; Thu, 24 May 2007 10:41:50 -0400
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HrEVh-0000G5-MX; Thu, 24 May 2007 10:41:50 -0400
Received: from ns4.neustar.com ([156.154.24.139])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43)
	id 1HrEVg-0006Rj-E6; Thu, 24 May 2007 10:41:49 -0400
Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com
	[10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 5A8602ACB2;
	Thu, 24 May 2007 14:41:18 +0000 (GMT)
Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43)
	id 1HrEVC-0005KC-3L; Thu, 24 May 2007 10:41:18 -0400
X-test-idtracker: no
To: IETF-Announce <ietf-announce@ietf.org>
From: The IESG <iesg-secretary@ietf.org>
Message-Id: <E1HrEVC-0005KC-3L@stiedprstage1.ietf.org>
Date: Thu, 24 May 2007 10:41:18 -0400
X-Spam-Score: -2.8 (--)
X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581
Cc: ips@ietf.org
Subject: [Ips] Last Call: draft-ietf-ips-iscsi-impl-guide (iSCSI Corrections
 and Clarifications) to Proposed Standard 
X-BeenThere: ips@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: ietf@ietf.org
List-Id: IP Storage <ips.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ips>,
	<mailto:ips-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ips@ietf.org>
List-Help: <mailto:ips-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ips>,
	<mailto:ips-request@ietf.org?subject=subscribe>
Errors-To: ips-bounces@ietf.org

The IESG has received a request from the IP Storage WG (ips) to consider
the following document:

- 'iSCSI Corrections and Clarifications '
   <draft-ietf-ips-iscsi-impl-guide-08.txt> as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send substantive comments to the
ietf@ietf.org mailing lists by 2007-06-07. Exceptionally, 
comments may be sent to iesg@ietf.org instead. In either case, please 
retain the beginning of the Subject line to allow automated sorting.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-ips-iscsi-impl-guide-08.txt




IESG discussion can be tracked via
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=13381&rfc_flag=0



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



From ips-bounces@ietf.org Thu May 31 18:15:58 2007
Return-path: <ips-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Htsvt-0003ZR-TB; Thu, 31 May 2007 18:15:49 -0400
Received: from ips by megatron.ietf.org with local (Exim 4.43)
	id 1Htsvt-0003ZF-61
	for ips-confirm+ok@megatron.ietf.org; Thu, 31 May 2007 18:15:49 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Htsvs-0003Z6-SQ
	for ips@ietf.org; Thu, 31 May 2007 18:15:48 -0400
Received: from stork.istor.com ([12.170.66.34] helo=stork.inside.istor.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Htsvs-0001wi-Ed
	for ips@ietf.org; Thu, 31 May 2007 18:15:48 -0400
Received: from mercury.inside.istor.com ([192.168.50.30])
	by stork.inside.istor.com with ESMTP; 31 May 2007 15:15:48 -0700
X-IronPort-AV: i="4.16,370,1175497200"; d="scan'208"; a="3595985:sNHT59336620"
Content-class: urn:content-classes:message
Subject: RE: [Ips] StatSN question
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Thu, 31 May 2007 15:15:47 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5
Message-ID: <9F3F0A752CAEBE4FA7E906CC2FBFF57C06D497@MERCURY.inside.istor.com>
In-Reply-To: <002801c79d38$de1a3f60$05faa8c0@ivivity.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Ips] StatSN question
Thread-Index: AcedOPOtE+b6s9YxSG6GZ8DPlvxFSQGl8lBA
From: "Ken Craig" <kcraig@istor.com>
To: "Eddy Quicksall" <Quicksall_iSCSI@Bellsouth.net>,
	<ips@ietf.org>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 200d029292fbb60d25b263122ced50fc
Cc: 
X-BeenThere: ips@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IP Storage <ips.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ips>,
	<mailto:ips-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ips@ietf.org>
List-Help: <mailto:ips-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ips>,
	<mailto:ips-request@ietf.org?subject=subscribe>
Errors-To: ips-bounces@ietf.org

Eddy,

The iSCSI initiator that we have confirmed sends updated
ExpStatSN before receiving all of the data is from SourceForge.
The name of the project on SourceForge is "linux-iscsi".
The version that we looked at the source code for is 4.0.2.

I also had a mistake in my detailed example.  The Initiator
negotiated a 128K MaxRecvDataSegmentLength instead of the
256K I mentioned.  That doesn't change anything since the
command that turned up the issue was a 128K Read.

Ken Craig

-----Original Message-----
From: Eddy Quicksall [mailto:Quicksall_iSCSI@Bellsouth.net]=20
Sent: Wednesday, May 23, 2007 5:50 AM
To: Ken Craig; Sandars, Ken; ips@ietf.org
Subject: Re: [Ips] StatSN question


It would behoove all of us if the initiator was fixed. We should not be=20
adding code to overcome a bug in the initiator especially if it is hard
to=20
detect.

Can you tell us the initiator so we can run tests too?

Eddy
----- Original Message -----=20
From: "Ken Craig" <kcraig@istor.com>
To: "Sandars, Ken" <ken_sandars@adaptec.com>; <ips@ietf.org>
Sent: Monday, May 21, 2007 1:16 PM
Subject: RE: [Ips] StatSN question


Ken,

My iSCSI Target has been working for the last
couple of years with all of the Initiators I
have been able to get a hold of.  I guess I
should have been more explicit in my example.
The Initiator negotiated a 256K
MaxRecvDataSegmentLength of 256K then sent a
128K Read command which allowed me to send all
of the data in one PDU.  The DATA IN PDU had
the Status and Final bits set with Command
Status of Good.  It wasn't until I had a
situation where a few of the Ethernet Frames
with the rest of the data for this particular
DATA IN PDU were stalled for ~.5 second (due
to what I think was the Initiator not opening
up its window size) that the problem was seen.

Ken Craig

-----Original Message-----
From: Sandars, Ken [mailto:ken_sandars@adaptec.com]
Sent: Sunday, May 20, 2007 7:34 PM
To: Ken Craig; Eddy Quicksall; ips@ietf.org
Subject: RE: [Ips] StatSN question


Hi Ken,

Interesting initiator. If it is truly issuing an ExpStatSN which
acknowledges a response which has not been sent by the target, the
implementers should be directed to section 3.2.2.2 of RFC3720.

Is it possible that the target is not initialising its StatSN counter
correctly? Your example refers to a StatSN of 0 for the Data-In PDU
(which I am assuming also has the S bit set). Have a read of section
10.13.4 and ensure the target is incrementing StatSN correctly.

HTH,
Ken

-----Original Message-----
From: Ken Craig [mailto:kcraig@istor.com]
Sent: Saturday, 19 May 2007 02:47
To: Eddy Quicksall; ips@ietf.org
Subject: RE: [Ips] StatSN question

Eddy,

Thanks for the response.  I've got an Initiator that is updating
ExpStatSn before receiving all of the data.  I consider that Initiator
to be broken but since the RFC doesn't specifically state what you said
I've got no choice but to find a way to deal with it.

Ken Craig

-----Original Message-----
From: Eddy Quicksall [mailto:Quicksall_iSCSI@Bellsouth.net]
Sent: Thursday, May 17, 2007 10:03 PM
To: Ken Craig; ips@ietf.org
Subject: Re: [Ips] StatSN question


It would mean the header and data has been received. The reason is
because the target can use ExpStatSN to free the resources used to send
the Data-in. At ERL 0 it is faster to just use the TCP ACK; for ERL > 0
I think there was argument given once that the TCP ACK may not really
indicate that the data was received and hence the ExpStatSN would be
used for that purpose (I don't really remember that well though).

Eddy

----- Original Message -----=20
From: "Ken Craig" <kcraig@istor.com>
To: <ips@ietf.org>
Sent: Friday, April 27, 2007 5:23 PM
Subject: [Ips] StatSN question


I have a question about what ExpStatSN means that
I can't find an answer for in the reflector archives
or in any of the RFCs.

I, as an iSCSI Target running at ERL=3D0, send a
DATA IN PDU with FINAL=3D1 and a StatSN of 0.  I
receive a SCSI CMD PDU with an ExpStatSN of 1.
Does this mean that the Initiator has received
the PDU BHS and all of the data or is it simply
an acknowledgement that it has received the PDU
BHS?

Thanks,
Ken Craig


_______________________________________________
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


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



