Progress Indication function in Device Busy Event#2

Henry Gabryjelski henrygab at windows.microsoft.com
Mon Nov 3 15:28:54 PST 2003


* From the T10 Reflector (t10 at t10.org), posted by:
* "Henry Gabryjelski" <henrygab at windows.microsoft.com>
*
This is a multi-part message in MIME format.

------=_NextPart_000_0057_01C3A21F.30E02E30
Content-Type: multipart/alternative;
	boundary="----=_NextPart_001_0058_01C3A21F.30E02E30"


------=_NextPart_001_0058_01C3A21F.30E02E30
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit


It is difficult to use a word document to reply to e-mail.  Please keep
future comments in e-mail.  I must use RTF format now to make it clear whose
comments are whose.

(Due to many issues with asynchronous GESN, it will not be considered in
this response. Also, "command queuing" in CD type logical units will
similarly not be considered.)
<KK - Comment>
I agree with you for current actual implementations. But MMC3 standard and
Fuji Specification are made as physical bus independent documents. They must
be consistent for any environments.
<HG - RE: Comment>
For my discussions, I chose to restrict the discussion for simplicity, not
because the use was invalid.  I regret any confusion that may have caused.

1) Indeed, the initiator of any command (referred to below as the host, but
may be driver or application, but rarely both) can know the remaining time
using the command-specific follow-up behavior.
<KK - Comment>
You need to explain to Device manufactures why you need progress indication
in time unit. Otherwise, many people who cannot attend MMC4 WG due to too
far distance from their countries, will not accept your opinion.
<HG - RE: Comment>
The explanation was done in full at the MMC meeting, and allowed questions
to occur and be answered quickly.  The summary is: (A) In complex
environment, driver and application are seperated. (B) driver cannot know
all commands being sent by application or other drivers. (C) Therefore, it
is not possible to ensure that GESN commands are occurring before each
command which can timeout.  (D) It is also not possible to know ahead of
time if an application (or other driver) has caused device to become
not-ready (such as due to format, blank, etc).  (E) If a device is not
ready, it is not possible for anyone other than the initiator to know how
long it will take for the device to become ready.  (for simplicity, let use
consider the case of an application formatting media.)  Therefore, when the
application causes a device to end up in a not-ready state, it is not
reasonable for the driver to detect the time it will take for the device to
become ready.  This prevents, in many cases, the ability of the host driver
to make an informed decision as to whether to retry some IO after a small
delay or simply fail the request with a busy status.  This then results in
situations where a computer program may appear to "hang" for a significant
period of time as the IO is retried due to a device busy condition.

2) If Device Busy is used to indicate timeout possibility of a command, what
commands are covered by the Device Busy event?  I will presume that only
those commands which can timeout per spec are included. In such a case, what
will occur if the device cannot accept one command but can accept a second
command? Which command's timeout value will be reported in the Device Busy
event?
<KK - Comment>
Device shall report time-out event "before" or "after" the command that may
cause Group 1 time-out, is issued. The "before" is in case of polling mode.
The "after" is in case of queued mode.
<HG - RE: Comment>
If instead you are saying the previous command's long execution would cause
the next GESN to report a DeviceBusy event, then it is assumed that commands
are linked from the host.  Linked commands in complex host environments are
not supported; IO can be reorderd prior to being processed by the LU, and
multiple initiators (drivers and applications) further enhance this problem.
Therefore, I think it is not reasonable to expect a device busy event to
occur from the previous command, but only predictively for the next
command(s).  But, if sent before a command, how can the LU determine if the
following command will exceed the typical timeout?  I do not think this is
possible.

The documentation on Device Busy supports may be interpreted to support this
notion of use for Device Busy event for a transport/device that supports
command queueing.  In these cases, it is clear how the Device Busy event
could be used in the method described by Katata-san.  However, in a
single-command transport/device, the use model described does not seem to be
easily supported.

Using Katata-san's section 2.3 for diagrams: Method 1 works for non-queued,
single-command at a time case.  However, only the initiator of the command
(either one application or driver, not both) can understand the results.
Method 2 will not be considered.
<KK - Comment>
Actually you need not consider Method 2 because you do not have a plane to
use command queuing in ATAPI environment. But it is your case only, not for
all people. For example, Pioneer has products that support ATAPI overlap
feature. Because several customer need this feature. So if queuing is
required, why I should not use it?
<HG - RE: Comment>
For my discussions, I chose to restrict the discussion for simplicity, not
because the use was invalid.  I regret any confusion that may have caused.

The diagram of Method 4 is unclear, and not referred to in this discussion.
<KK - Comment>
This Method 4 is your talking. You said that Device Busy Event reports
Progress Indication instead of time-out signal and Expanded Working Time.
<HG - RE: Comment>
The Method 4 is not that reported by myself, or the diagram is unclear.  I
have described this repeatedly as "Time until the device is ready"; only
you, Katata-san, are repeatedly describing this as "Progress Indication".  I
ask that you do not use this term, as it confuses the issue.

This leaves only Method 3 per Katata-san's documentation.  Method 3 is the
most interesting of the cases.  In a non-queued environment, the READ
command would timeout;  Since the specification says timeouts are disabled,
there are three scenarios:
(A) device becomes ready to receive next command,
(B) device continues to asset the busy bit (ATAPI example) saying it is not
ready for next command,
(C) host sends GESN prior to READ command to get Device Busy.
In case B, the host will eventually force the command to terminate due to
the command's timeout setting. I do not believe this could be the intention
of the specification.
<KK - Comment>
The case B has happened in the real market. Then 11.0 Time-out model is
created. If device reports time-out signal to host, host can know that
device does not hang up and host can wait the finish of the command without
RESET..
<HG - RE: Comment>
Case B has happened in the real market, and has resulting in the device
being reset by some host OS implementations.  The reason is that, in at
least one OS implementation, the timeout for a command is predetermined, and
the device is expected to become ready within that timeout period.  The
expectation in your reading of the specifation requires a much more
monolithic implementation of the CD device driver and the transport driver
(ATAPI, 1394, etc.) to prevent a bus reset when a command times out.  The
market reality is that most devices will be running on OSs which will reset
the bus if the busy bit is not cleared (and cause the device to disappear if
it continues to assert the busy bit after the reset).

In case A, the host will expect the data to have been successfully written.
<KK - Comment>
Host will expect it. But it is not confirmed. If OPC failure occurred, any
data will not be written, deferred error of write will be reported later.
<HG - RE: Comment>
Again, I regret my explanation was not sufficient for complete understanding
of my meaning.  Please consider this to be "The host will expect the data to
have been succesfully written and the device to be ready for the next
command."  This understanding will make more sense as I described the
problem inherent in this:

Furthermore, in a complex host environment, it is not possible to ensure
that a GESN event will follow each command.  One example is when an
operating system implicitly allows commands (I/O) to be reordered within a
device driver stack, or have I/O inserted between existing commands.
Therefore, it is quite possible and even likely that a complex host would
not send a GESN event immediately following such a command and therefore
never get the Device Busy event.  Before discussing case C at length, I must
first quote from MMC3r10g:
"This type of event is usable in two environments. The first is in a queued
environment. The GET EVENT/STATUS NOTIFICATION command may be issued in a
non-immediate mode prior to executing commands or in the immediate mode
while commands are being executed. The second environment is where immediate
commands and deferred writing are performed; this command may be issued in
the immediate mode to obtain status. If a normal command is issued while the
device is busy, this command cannot be issued until the normal command
completes. Therefore, if queuing is not used, the GET EVENT/STATUS
NOTIFICATION command should precede any command that may time out."
The specific example of the write/read commands is not a good example, as
the LU cannot know what the next command the device will receive. Therefore,
it cannot know the correct Device Busy time to put into the event. For
example, a series of WRITE commands would not report a Device Busy event
between any of those commands in many cases. However, if a READ command were
inserted into that sequence, a Device Busy event may be required per the
diagram in the document. Therefore, I think it is not possible for a LU to
implement this because the LU cannot know the next command that will be sent
to the device.
<KK - Comment>
I agree with you that device cannot know the next command. But host can know
it. Then host shall use the GET EVENT/STATUS NOTIFICATION command prior to
issuing the next command that may time-out. The paragraph that you quoted
describes host operation, not device behavior. Only host can issue commands.
Only host can select an environment. Regardless of difficulty of
implementation you stated, if host used this command at the best timing,
host can get correct information that is described in 11.0 Time-out model.
<HG - RE: Comment>
This requires a monolithic architecture, wherein the CDROM driver and the
transport driver are tightly interlinked.  In the majority of the OSs
installed in the market today, this is not the case.  The architecture of
these OSs allows commands and IO to be reordered by any driver in the device
stack.  There is no guarantee of ordering of operations, meaning that an
intermediate command sent by a different initiator can occur before the GESN
command occurs.  This then results in the device asserting the busy bit, and
then a bus reset occurs because that unexpected command is taking an
abnormally long time.  I restate my assertion that disabling of timeouts is
not a good idea; this has and will continue to cause problems.

Instead, let us consider case C for another type of command that takes an
abnormally long time to complete (Format Unit, Blank, Close Track/Session,
etc., always considered with IMMED=1).
<KK - Comment>
I think here is a mismatch understanding between you and I. The "abnormally
long time to complete" does not include Format Unit, Blank, Close
Track/Session, etc. with IMMED=1. The command with IMMED=1 is terminated
normally without any trouble. The general description of this section
"Device Busy Events are used to notify the host of commands that are
executing but that require an abnormally long time to complete" covers
single command execution - termination only. If a command that is executed
but takes abnormally long time to terminate, a device busy event should be
generated. If a Read command takes abnormally longer time than Group 1
time-out value, device shall report a device busy event to host.
<HG - RE: Comment>
This is a very clear explanation of your understanding of the usage of the
Device Busy event.  I still believe there are significant issues surrounding
the use of this model of the Device Busy event, as described briefly above.
Most disturbing are the cases where the device disables timeouts due to a
device busy event.  It is especially disturbing if you consider that one
application (not a driver or file system) could send a GESN request, and if
the device then disables timeouts.  This would obviously cause significant
problems with the existing drivers/file systems.

In these cases, one can read the above MMC3 section as stating that any GESN
Device Busy request received by the LU shall report the time from the
receipt of the GESN command until the LU will be able to handle additional
commands.  While Katata-san describes this as "progress", the real
information contained in the event is only the amount of time until the LU
is ready to process additional commands.
>From here, I think there are two possible paths that devices can follow.

The first is, when such a long command is executing, that the LU reports a
zero value, as commands will be failed with 2/4/7 or 2/4/8 as necessary. In
such a case, the Device Busy events are meaningless, so let us not consider
this as a correct solution.  The second path is that the LU reports the
approximate time to the completion of the long immediate command. In this
case, the host can use this information.
In fact, with proper driver software, all drivers and software can be
simultaneously informed of the time until the LU is no longer busy.  (This
is what the MMCTest provided by Microsoft's WHQL has been using during
BLANK, FORMAT UNIT, and CLOSE SESSION/TRACK command testing for some time.)
<KK - Comment>
You and I have different definition for Device Busy Event.  Your definition
of Device Busy Event is that device reports remaining time to be ready by
this event. Therefore Time field has remaining time to be ready.  My
definition is that device reports Group 1 time-out signal by this event.
Therefore Time field has expanded working time.  In your definition, there
are many inconsistencies that I explain.
1.	Device Busy Event is made for 11.0 Time-out model. This is clear
because general description of device busy event has this sentence "See
Section 11.0, "Time-out and Reset models" on page 217." But your definition
cannot cover this general description.
2.	The remaining time of the current operation is progress indication.
But the description of progress indication in BLANK, FORMAT UNIT, and CLOSE
SESSION/TRACK command does not point to Device Busy Event. This means that
the members who created this document did not have such intention.
3.	If GESN has progress indication capability, much application may use
the function. It will cause that OS loses important event signals like UNIT
ATTENTION condition due to application polling. I believe this is not
intention of who created this document.
<HG - RE: Comment>
You have a good understanding of my understanding of the usage of the device
busy event.  One item not clearly understood is shown in #3 above, however.
At least some operating systems which ask for the device busy event have
already solved the problem of converting the event from unicast to multicast
through the use of operating system specific methods.  So, this "issue" is
not an issue.  For #2, the lack of clear links between all such commands
would be significant; many such links are simply not included in the
document when commands are so slightly related.  Therefore, #2 is not
sufficient to consider this understanding in error.  #1 only refers to
timeouts in saying that they should be disabled; I believe I have shown that
this is a dangerous path for a LU to take for complex host environments.
Therefore, it has been understood that this was in error as the
specification used for development here is the MMC document (which has no
Timeout model).  Perhaps this understanding was not correct, but also
attempting to use the intended method would also be impossible to do in a
complex host environment.

<HG - RE: Comment>
So, to summarize, Katata-san and I both understand the other's understanding
of device busy events.  Katata-san's understanding of the specification is
full of issues in a complex host environment.  My understanding of the
specification does not have these issues, but does not address the reference
(in Mt. Fuji only) to the timeout model section.

<HG - RE: Comment>
I must stress that I do not believe the Device Busy events, as understood by
Katata-san, are usable in complex hosts environments.  My understanding of
the specification was driven by what could be used practically in my current
environment without major architectural changes or backwards compatibility
issues.  I believe that it is technically not reasonable to have all
existing host environments be updated to use the specification as understood
by Katata-san, due to architectural designs that cannot be currently
changed.

<HG - RE: Comment>
So, how to solve this problem?
.
 

-----Original Message-----
From: owner-mtfuji5 at avc-pioneer.com [mailto:owner-mtfuji5 at avc-pioneer.com]
On Behalf Of keiji_katata at post.pioneer.co.jp
Sent: Monday, November 03, 2003 2:04 PM
To: mtfuji5 at avc-pioneer.com
Cc: twg3 at ml.cds21solutions.org; T10 at t10.org
Subject: RE: Progress Indication function in Device Busy Event#2


Hi Henry and all,

I wrote my comment in attached word document.

I want to know members understanding.

1. Device Busy is designed for progress indication.
2. Device Busy is designed for time-out event reporting.

Which is your understanding for the definition of device busy event?

Best regards,

Keiji Katata
PIONEER CORP.

(See attached file: comment.zip)

------=_NextPart_001_0058_01C3A21F.30E02E30
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">

 RE: Progress Indication function in Device Busy Event#2 
It is = difficult to use a word document to reply to e-mail.  Please keep = future comments in e-mail.  I must use RTF format now to make it = clear whose comments are whose. I agree with you for current actual = implementations. But MMC3 standard and Fuji Specification are made as = physical bus independent documents. They must be consistent for any = environments. For my discussions, I chose to restrict the = discussion for simplicity, not because the use was invalid.  I = regret any confusion that may have caused. You need to explain to Device manufactures why you = need progress indication in time unit. Otherwise, many people who cannot = attend MMC4 WG due to too far distance from their countries, will not = accept your opinion. The explanation was done in full at the MMC = meeting, and allowed questions to occur and be answered quickly.  = The summary is: (A) In complex environment, driver and application are = seperated. (B) driver cannot know all commands being sent by application = or other drivers. (C) Therefore, it is not possible to ensure that GESN = commands are occurring before each command which can timeout.  (D) = It is also not possible to know ahead of time if an application (or = other driver) has caused device to become not-ready (such as due to = format, blank, etc).  (E) If a device is not ready, it is not = possible for anyone other than the initiator to know how long it will = take for the device to become ready.  (for simplicity, let use = consider the case of an application formatting media.)  Therefore, = when the application causes a device to end up in a not-ready state, it = is not reasonable for the driver to detect the time it will take for the = device to become ready.  This prevents, in many cases, the ability = of the host driver to make an informed decision as to whether to retry = some IO after a small delay or simply fail the request with a busy = status.  This then results in situations where a computer program = may appear to ;hang; for a significant period of time as the = IO is retried due to a device busy condition. Device shall report time-out event = ;before; or ;after; the command that may cause = Group 1 time-out, is issued. The ;before; is in case of = polling mode. The ;after; is in case of queued = mode. If instead you are saying the previous command's = long execution would cause the next GESN to report a DeviceBusy event, = then it is assumed that commands are linked from the host.  Linked = commands in complex host environments are not supported; IO can be = reorderd prior to being processed by the LU, and multiple initiators = (drivers and applications) further enhance this problem.  = Therefore, I think it is not reasonable to expect a device busy event to = occur from the previous command, but only predictively for the = next command(s).  But, if sent before a command, how can the LU = determine if the following command will exceed the typical = timeout?  I do not think this is possible. Actually you need not consider Method 2 because you = do not have a plane to use command queuing in ATAPI environment. But it = is your case only, not for all people. For example, Pioneer has products = that support ATAPI overlap feature. Because several customer need this = feature. So if queuing is required, why I should not use = it? For my discussions, I chose to restrict the = discussion for simplicity, not because the use was invalid.  I = regret any confusion that may have caused. 
<KK - Comment> 
This Method 4 is your talking. You said that Device = Busy Event reports Progress Indication instead of time-out signal and = Expanded Working Time. The Method 4 is not that reported by myself, or the = diagram is unclear.  I have described this repeatedly as ;Time = until the device is ready;; only you, Katata-san, are repeatedly = describing this as ;Progress Indication;.  I ask that you = do not use this term, as it confuses the issue. (B) device continues to asset the busy bit (ATAPI = example) saying it is not ready for next command, 
(C) host sends GESN prior to READ command to get = Device Busy. 
In case B, the host will eventually force the = command to terminate due to the command's timeout setting. I do not = believe this could be the intention of the = specification. The case B has happened in the real market. Then = 11.0 Time-out model is created. If device reports time-out signal to = host, host can know that device does not hang up and host can wait the = finish of the command without RESET.. Case B has happened in the real market, and has = resulting in the device being reset by some host OS = implementations.  The reason is that, in at least one OS = implementation, the timeout for a command is predetermined, and the = device is expected to become ready within that timeout period.  The = expectation in your reading of the specifation requires a much more = monolithic implementation of the CD device driver and the transport = driver (ATAPI, 1394, etc.) to prevent a bus reset when a command times = out.  The market reality is that most devices will be running on = OSs which will reset the bus if the busy bit is not cleared (and cause = the device to disappear if it continues to assert the busy bit after the = reset). 
<KK - Comment> 
Host will expect it. But it is not confirmed. If = OPC failure occurred, any data will not be written, deferred error of = write will be reported later. Again, I regret my explanation was not sufficient = for complete understanding of my meaning.  Please consider this to = be ;The host will expect the data to have been succesfully written = and the device to be ready for the next command.;  This = understanding will make more sense as I described the problem inherent = in this: I agree with you that device cannot know the next = command. But host can know it. Then host shall use the GET EVENT/STATUS = NOTIFICATION command prior to issuing the next command that may = time-out. The paragraph that you quoted describes host operation, not = device behavior. Only host can issue commands. Only host can select an = environment. Regardless of difficulty of implementation you stated, if = host used this command at the best timing, host can get correct = information that is described in 11.0 Time-out model. This requires a monolithic architecture, wherein = the CDROM driver and the transport driver are tightly interlinked.  = In the majority of the OSs installed in the market today, this is not = the case.  The architecture of these OSs allows commands and IO to = be reordered by any driver in the device stack.  There is no = guarantee of ordering of operations, meaning that an intermediate = command sent by a different initiator can occur before the GESN command = occurs.  This then results in the device asserting the busy bit, = and then a bus reset occurs because that unexpected command is taking an = abnormally long time.  I restate my assertion that disabling of = timeouts is not a good idea; this has and will continue to cause = problems. I think here is a mismatch understanding between = you and I. The ;abnormally long time to complete; does not = include Format Unit, Blank, Close Track/Session, etc. with IMMED=3D1. = The command with IMMED=3D1 is terminated normally without any trouble. = The general description of this section ;Device Busy Events are = used to notify the host of commands that are executing but that require = an abnormally long time to complete; covers single command = execution - termination only. If a command that is executed but takes = abnormally long time to terminate, a device busy event should be = generated. If a Read command takes abnormally longer time than Group 1 = time-out value, device shall report a device busy event to = host. This is a very clear explanation of your = understanding of the usage of the Device Busy event.  I still = believe there are significant issues surrounding the use of this model = of the Device Busy event, as described briefly above.  Most = disturbing are the cases where the device disables timeouts due to a = device busy event.  It is especially disturbing if you consider = that one application (not a driver or file system) could send a GESN = request, and if the device then disables timeouts.  This would = obviously cause significant problems with the existing drivers/file = systems. You and I have different definition for Device Busy = Event.  Your definition of Device Busy Event is that device reports = remaining time to be ready by this event. Therefore Time field has = remaining time to be ready.  My definition is that device reports = Group 1 time-out signal by this event. Therefore Time field has expanded = working time.  In your definition, there are many inconsistencies = that I explain. You have a good understanding of my understanding = of the usage of the device busy event.  One item not clearly = understood is shown in #3 above, however.  At least some operating = systems which ask for the device busy event have already solved the = problem of converting the event from unicast to multicast through the = use of operating system specific methods.  So, this = ;issue; is not an issue.  For #2, the lack of clear links = between all such commands would be significant; many such links are = simply not included in the document when commands are so slightly = related.  Therefore, #2 is not sufficient to consider this = understanding in error.  #1 only refers to timeouts in saying that = they should be disabled; I believe I have shown that this is a dangerous = path for a LU to take for complex host environments.  Therefore, it = has been understood that this was in error as the specification used for = development here is the MMC document (which has no Timeout model).  = Perhaps this understanding was not correct, but also attempting to use = the intended method would also be impossible to do in a complex host = environment. So, to summarize, Katata-san and I both understand = the other's understanding of device busy events.  Katata-san's = understanding of the specification is full of issues in a complex host = environment.  My understanding of the specification does not have = these issues, but does not address the reference (in Mt. Fuji only) to = the timeout model section. I must stress that I do not believe the Device Busy = events, as understood by Katata-san, are usable in complex hosts = environments.  My understanding of the specification was driven by = what could be used practically in my current environment without major = architectural changes or backwards compatibility issues.  I believe = that it is technically not reasonable to have all existing host = environments be updated to use the specification as understood by = Katata-san, due to architectural designs that cannot be currently = changed. So, how to solve this problem? 
. 
From: = owner-mtfuji5 at avc-pioneer.com [] On Behalf Of = keiji_katata at post.pioneer.co.jp 
Sent: = Monday, November 03, 2003 2:04 PM 
To: = mtfuji5 at avc-pioneer.com 
Cc: = twg3 at ml.cds21solutions.org; T10 at t10.org 
Subject: = RE: Progress Indication function in Device Busy Event#2 
Hi Henry and = all, I wrote my = comment in attached word document. I want to = know members understanding. 1. Device = Busy is designed for progress indication. 
2. Device = Busy is designed for time-out event reporting. Which is = your understanding for the definition of device busy = event? Best = regards, Keiji = Katata 
PIONEER = CORP. (See = attached file: comment.zip) 
------=_NextPart_001_0058_01C3A21F.30E02E30--

------=_NextPart_000_0057_01C3A21F.30E02E30
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIe3jCCA7Ew
ggKZoAMCAQICEGLjZmVSIbeyRuVfQYoWnmIwDQYJKoZIhvcNAQEFBQAwTDELMAkGA1UEBhMCVVMx
EjAQBgNVBAoTCU1pY3Jvc29mdDEOMAwGA1UECxMFTnRkZXYxGTAXBgNVBAMTEE5UREVWIFNBIFJv
b3QgQ0EwHhcNMDIwODA3MDM0NTAyWhcNMDcwODA3MDM1NTAyWjBMMQswCQYDVQQGEwJVUzESMBAG
A1UEChMJTWljcm9zb2Z0MQ4wDAYDVQQLEwVOdGRldjEZMBcGA1UEAxMQTlRERVYgU0EgUm9vdCBD
QTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAOoI+NpQ4wnW1e11kPkhTnigAO0ked3R
JGftlHdGD3DPOwNAkTRzTtSIQTYZkTx+Asu+aoqsru6ed6W/Mxhd7+DxQ2E6nXFvPd7WnSMqEBrA
ITOWcEpSZaS2afWL7up5R7w6PZl8+lheotfJVMdUgDtBvgBC8xTs7PD+zT09iZ4PchILTK0DdKXU
J163rordZSG0cmeCV+pz1/EtBtw6uD8tLsDlIcNWQnph4McYjmNf6jdtuzuwr++CGHi5SEAhHLl0
WjtwzAFltSfRmj2VcljijzpTPEj0lHnXH/G49ohh24NexdzQ0KHjajkM36rIfJplmACDkzmIvl6S
jkyzJW0CAwEAAaOBjjCBizATBgkrBgEEAYI3FAIEBh4EAEMAQTALBgNVHQ8EBAMCAUYwDwYDVR0T
AQH/BAUwAwEB/zAdBgNVHQ4EFgQUiMnNnJw6IoDq5C3aFUcv9fvEvJswEgYJKwYBBAGCNxUBBAUC
AwEAATAjBgkrBgEEAYI3FQIEFgQUnpC7JiTk2txjEbgYLa+tOVaBZlEwDQYJKoZIhvcNAQEFBQAD
ggEBAFhv2fkYKXwaad2xA9h+RjyS8twwPfcAuPRD+W7kvsvBtPeoI4cpMU+f12+SH1WfdhNErRYs
I2Whc+Xlkqm6KLZtUG52qNsHI5aRB2zHVYXLFdFnSZ0xFOsu9y11fh/6Yv3SS7etGrLVtOdzfeOL
xzosK8ZbdBh/wF1b/jB/orp4bgXqsGqQyXGLanR29TLLT2QZjzrt8k9tMM1u+vjQ1tHNEK7qfm4D
plgZUu4wK/QZLwCYoz4u29mQSJ6TWC0VoFQeZu2cv2jtIikzYR/HI9PNJv5AErQ63RJOLy45GosR
S14poZyAoFv9233bFpHXnXz/oeMnW1Rwr5p4JBxsFLEwggWSMIIFUqADAgECAgoppSGSAAUAAAIg
MAkGByqGSM44BAMwYTELMAkGA1UEBhMCVVMxEjAQBgNVBAoTCU1pY3Jvc29mdDEOMAwGA1UECxMF
TnRkZXYxLjAsBgNVBAMTJU5UREVWIEludGVybWVkaWF0ZSBTdWJvcmRpbmF0ZSBXaGljYTIwHhcN
MDIxMDEwMjA0MzA3WhcNMDQxMDEwMjA1MzA3WjBLMQswCQYDVQQGEwJVUzESMBAGA1UEChMJTWlj
cm9zb2Z0MQ4wDAYDVQQLEwVOdGRldjEYMBYGA1UEAxMPTlRERVYgSVNTVUUzIENBMIGfMA0GCSqG
SIb3DQEBAQUAA4GNADCBiQKBgQCslBWXY0NTtIV2J0MY5hQTlVtFlPH3K27ZVXbdGUMe0szXI/jh
rktkRDINZX0v6ej3CWL9mSvqqeVfYUJ4RDcuNjjx1tBibQ5Tk4ujVXIiXdJwKTBiu3YqDhv8ajoj
ZgASrQnAOz+qNGt3EP1Sn0YaNxjPvpy7yLFDd3O7QjxngQIDAQABo4IDwDCCA7wwDwYDVR0TAQH/
BAUwAwEB/zAdBgNVHQ4EFgQUi9HNYfHpr468kdBA6im/5i6FQFcwCwYDVR0PBAQDAgGGMBIGCSsG
AQQBgjcVAQQFAgMCAAMwIwYJKwYBBAGCNxUCBBYEFG63AnsLfqwCcPqopI+9FMOWUqPPMBEGA1Ud
IAQKMAgwBgYEVR0gADAZBgkrBgEEAYI3FAIEDB4KAFMAdQBiAEMAQTAfBgNVHSMEGDAWgBTivgNw
1Ysg0kFEaq/myHdxWiUAHzCCAWkGA1UdHwSCAWAwggFcMIIBWKCCAVSgggFQhoHnbGRhcDovLy9D
Tj1OVERFViUyMEludGVybWVkaWF0ZSUyMFN1Ym9yZGluYXRlJTIwV2hpY2EyKDQpLENOPXdoaWNh
MixDTj1DRFAsQ049UHVibGljJTIwS2V5JTIwU2VydmljZXMsQ049U2VydmljZXMsQ049Q29uZmln
dXJhdGlvbixEQz1udGRldixEQz1jb3JwLERDPW1pY3Jvc29mdCxEQz1jb20/Y2VydGlmaWNhdGVS
ZXZvY2F0aW9uTGlzdD9iYXNlP29iamVjdENsYXNzPWNSTERpc3RyaWJ1dGlvblBvaW50hmRodHRw
Oi8vd2hpY2EyLm50ZGV2LmNvcnAubWljcm9zb2Z0LmNvbS9DZXJ0RW5yb2xsL05UREVWJTIwSW50
ZXJtZWRpYXRlJTIwU3Vib3JkaW5hdGUlMjBXaGljYTIoNCkuY3JsMIIBhgYIKwYBBQUHAQEEggF4
MIIBdDCB3QYIKwYBBQUHMAKGgdBsZGFwOi8vL0NOPU5UREVWJTIwSW50ZXJtZWRpYXRlJTIwU3Vi
b3JkaW5hdGUlMjBXaGljYTIsQ049QUlBLENOPVB1YmxpYyUyMEtleSUyMFNlcnZpY2VzLENOPVNl
cnZpY2VzLENOPUNvbmZpZ3VyYXRpb24sREM9bnRkZXYsREM9Y29ycCxEQz1taWNyb3NvZnQsREM9
Y29tP2NBQ2VydGlmaWNhdGU/YmFzZT9vYmplY3RDbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5
MIGRBggrBgEFBQcwAoaBhGh0dHA6Ly93aGljYTIubnRkZXYuY29ycC5taWNyb3NvZnQuY29tL0Nl
cnRFbnJvbGwvd2hpY2EyLm50ZGV2LmNvcnAubWljcm9zb2Z0LmNvbV9OVERFViUyMEludGVybWVk
aWF0ZSUyMFN1Ym9yZGluYXRlJTIwV2hpY2EyKDUpLmNydDAJBgcqhkjOOAQDAy8AMCwCFG0a0eml
aHCZ0XREh9+8PT+SuANMAhQLuEXjuaULz1r4zciD4EyvpGjZ7DCCBpMwggX8oAMCAQICCjXOzR8A
AwAt9cwwDQYJKoZIhvcNAQEFBQAwSzELMAkGA1UEBhMCVVMxEjAQBgNVBAoTCU1pY3Jvc29mdDEO
MAwGA1UECxMFTnRkZXYxGDAWBgNVBAMTD05UREVWIElTU1VFMyBDQTAeFw0wMzA1MjcyMzUxNDVa
Fw0wNDA1MjYyMzUxNDVaMIGXMRMwEQYKCZImiZPyLGQBGRYDY29tMRkwFwYKCZImiZPyLGQBGRYJ
bWljcm9zb2Z0MRQwEgYKCZImiZPyLGQBGRYEY29ycDEVMBMGCgmSJomT8ixkARkWBW50ZGV2MQww
CgYDVQQLEwNJVEcxDjAMBgNVBAsTBVVzZXJzMRowGAYDVQQDExFIZW5yeSBHYWJyeWplbHNraTCB
nzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEApDw0/Y2NxREP+Jq9GI+qCHJEoX+oYJ7x0u4ENHaj
CbJ5BbcdIO8IcZJ17OirUUAQQMLiLZKboZCWB4+uG+ee23iJn1QzAfQaacJzgSKqlE0T98EAdc7f
uY7RCoKG2EsjPa3MZWLoxlEH6Z12O+LRwCTGbLBQBGIEYeN50T1m+dECAwEAAaOCBC8wggQrMAsG
A1UdDwQEAwIHgDAdBgNVHQ4EFgQU73Wh7Ne6dK4H26qra0rzcTA3N5wwPgYJKwYBBAGCNxUHBDEw
LwYnKwYBBAGCNxUIjeDRiU6E15zDB4amhvscj9O/phWCv5z2fIbe5oBUAgF4AgEBMB8GA1UdIwQY
MBaAFIvRzWHx6a+OvJHQQOopv+YuhUBXMIIBiAYDVR0fBIIBfzCCAXswggF3oIIBc6CCAW+Ggc9s
ZGFwOi8vL0NOPU5UREVWJTIwSVNTVUUzJTIwQ0EoMiksQ049V0hJQ0EzLENOPUNEUCxDTj1QdWJs
aWMlMjBLZXklMjBTZXJ2aWNlcyxDTj1TZXJ2aWNlcyxDTj1Db25maWd1cmF0aW9uLERDPW50ZGV2
LERDPWNvcnAsREM9bWljcm9zb2Z0LERDPWNvbT9jZXJ0aWZpY2F0ZVJldm9jYXRpb25MaXN0P2Jh
c2U/b2JqZWN0Q2xhc3M9Y1JMRGlzdHJpYnV0aW9uUG9pbnSGTWh0dHA6Ly93aGljYXdlYi5udGRl
di5jb3JwLm1pY3Jvc29mdC5jb20vTlRERVZDUkxzL05UREVWJTIwSVNTVUUzJTIwQ0EoMikuY3Js
hkxodHRwOi8vd2hpY2EzLm50ZGV2LmNvcnAubWljcm9zb2Z0LmNvbS9DZXJ0RW5yb2xsL05UREVW
JTIwSVNTVUUzJTIwQ0EoMikuY3JsMIIBVAYIKwYBBQUHAQEEggFGMIIBQjCBxQYIKwYBBQUHMAKG
gbhsZGFwOi8vL0NOPU5UREVWJTIwSVNTVUUzJTIwQ0EsQ049QUlBLENOPVB1YmxpYyUyMEtleSUy
MFNlcnZpY2VzLENOPVNlcnZpY2VzLENOPUNvbmZpZ3VyYXRpb24sREM9bnRkZXYsREM9Y29ycCxE
Qz1taWNyb3NvZnQsREM9Y29tP2NBQ2VydGlmaWNhdGU/YmFzZT9vYmplY3RDbGFzcz1jZXJ0aWZp
Y2F0aW9uQXV0aG9yaXR5MHgGCCsGAQUFBzAChmxodHRwOi8vd2hpY2EzLm50ZGV2LmNvcnAubWlj
cm9zb2Z0LmNvbS9DZXJ0RW5yb2xsL1dISUNBMy5udGRldi5jb3JwLm1pY3Jvc29mdC5jb21fTlRE
RVYlMjBJU1NVRTMlMjBDQSgzKS5jcnQwEwYDVR0lBAwwCgYIKwYBBQUHAwQwLQYDVR0gBCYwJDAi
BiArBgEEAYI3FQiN4NGJToTXnMMHhqaG+xyP07+mFQGDETAbBgkrBgEEAYI3FQoEDjAMMAoGCCsG
AQUFBwMEMFcGA1UdEQRQME6gLAYKKwYBBAGCNxQCA6AeDBxoZW5yeWdhYkBudGRldi5taWNyb3Nv
ZnQuY29tgR5oZW5yeWdhYkB3aW5kb3dzLm1pY3Jvc29mdC5jb20wDQYJKoZIhvcNAQEFBQADgYEA
oZngVwmM+HPyxenzFt48CJ4RNlb/ze9TkwjZ1gW19Mz/B4l8EQOg9r1zEI2w4P++vJmNNOKDVqVB
eVxVNWnNB1IlS4WPvB0A38o+K+M8c/QRIrgEiYRpzssIED7LXibov4t7fuESumrCar3nPtrTRC11
qVeQAzmAtYk/r6biIMkwggbZMIIGQqADAgECAgo1ztDoAAMALfXNMA0GCSqGSIb3DQEBBQUAMEsx
CzAJBgNVBAYTAlVTMRIwEAYDVQQKEwlNaWNyb3NvZnQxDjAMBgNVBAsTBU50ZGV2MRgwFgYDVQQD
Ew9OVERFViBJU1NVRTMgQ0EwHhcNMDMwNTI3MjM1MTQ2WhcNMDQwNTI2MjM1MTQ2WjCBxjETMBEG
CgmSJomT8ixkARkWA2NvbTEZMBcGCgmSJomT8ixkARkWCW1pY3Jvc29mdDEUMBIGCgmSJomT8ixk
ARkWBGNvcnAxFTATBgoJkiaJk/IsZAEZFgVudGRldjEMMAoGA1UECxMDSVRHMQ4wDAYDVQQLEwVV
c2VyczEaMBgGA1UEAxMRSGVucnkgR2FicnlqZWxza2kxLTArBgkqhkiG9w0BCQEWHmhlbnJ5Z2Fi
QHdpbmRvd3MubWljcm9zb2Z0LmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAqga01zJv
LSABhM0uYw6cToJN42MVO6GZLSSKMu/07RxyBKccVUxwBfltmq+ZJd0I8yMIW6aoZAT6i18JrjPf
LDSM3w/Z+GZx8cjjwCdY7gim5M3bAv6BPdMOEihZyvWVASBGHfMbxE2HuWuCpKegxczZnM2uSohg
76wKeUsoA+8CAwEAAaOCBEYwggRCMAsGA1UdDwQEAwIEMDBEBgkqhkiG9w0BCQ8ENzA1MA4GCCqG
SIb3DQMCAgIAgDAOBggqhkiG9w0DBAICAIAwBwYFKw4DAgcwCgYIKoZIhvcNAwcwHQYDVR0OBBYE
FK0Q1TO1Y6qIT1/Gxn/7p7QJ1k0/MD4GCSsGAQQBgjcVBwQxMC8GJysGAQQBgjcVCI3g0YlOhNec
wweGpob7HI/Tv6YVh6e+4gmOsa3xTQIBeAIBATAfBgNVHSMEGDAWgBSL0c1h8emvjryR0EDqKb/m
LoVAVzCCAYgGA1UdHwSCAX8wggF7MIIBd6CCAXOgggFvhoHPbGRhcDovLy9DTj1OVERFViUyMElT
U1VFMyUyMENBKDIpLENOPVdISUNBMyxDTj1DRFAsQ049UHVibGljJTIwS2V5JTIwU2VydmljZXMs
Q049U2VydmljZXMsQ049Q29uZmlndXJhdGlvbixEQz1udGRldixEQz1jb3JwLERDPW1pY3Jvc29m
dCxEQz1jb20/Y2VydGlmaWNhdGVSZXZvY2F0aW9uTGlzdD9iYXNlP29iamVjdENsYXNzPWNSTERp
c3RyaWJ1dGlvblBvaW50hk1odHRwOi8vd2hpY2F3ZWIubnRkZXYuY29ycC5taWNyb3NvZnQuY29t
L05UREVWQ1JMcy9OVERFViUyMElTU1VFMyUyMENBKDIpLmNybIZMaHR0cDovL3doaWNhMy5udGRl
di5jb3JwLm1pY3Jvc29mdC5jb20vQ2VydEVucm9sbC9OVERFViUyMElTU1VFMyUyMENBKDIpLmNy
bDCCAVQGCCsGAQUFBwEBBIIBRjCCAUIwgcUGCCsGAQUFBzAChoG4bGRhcDovLy9DTj1OVERFViUy
MElTU1VFMyUyMENBLENOPUFJQSxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNlcyxDTj1TZXJ2aWNl
cyxDTj1Db25maWd1cmF0aW9uLERDPW50ZGV2LERDPWNvcnAsREM9bWljcm9zb2Z0LERDPWNvbT9j
QUNlcnRpZmljYXRlP2Jhc2U/b2JqZWN0Q2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTB4Bggr
BgEFBQcwAoZsaHR0cDovL3doaWNhMy5udGRldi5jb3JwLm1pY3Jvc29mdC5jb20vQ2VydEVucm9s
bC9XSElDQTMubnRkZXYuY29ycC5taWNyb3NvZnQuY29tX05UREVWJTIwSVNTVUUzJTIwQ0EoMyku
Y3J0MBMGA1UdJQQMMAoGCCsGAQUFBwMEMBsGCSsGAQQBgjcVCgQOMAwwCgYIKwYBBQUHAwQwVwYD
VR0RBFAwTqAsBgorBgEEAYI3FAIDoB4MHGhlbnJ5Z2FiQG50ZGV2Lm1pY3Jvc29mdC5jb22BHmhl
bnJ5Z2FiQHdpbmRvd3MubWljcm9zb2Z0LmNvbTANBgkqhkiG9w0BAQUFAAOBgQA0d0I1vP6vEoPc
/iIwofo/lxWbPQOPOVlnBufGbf4UL6+KR0sU//EyKGAi1KYupQXLm1NLkvbUTtFQNiKQSwnwVYqw
Th45C6tLkYRvhvMds8ogSIojSZWhRpoG0SLcDVoaUYqIiryh/lf3ZczCy8ZwX1WCp+hy2/KBzSk1
EFLJ8TCCCBswggcDoAMCAQICCijG53IAAQAAADUwDQYJKoZIhvcNAQEFBQAwTDELMAkGA1UEBhMC
VVMxEjAQBgNVBAoTCU1pY3Jvc29mdDEOMAwGA1UECxMFTnRkZXYxGTAXBgNVBAMTEE5UREVWIFNB
IFJvb3QgQ0EwHhcNMDIxMDEwMTYzMzAwWhcNMDUxMDEwMTY0MzAwWjBhMQswCQYDVQQGEwJVUzES
MBAGA1UEChMJTWljcm9zb2Z0MQ4wDAYDVQQLEwVOdGRldjEuMCwGA1UEAxMlTlRERVYgSW50ZXJt
ZWRpYXRlIFN1Ym9yZGluYXRlIFdoaWNhMjCCAbcwggErBgcqhkjOOAQBMIIBHgKBgQD6Es97u5iw
ea4ZR+QhOQGpawZejbbLfr2SzT0T4SPAAazbhymFpUeoVnf4pD+SDIA0K+w1KSa63b+Gdk9aST1R
ByMQrmtx01/6Pl1Rk2V3Qb+MfjoRy5rddSnE8vQftLaYN6bCQuJvrWjjWm3fssPxAfQKD5XRnR6B
gQUhjnQC4wIVAJhPlD2ydVrV6RStlMJjOhv86OtDAoGAZsoPfe8UED5wq+CK2salIubF17L0j74p
sDv1BBcScAIlkvDlLp754exndP7HA+WDZFQLG0WBflzYMmFQrGLrAtSx/A76Ds6uB8/JYPSv9pAP
NL9kpK+Ax9RBTNiRtyfR26t+tg5PYvFehwGRAPz/JAffyfnCNS6F5VrX8ObmgpgDgYUAAoGBAKJK
0lYkyELe2RtGLY69hi3HKuW08w7JlHUTkM9aovXm+XDiGGtmF4BOnJmUyCBTi8emz3YG8GUgLDnw
UKH0KCxt7yXkHBrAP74+8M45s5WiJmLARfTmURSpewt6/0y0oR1wU0B6Nes3Ahriwl4ULzrK4yYZ
Sr4b0eXzJjaTiuI5o4IEUzCCBE8wDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQU4r4DcNWLINJB
RGqv5sh3cVolAB8wCwYDVR0PBAQDAgGGMBIGCSsGAQQBgjcVAQQFAgMEAAUwIwYJKwYBBAGCNxUC
BBYEFNZSKDdZIeNtheISai1jbapovGtAMBkGCSsGAQQBgjcUAgQMHgoAUwB1AGIAQwBBMB8GA1Ud
IwQYMBaAFIjJzZycOiKA6uQt2hVHL/X7xLybMIIBmQYDVR0fBIIBkDCCAYwwggGIoIIBhKCCAYCG
gdlsZGFwOi8vL0NOPU5UREVWJTIwU0ElMjBSb290JTIwQ0EoMSksQ049d2hpY2FzYXJvb3RjYSxD
Tj1DRFAsQ049UHVibGljJTIwS2V5JTIwU2VydmljZXMsQ049U2VydmljZXMsQ049Q29uZmlndXJh
dGlvbixEQz1udGRldixEQz1jb3JwLERDPW1pY3Jvc29mdCxEQz1jb20/Y2VydGlmaWNhdGVSZXZv
Y2F0aW9uTGlzdD9iYXNlP29iamVjdENsYXNzPWNSTERpc3RyaWJ1dGlvblBvaW50hlFodHRwOi8v
d2hpY2F3ZWIubnRkZXYuY29ycC5taWNyb3NvZnQuY29tL0NlcnRFbnJvbGwvTlRERVYlMjBTQSUy
MFJvb3QlMjBDQSgxKS5jcmyGT2h0dHA6Ly93aGljYTMubnRkZXYuY29ycC5taWNyb3NvZnQuY29t
L0NlcnRFbnJvbGwvTlRERVYlMjBTQSUyMFJvb3QlMjBDQSgxKS5jcmwwggHpBggrBgEFBQcBAQSC
AdswggHXMIHIBggrBgEFBQcwAoaBu2xkYXA6Ly8vQ049TlRERVYlMjBTQSUyMFJvb3QlMjBDQSxD
Tj1BSUEsQ049UHVibGljJTIwS2V5JTIwU2VydmljZXMsQ049U2VydmljZXMsQ049Q29uZmlndXJh
dGlvbixEQz1udGRldixEQz1jb3JwLERDPW1pY3Jvc29mdCxEQz1jb20/Y0FDZXJ0aWZpY2F0ZT9i
YXNlP29iamVjdENsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwgYQGCCsGAQUFBzAChnhodHRw
Oi8vd2hpY2F3ZWIubnRkZXYuY29ycC5taWNyb3NvZnQuY29tL0NlcnRFbnJvbGwvd2hpY2FzYXJv
b3RjYS5udGRldi5jb3JwLm1pY3Jvc29mdC5jb21fTlRERVYlMjBTQSUyMFJvb3QlMjBDQSgxKS5j
cnQwgYIGCCsGAQUFBzAChnZodHRwOi8vd2hpY2EzLm50ZGV2LmNvcnAubWljcm9zb2Z0LmNvbS9D
ZXJ0RW5yb2xsL3doaWNhc2Fyb290Y2EubnRkZXYuY29ycC5taWNyb3NvZnQuY29tX05UREVWJTIw
U0ElMjBSb290JTIwQ0EoMSkuY3J0MBEGA1UdIAQKMAgwBgYEVR0gADANBgkqhkiG9w0BAQUFAAOC
AQEANMJkJRm8T8IXlhftKI/L9YYwW1dd4JgSv9jstKtjnIAv6PhkpCivuUt+sTsU71SAYqN+z4uo
7SSPFp3jvTjXC0CuTR7lFd4/RRbQjNk5y26vziR7vqyq2CAUWAI598uqFj2mUJx9VIOkGueAAhJd
W6HHygTOm1TZSSpwflkaZ8G+DK10Ip769K2K5WB/me8RAh6Pmifap6e3F18xCxee2PagQW6mOZHo
n1hX1/jcYRaUa4MLUui7XSDziJ0CxtpD6GPEGnx700gY+CLksXWjfndHfZ9Tg5zeCCkYUWIlUqcD
+2qC6ytxXpWI3SxB+10Atqvk+NXbmIDYVpdA5H9ulzGCAp8wggKbAgEBMFkwSzELMAkGA1UEBhMC
VVMxEjAQBgNVBAoTCU1pY3Jvc29mdDEOMAwGA1UECxMFTnRkZXYxGDAWBgNVBAMTD05UREVWIElT
U1VFMyBDQQIKNc7NHwADAC31zDAJBgUrDgMCGgUAoIIBnDAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN
AQcBMBwGCSqGSIb3DQEJBTEPFw0wMzExMDMyMzI4NTRaMCMGCSqGSIb3DQEJBDEWBBR0z4U68p4G
R33bug6JueYKDdT0xjBnBgkqhkiG9w0BCQ8xWjBYMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIA
gDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjAKBggqhkiG
9w0CBTBoBgkrBgEEAYI3EAQxWzBZMEsxCzAJBgNVBAYTAlVTMRIwEAYDVQQKEwlNaWNyb3NvZnQx
DjAMBgNVBAsTBU50ZGV2MRgwFgYDVQQDEw9OVERFViBJU1NVRTMgQ0ECCjXO0OgAAwAt9c0wagYL
KoZIhvcNAQkQAgsxW6BZMEsxCzAJBgNVBAYTAlVTMRIwEAYDVQQKEwlNaWNyb3NvZnQxDjAMBgNV
BAsTBU50ZGV2MRgwFgYDVQQDEw9OVERFViBJU1NVRTMgQ0ECCjXO0OgAAwAt9c0wDQYJKoZIhvcN
AQEBBQAEgYArtC3mLDSljs0VIivsxlJGsGAyt5GNMG4sIYPV5rIpqMNCvKrl+nj9/96otYviVORQ
IPPbhQvp9nqnJoJdts3qDqi9er1QyuLfWNfBHWV3ntqJO2E6F9KiegYtp33JYzp/Fpg5pBEBTZZf
OP6uE79vdeIlEaVR2OBp7dC0h7EWgQAAAAAAAA==

------=_NextPart_000_0057_01C3A21F.30E02E30--
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org




More information about the T10 mailing list